Official MCP Registry: a new MCP growth channel

The official MCP Registry is the one place where you publish your MCP server’s metadata and let other catalogs pick it up. Before it existed, every directory had its own submission form, pull request or crawler. This article maps the MCP catalogs that appeared as the protocol grew, explains what the official registry is and when it launched, and shows which catalogs already consume it, so you can decide where publishing fits in your distribution plan.

Key takeaways

• Many community catalogs list MCP servers: mcp.so, Smithery, PulseMCP, Glama and the awesome-mcp-servers list on GitHub are the best known. Each has its own way in.
• GitHub launched the GitHub MCP Registry on September 16, 2025. Docker announced its MCP Catalog and Toolkit on April 22, 2025 and released them on May 5, 2025.
• The official MCP Registry at registry.modelcontextprotocol.io launched in preview on September 8, 2025. It hosts metadata only and checks that you own the namespace you publish under.
• It is built to be consumed by other catalogs. Glama says it ingests everything in it, and PulseMCP lists it as a data source.
• In my view, publishing there is the cheapest distribution step you can take: one server.json, one CLI, many downstream catalogs.
• Get your server ready first, and measure what the catalogs send you afterwards.

How many MCP server catalogs are there?

As soon as developers started writing MCP servers, people started listing them. The result is a crowded field of directories that overlap but work differently:

Catalog	How a server gets in
mcp.so	A community directory of MCP servers, with listings, remote endpoints and setup guides
Smithery	You publish your server on Smithery itself, with its CLI or publish API
PulseMCP	A directory and sub-registry API, fed in part by the official MCP Registry
Glama	Maintainers list servers through GitHub, and Glama also ingests the official MCP Registry
awesome-mcp-servers	A pull request to a curated GitHub list; remote-only servers go to a separate list
GitHub MCP Registry	A curated selection at launch, with self-publishing through the open registry planned
Docker MCP Catalog	A pull request to Docker’s own docker/mcp-registry repository

The list keeps changing. mcp.run, for example, now redirects to Turbo MCP, a self-hosted MCP gateway. Submitting to each directory by hand means a form or pull request per catalog, repeated on every release.

GitHub MCP Registry and Docker MCP Catalog

Two platform companies built catalogs of their own, and both are worth knowing because developers already live in their tools.

GitHub MCP Registry

GitHub launched the GitHub MCP Registry on September 16, 2025, “with a curated selection of MCP servers”. The same changelog says GitHub was working with the MCP steering committee on the open-source registry “to eventually allow for self-publication of MCP servers”.

A GitHub guide from October 24, 2025 describes the intended flow: you publish with the mcp-publisher CLI, and your server “shows up in the open source registry and downstream registries (like GitHub’s)”. At the time, it still asked publishers to email [email protected] to be included, and listed self-publication as “expected in the next couple months”. I could not find a later GitHub source that confirms automatic inclusion has shipped, so check the guide before you count on it.

GitHub also lets enterprises point Copilot at their own registry. Its configuration docs require that registry to “follow the v0.1 MCP registry specification”, which is the API the official registry defines.

Docker MCP Catalog

Docker announced the upcoming Docker MCP Catalog and Toolkit on April 22, 2025, and introduced them on May 5, 2025. The catalog is part of Docker Hub and listed “100+ MCP servers” at launch, all of them containerized and curated. You get in by opening a pull request to the docker/mcp-registry repository, and an approved server appears in the catalog, Docker Desktop’s MCP Toolkit and, for images Docker builds, the mcp namespace on Docker Hub.

Docker’s catalog docs do not mention the official MCP Registry. The Toolkit’s CLI docs do accept a server reference in the form https://<url>/v0/servers/<uuid>, which they describe as “the MCP community registry”. So Docker users can add a server from a registry, but listing in the Docker catalog itself is a separate submission.

What is the official MCP Registry?

The MCP project announced it in Introducing the MCP Registry, published on September 8, 2025, with the words “The MCP Registry is now available in preview”. The post calls it “an open catalog and API for publicly available MCP servers” and “a primary source of truth that sub-registries can build upon”. The work began in February 2025, when MCP creators David Soria Parra and Justin Spahr-Summers asked the PulseMCP and Goose teams to help build a community registry.

The registry’s About page describes it as “the official centralized metadata repository for publicly accessible MCP servers”, backed by contributors such as Anthropic, GitHub, PulseMCP and Microsoft. What it does, in short:

• It stores metadata in a standard server.json file: a unique name, where to find the server (an npm package, a Docker image or a remote URL) and how to run it.
• It hosts no code. Packages stay on npm, PyPI, NuGet, Docker Hub and the other package registries.
• It checks that you own your namespace. A name like io.github.alice/weather needs a GitHub login as alice, and com.example/weather needs DNS or HTTP proof that you control example.com.
• It serves a public REST API at https://registry.modelcontextprotocol.io.
• It does not accept private servers that only a narrow set of users can reach.

Two status notes from the repository README: the API entered an “API freeze (v0.1)” on October 24, 2025, and the docs still say the registry is in preview, so “breaking changes or data resets may occur” before general availability.

Why does the official registry sit upstream of the others?

The official registry was designed to feed other catalogs, not to replace them. Its About page says it “is intended to be consumed primarily by downstream aggregators, such as MCP server marketplaces”, and that host applications should consume those downstream registries rather than the official one directly.

The aggregators guide spells out the model. Aggregators read the API “on a regular but infrequent basis (e.g., once per hour)”, store the data themselves and add what the official registry deliberately leaves out: ratings, download counts, security scans and curation. A sub-registry is an aggregator that also serves the same API, so clients can read it the same way.

For you as a publisher, the official registry holds the facts you control: name, description, version, packages and remote URL. It does not rank or review servers. The downstream catalogs decide how to present, score and promote what they ingest.

Metadata is immutable once published. When you release a new version, every aggregator that syncs picks up the same record, instead of you editing each listing by hand.

Which catalogs consume the official MCP Registry?

These are the consumers I could confirm from each project’s own documentation:

Consumer	What its own docs say
Glama	“Glama ingests and re-publishes everything in the official registry” and layers its own analysis on top (methodology)
PulseMCP	Lists “Integration with the Official MCP Registry” as a data source; its Sub-Registry API implements the generic registry API (API page)
GitHub MCP Registry	Servers published to the open registry are meant to appear “in the open source registry and downstream registries (like GitHub’s)”; inclusion still went through email in October 2025 (guide)
Docker MCP Toolkit	Can add a server referenced from “the MCP community registry”; the Docker catalog itself is a separate submission (CLI docs)
Community browsers and tools	MCP Bench, TeamSpark’s registry browser, MCP Registry UI and others browse or analyze the official registry (community projects)

I left out catalogs where I found no primary source. Smithery and mcp.so, for example, have their own listings, and I could not find documentation saying they sync from the official registry. Claude’s directory is also separate: Anthropic’s docs say the domain-ownership proof belongs to the open MCP Registry, not to its own directory, as I explain in the Claude Marketplace article.

Why publish to the official MCP Registry?

I think every public MCP server should be in the official registry, for three practical reasons.

1. One publish reaches several listings. You write one server.json and run one CLI, Glama and PulseMCP pick it up, and other catalogs that sync from the registry can do the same.
2. The name is verified. An io.github.* or reverse-DNS name proves the listing comes from you, and nobody else can publish under your namespace.
3. Your metadata is the source. Catalogs that sync get your description and URL from the record you published.

It costs little: one config file, and one command for each release. The how-to is in How to publish an MCP server to the MCP Registry.

The registry is not a storefront inside ChatGPT or Claude. Those assistant directories have their own submissions, and they are where end users of the assistants look. I cover them one by one: ChatGPT, Claude, Muse, Perplexity and Gemini. The registry reaches developers and the catalogs they browse; the assistant directories reach people inside a chat.

Get your MCP server ready before you publish

The registry does not review your tools, but the catalogs downstream do look at them. Glama’s methodology, for one, describes scoring tool definitions and diffing tool descriptions for prompt-injection patterns. Clients that find you through a catalog will also connect and sign in the way ChatGPT and Claude do. Fix what they would trip on first:

• Tools and descriptions. When you add your server to MCP Tower, its Inspect module validates every tool and its description and gives you recommendations. You can fix them on your server, or change a tool’s title and description with an override without waiting for a release.
• Sign-in. If your server uses OAuth, run MCP Tower’s 18 OAuth checks. They sign in the way ChatGPT and Claude do and report the first step that breaks, with the fix.
• The URL you publish. Each remote URL in the registry can belong to only one server name, and your published versions cannot be edited. Put MCP Tower in front of your server first (onboarding) and publish its hostname as the remote URL. The URL you publish is then the one you keep, and every call through it is measured.

Measure what the registry sends you

Once you are listed, you cannot see from the registry who installed or called your server. Each downstream catalog shows its own numbers, if any. This is where MCP Tower comes in, the first product built to show how AI agents use your MCP server.

Because it sits in front of your server, MCP Tower records every call that passes through: which agent made it and how far that label can be trusted, which tool it called, how long it took and what failed. It also tracks link clicks from tool results and interactions inside widgets, and checks your server’s uptime even when nobody is using it. Compare the weeks before and after you publish, and you see what the registry and the catalogs that pull from it send you, in the same reports as your ChatGPT and Claude traffic. To see it on your own server, start with MCP analytics in MCP Tower.

Conclusion

MCP catalogs multiplied as the protocol took off, and each had its own way in. The official MCP Registry, in preview since September 8, 2025, gives them a shared upstream: you publish verified metadata once, and Glama, PulseMCP and other aggregators pull it from there. It does not replace the assistant directories, but in my view it is the cheapest listing you can get. Prepare your server, publish it behind the hostname you will keep, and watch what arrives.

Next step: follow the step-by-step guide, How to publish an MCP server to the MCP Registry, and add your MCP server to MCP Tower before you run mcp-publisher publish.