MCP Registry

The MCP Registry is the official, centralized metadata catalog of publicly accessible Model Context Protocol servers, run by the MCP project at registry.modelcontextprotocol.io. Its documentation describes it as "the official centralized metadata repository for publicly accessible MCP servers, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP, and Microsoft." It answers a question the protocol itself leaves open: once thousands of servers exist, how does a client, a marketplace or an agent find the right one and know who published it?

What It Is and Is Not

The registry stores metadata, not code. Each entry is a server.json record containing the server's unique name, where to get it (an npm, PyPI or Docker package, or the URL of a remote server), how to run it, and descriptive data. The code stays in the package registries; the MCP Registry points to it. Closed-source servers may be listed as long as the installation method or endpoint is publicly reachable. Private servers are out of scope, and organizations are expected to run their own registries for those.

Two design choices are easy to miss. The registry is "deliberately unopinionated": it does not rate, rank or curate. And it is not meant to be queried directly by end-user applications. The documentation says it is "intended to be consumed primarily by downstream aggregators, such as MCP server marketplaces," which add curation, ratings and security checks and expose the same OpenAPI interface to host applications. The official registry is the upstream source of truth, and the directories people actually browse sit on top of it.

Publishing and Verification

Publishers submit entries with the mcp-publisher command-line tool. Names use a reverse-DNS format such as io.github.username/server or com.example/server, and the publisher must prove control of the namespace through GitHub authentication or a DNS or HTTP challenge on the domain. That is the registry's main trust guarantee: an entry under a company's domain was published by someone who controls that domain.

It is a guarantee about identity, not safety. Security scanning is explicitly delegated to the underlying package registries and to downstream aggregators, and maintainers can remove spam or malicious entries after the fact. Since tool descriptions and tool outputs are untrusted input to a model, a verified namespace does not remove the prompt injection risk of connecting an unfamiliar server.

Status and Scale

The registry launched in preview on September 8, 2025 and froze its v0.1 API on October 24, 2025. Its documentation still carried a preview notice when checked in October 2026, warning that breaking changes or data resets may occur before general availability.

Counts of MCP servers should be quoted with a source and a date, because trackers measure different things and disagree widely.

The spread, from about 22,000 to about 97,000 on the same day, reflects method: automated crawls of code hosts count far more than curated lists, and the sets overlap heavily. Volume also says little about quality. The same independent snapshot of the official registry reported that 62% of servers had exactly one published version, roughly a third had not been updated in 90 days or more, and 23% carried no source-code link. It is a single analyst's reading of the public API and has not been replicated, but it is consistent with a long tail of experiments around a smaller core of maintained servers.

Why Listing Matters

For a product that wants to be usable by agents, the registry is a distribution point. Marketplaces and client applications draw on registry data to populate their catalogs, so an official entry is the most direct way to appear across them with a verified publisher name and correct installation details, instead of relying on each directory to scrape a README. It is the discovery half of the tools pillar of agent experience: an MCP server that coding agents and their users cannot find does little good.

Listing is necessary, not sufficient. No public study yet shows how often agents select tools from registry data as opposed to documentation, web search or prior knowledge, and with tens of thousands of entries a listing alone confers no prominence. The sensible framing is hygiene: claim the namespace, publish accurate metadata, keep versions current, and treat downstream marketplaces as the places where selection actually happens. Broader questions of how agents find each other, beyond tool servers, belong to agent discovery.