The MCP Registry: What It Is & How to Publish to It

The MCP registry is the official, centralized metadata repository for publicly accessible MCP servers, hosted at registry.modelcontextprotocol.io and backed by major ecosystem contributors — Anthropic, GitHub, PulseMCP and Microsoft. Its job is narrow and useful: give server creators one place to publish standardized metadata about their server, and give clients and marketplaces one API to discover what exists.

A crucial distinction up front: the registry hosts metadata, not code. The actual server lives where code always lives — an npm package, a PyPI package, a Docker image, or a remote HTTPS endpoint. The registry stores a standardized record that maps a server’s name and version to *where to get it* and *how to run it*. Think of it as the card catalog, not the library shelves.

This guide is the meta-layer companion to our own MCP server directory; if you want to understand how the ecosystem’s discovery plumbing fits together — and where our directory sits in it — this is the map.

Every registry entry is a standardized server.json record. It’s deliberately minimal — enough to find, identify and install a server, and nothing opinionated on top:

The registry’s most important trust feature is namespace authentication. Server names use a reverse-DNS format that ties them to a verified identity, and only the proven owner of that identity can publish under it:

• io.github.username/server-name — verified by proving control of that GitHub account.
• com.yourdomain/server-name — verified by proving control of that domain via DNS or an HTTP challenge.

This is what stops a bad actor from publishing a server called io.github.stripe/official and impersonating a trusted vendor: they can’t verify ownership of that namespace, so they can’t claim it. It’s the same principle that makes reverse-DNS package identifiers trustworthy elsewhere, applied to MCP servers.

People conflate the official registry with the many MCP directories and marketplaces, but they occupy different layers of an intentional design. The registry is meant to be consumed by those directories, not directly by end users:

The registry maintainers make this explicit: the metadata is deliberately unopinionated, and downstream aggregators provide curation and additional data such as community ratings. It even defines an OpenAPI spec other registries can implement — a “registry of registries” model where private and public registries share one interface.

That’s precisely the role our MCP server directory plays: we add the curation the registry deliberately omits — real setup guides, example prompts, honest categories, and reviews — on top of open metadata. The two aren’t competitors; the directory is the layer the registry was designed to feed.

Publishing is open to any server that’s publicly installable (a public npm/PyPI/Docker package) or publicly reachable (a remote server not locked to a private network). The path, at a high level:

1. 1Ship your server somewhere public — publish the package, or stand up the remote endpoint. The registry needs something real to point at.
2. 2Write your server.json — name (under a namespace you can verify), description, package or remote location, and runtime hints.
3. 3Verify your namespace — prove ownership of the GitHub account or domain in the name, via the registry’s publishing tooling.
4. 4Publish, then verify the listing — confirm your record resolves through the registry API, and consider testing the server itself with our MCP server tester first so consumers get a clean handshake.

That submission path is /mcp-servers/submit. And a caveat worth repeating: the official registry is still in preview, so its API shapes and tooling may change before general availability — check the official registry documentation for the current publishing flow before you start.