What is the MCP Registry?

The MCP Registry is the official catalog of publicly available MCP servers. A server's author publishes its metadata there, and everyone else reads it through one REST API. The documentation describes it as "the official centralized metadata repository for publicly accessible MCP servers", backed by Anthropic, GitHub, PulseMCP and Microsoft.

The word metadata carries the definition. npm, PyPI and Docker Hub host the code. The registry hosts a record that points at that code: the server's name, its version, where the package lives, how to start it, and what it says it does. Ask the registry for a server and you get a server.json document, never a binary.

Two things follow from that, and both are easy to miss. A record in the registry is a claim by a verified publisher, not a review of their code. And a server that is not publicly installable cannot be there at all.

Names are reverse-DNS and tied to proof of ownership. A server is called something like io.github.username/weather-mcp or com.example/weather. To publish under that name you log in with the matching GitHub account, or prove control of the domain through a DNS or HTTP challenge. The namespace is the trust anchor, because only the owner of that account or domain can publish there.

Publishing happens from your own project, not through a pull request. The repository is blunt about it: adding a server.json or a seed entry in a PR "will not publish or list your server, even if the PR is merged". You publish with the mcp-publisher CLI from the server's own repository, usually from CI.

Each package type proves ownership its own way. The registry supports npm, PyPI, NuGet, Cargo, OCI images and MCPB bundles. npm packages carry an mcpName field in package.json; PyPI, NuGet and Cargo expect an mcp-name: token in the README; OCI images need the io.modelcontextprotocol.server.name label. The check is always the same; each package ecosystem just runs it its own way: does the package itself admit it belongs to this server name?

Consumers are expected to be other registries. The documentation is explicit that the registry is "intended to be consumed primarily by downstream aggregators". Those are marketplaces and client-specific catalogs that pull metadata on a regular but infrequent basis, roughly hourly, and add their own curation, ratings or policy on top. Host applications should read those, not the official registry. The launch announcement framed the same split: the registry is the "primary source of truth that sub-registries can build upon", with public marketplaces on one side and private enterprise registries on the other.

It is still formally in preview. The docs still carry the preview notice, which warns that breaking changes or data resets may occur before general availability. We found it there on 14 October 2026. The deployed service meanwhile reports version 1.8.1, built on 6 August 2026, which matches the latest release in the repository. Treat the label, not the version number, as the contract.

Provenance for public servers. Before the registry, "is this the real Notion server or someone's weekend fork?" was answered by reading a README. Now the name itself carries a verified owner. That is a small guarantee, but it is the one that was missing.

A machine-readable install contract. The same record tells a client which package to fetch, which transport to use, and which environment variables the server expects. Catalogs, IDEs and gateways can build install flows against one schema instead of scraping documentation.

A base layer for your own catalog. The spec is published as an OpenAPI document that other registries can implement, so an internal catalog can speak the same API that host applications already support. You keep the curation; you do not invent the interface.

A registry entry is not an approval. The registry delegates security scanning to the package registries underneath it and to the aggregators above it. It verifies who published a server, not what that server does once it runs. We ran into the gap as an operator: when two servers expose similarly named tools, the agent goes by the tool name and cannot see which command actually runs behind it. That is the attack surface we described while building MCP governance for enterprise. A public catalog makes that failure mode easier to reach.

Most enterprise servers will never be in it. The registry does not support private servers. Anything on an internal network or a private package registry is out of scope, and the recommendation is to host your own private registry instead. Our own enterprise gateway images reach customers through a private Docker Hub account with per-organization API keys, because the licensing terms of public docker.io rule it out for those customers. A server distributed that way is invisible to the official registry.

Discovery is not governance. Knowing that a server exists says nothing about who may call it, with whose credentials, under which budget, or what lands in the audit log. Platform policies that point at a registry URL inherit that limit. Approval usually works at the level of a whole server, while teams need to allow or deny individual tools. That gap was one of the recurring findings in our review of the MCP governance landscape. The registry is an input to policy, never the policy itself.

Do not fork it to run it internally. The maintainers state that the codebase is not designed for self-hosting and that they cannot support that use. If you need an internal catalog, implement the API, do not inherit the implementation.

If every MCP server your agents touch is built in-house and deployed behind your own perimeter, the official registry adds nothing to your runtime. What you need instead is a short, curated list of servers you have reviewed, an enforcement point that can allow or deny individual tools, and provenance you can prove to an auditor. Start there. Pull in public records later, when something public is actually worth running.