An MCP registry is a catalog that lets AI clients discover Model Context Protocol servers and the data they connect to. Any MCP server, including Atlan’s own, can be listed there. The official MCP Registry, the single project at registry.modelcontextprotocol.io, stores each server’s metadata in a server.json file under a verified, reverse-DNS namespace, and its REST API entered a version freeze on October 24, 2025 ahead of general availability. The mechanics below cover how that registry actually works, what it explicitly does not do, and how it differs from a private registry, an MCP gateway, and ad hoc MCP usage.
A registry answers one question: does this server exist, and where can a client find it. It does not answer whether the data that server returns is current, owned by anyone, or safe to act on, and that distinction runs through everything below.
- “An MCP registry” and “the MCP Registry” are not the same thing. The first is any catalog of MCP servers. The second is one specific, official project.
- The registry is scoped narrowly on purpose. It does not scan for security issues itself, does not support private servers, and was never meant for a host application to query directly.
- Registration is a discovery signal, not a trust signal. A listed server has a verified publisher namespace. It says nothing about whether the server’s underlying data is governed.
| What it is | Governed by | Launched | Cost | Core format | Does NOT support |
|---|---|---|---|---|---|
| A catalog of MCP servers that AI clients can discover | Anthropic, GitHub, PulseMCP, and Microsoft as backing maintainers of an open community project | Preview, September 8, 2025; REST API froze at v0.1 on October 24, 2025 | Open and free to publish to | server.json per entry, under a reverse-DNS namespace |
Private or internal-only servers; direct consumption by host applications; self-hosted forks with maintainer support |
What is an MCP registry?
A registry, in the general sense, is a discovery catalog. It is not the Model Context Protocol itself, and not the runtime connection between a client and a server, which the MCP architecture deep dive covers in full. A registry sits alongside the protocol, listing which servers exist so a client knows what to connect to.
The core MCP specification, dated 2025-06-18, defines the base protocol, lifecycle management, authorization, and server and client capabilities. It never defines a registry: discovery is a separate ecosystem project layered on top, which is why “an MCP registry” and “the MCP Registry” need to be told apart first.
“An MCP registry” (lowercase, general) is any catalog of MCP servers: official, vendor-run, or self-hosted. “The MCP Registry” (capitalized, specific) is the one official community project, launched in preview on September 8, 2025 and backed by Anthropic, GitHub, PulseMCP, and Microsoft as its named maintaining organizations, according to the Model Context Protocol’s own preview announcement. An MCP registry is also a different animal from an AI agent registry, a model registry, or the vendor-specific case of an AWS agent registry; what is AI registry covers that broader category, and agent registry vs. MCP registry covers the specific comparison in depth.
The registry answering “does this exist” instead of “can this be trusted” is not a gap in an early product. It is the boundary the official project draws around itself deliberately, and the next two sections show exactly where that boundary sits.
How does the MCP Registry work?
The MCP Registry stores each server’s metadata as a server.json file, identified by a reverse-DNS namespace the publisher had to verify, and reachable through a versioned REST API that any MCP client or aggregator can query. Three mechanisms carry the weight: the schema, the namespace, and the API version itself.
The server.json schema
According to the official MCP Registry documentation, server metadata is stored in a standardized server.json format defined by a published JSON schema. The core fields:
| Field | What it captures | Example value |
|---|---|---|
name |
The server’s unique, namespaced identifier | io.github.acme/weather-server |
packages / remotes |
Where to find and run it: an npm package, a Docker image, or a remote URL | npm: @acme/weather-mcp |
version |
The published release version of that server entry | 1.2.0 |
description |
Short, discovery-facing summary of what the server does | “Weather data via MCP” |
The registry does not host the server’s code. It hosts metadata that points to where the code already lives, on npm, PyPI, Docker Hub, or a public remote URL, in the same way a library catalog card points to a shelf rather than containing the book. A server that exposes lineage or catalog data, the kind covered in MCP-connected data catalog, lists the same way: a server.json entry, nothing more.
Reverse-DNS namespaces and authentication
Every server name follows a reverse-DNS format, such as io.github.username/server-name or com.example/server-name, tied to a verified GitHub account or domain. According to the official docs, this namespace system ensures only the legitimate owner of that account or domain can publish under it, which prevents impersonation and name-squatting. A separate AI agent identity concern, who or what is acting on a system’s behalf at runtime, sits one layer up from this publisher-identity question.
API versioning and the v0.1 freeze
The registry’s REST API entered a freeze at version v0.1 on October 24, 2025, ahead of general availability, per the MCP Registry’s GitHub repository. That versioning detail matters more for the aggregators and marketplaces built on top of the registry than for a reader evaluating whether to use it directly.
A server appearing correctly in server.json, under a verified namespace, on a versioned API, tells a client one thing: this server is real and reachable. What it does not tell a client is covered next.
What does the MCP Registry not do?
The official registry limits its own scope on purpose, and it says so directly in its own documentation rather than leaving the boundary implicit. Four things it explicitly does not do:
| It does not | Why, per the official docs | What to use instead |
|---|---|---|
| Support private or internal-only servers | Scoped to servers that are publicly accessible or publicly installable; private-network servers are explicitly excluded | Run a private registry (see the section below) |
| Perform its own security scanning of listed servers | Delegates scanning to the underlying package registries (npm, PyPI, Docker Hub) and to downstream aggregators, rather than duplicating it | Vet a server through its package registry’s own scanning, or an aggregator that adds curation |
| Get consumed directly by host applications | Built to be consumed by downstream aggregators and marketplaces via its REST API, not queried directly inside a chat client | Consume through a downstream aggregator implementing the registry’s OpenAPI spec |
| Ship as a self-hostable, maintainer-supported fork | The codebase is not designed for self-hosting, and the maintainers cannot support that use case | Build or buy a purpose-built private registry instead of forking the official one |
All four rows trace to the same primary source: the official MCP Registry documentation, which states plainly that the registry “does not support private servers,” “is not intended to be directly consumed by host applications,” and has a codebase “not designed for self-hosting.” This is the registry’s own stated shape, and the practical trigger that pushes most enterprise teams toward a private MCP server registry the moment they need to list anything inside a firewall.
Being listed answers existence, and existence is not the same as being current, owned, or correct, a distinction that becomes unavoidable once the growth of agent sprawl across a large organization, or orchestrating multiple agents against the same listed servers, forces the question of which listed entries can actually be trusted at runtime. The same question sits underneath broader AI agent governance, including the practicalities of governing agents across multiple clouds, once more than a handful of registries are in play.
MCP registry vs. MCP gateway: what’s the difference?
Discovery and traffic management solve different problems, and conflating a registry with a gateway is the most common confusion in this space. A registry helps a client find a server it does not yet know about. A gateway sits in front of servers a client already knows about, routing, authenticating, and managing traffic to them once discovery is done. Discovery happens before a connection exists; a gateway operates after one does, and the two often sit in the same stack: find a server through a registry, then reach it through a gateway that adds authentication and centralized routing.
That gateway is a specific case of the broader AI gateway / LLM gateway category, scoped to MCP traffic. For the full mechanics and when a single MCP server stops being enough, see what is an MCP gateway and MCP gateway vs. a single MCP server; for how a gateway relates to a governed context layer, see MCP gateway vs. context layer.
Do you need the official MCP registry, or should you build your own?
The official registry’s own non-support for private servers is the practical trigger most enterprise teams hit first: the moment a server lives on an internal network or a private package feed, the public registry is out of scope, and a team needs its own. Two named approaches illustrate what that looks like. Docker’s MCP Catalog supports custom catalogs that let a team add its own private servers alongside public ones. Microsoft’s Azure API Center registers remote and local MCP servers, including ones that never leave an internal network, through its own MCP registry endpoint. The same public-versus-private split shows up one layer up the stack in agent skills registry, a parallel discovery pattern for a different artifact type.
Neither example resolves the harder question of when a formal registry is worth building at all versus when a small team can keep track of a handful of servers informally. That decision, with the team-size and governance thresholds that actually separate the two, is covered in MCP registry vs. ad hoc MCP usage.
Registered doesn’t mean trustworthy
Being listed confirms two things: a server exists, and a verified publisher put it there. It confirms nothing about whether the data that server returns is current, owned by a specific team, or correct at the moment an agent calls it. That gap is not a flaw in the MCP Registry specifically. It is what any discovery catalog, official or private, is built to leave open, because discovery and data quality are different problems solved by different layers.
An MCP server itself, including Atlan’s own MCP server, is exactly the kind of thing a registry, public or private, would list: a namespaced entry with a server.json pointing to where it runs. Whether what that server returns is governed, carrying real lineage, ownership, and certification rather than a bare schema name, is a separate concern from whether it is discoverable at all. That is the question delivering business context through MCP answers, and the same distinction MCP for data lineage and why MCP matters for AI agents cover for MCP specifically, and whether agent registries need a context layer covers for registries generally.
A reader who now understands namespaces, server.json, and the registry’s own stated non-goals has answered “does this server exist.” Whether to trust what it returns once an agent actually calls it is a question that starts with the enterprise context layer, not with the registry entry.
FAQs about MCP registries
1. What is the official MCP Registry?
The official MCP Registry is the community-run catalog at registry.modelcontextprotocol.io, backed by Anthropic, GitHub, PulseMCP, and Microsoft, that stores metadata about publicly accessible Model Context Protocol servers. It launched in preview on September 8, 2025 and is meant to be consumed primarily by downstream aggregators and marketplaces, not queried directly by a chat client.
2. How do you publish a server to the MCP registry?
A publisher verifies ownership of a namespace, tied to a GitHub account or a domain, then submits a server.json file describing the server’s name, where to find it (an npm package, a Docker image, or a remote URL), and its version. The server’s installation method or the server itself must be publicly accessible; the registry does not accept private-only entries.
3. Is the MCP Registry the same as an MCP marketplace?
No. The MCP Registry hosts raw, unopinionated metadata. A marketplace is a downstream aggregator that pulls from the registry’s API and layers curation, ratings, or search on top. The registry is explicitly built to feed marketplaces rather than to function as one itself.
4. What’s the difference between an MCP registry and an MCP gateway?
A registry helps a client discover a server it does not yet know about; a gateway sits in front of servers a client already knows about to handle routing, authentication, and traffic management. Discovery happens before a connection exists; a gateway operates once one does, and the two commonly work together in the same stack.
5. Does the MCP Registry support private or internal servers?
No. The official registry explicitly excludes servers restricted to a narrow set of users, such as ones on an internal network or a private package feed, and recommends that organizations needing that host their own private registry instead.
6. Do you need to use the official MCP Registry, or can you run your own?
Both are valid. The official registry fits publicly discoverable servers. An organization with internal-only servers needs a private registry by definition, since the official one does not support that case; Docker and Microsoft are two vendors offering private-registry approaches built for it.
7. Is being listed in the MCP Registry the same as being verified or trustworthy?
No. A listing confirms the server exists and that its publisher namespace was verified, nothing more. It does not confirm the server’s underlying data is current, correctly owned, or safe to act on, which is a governance question the registry was never designed to answer.
Sources
- The MCP Registry, official documentation
- Introducing the MCP Registry, September 8, 2025, Model Context Protocol blog
- modelcontextprotocol/registry, GitHub repository
- server.json schema reference, modelcontextprotocol/registry GitHub
- MCP specification, 2025-06-18, Basic overview
- MCP Catalog, Docker documentation
- Inventory and discover MCP servers in your API Center, Microsoft Learn
