A registry entry tells you a server exists, what it is called, and how to install it. It does not tell you whether your intern and your CFO should get the same answer when they both ask it the same question. Those are different jobs, and mixing them up is an easy mistake once "MCP" starts standing in for the whole stack rather than one protocol inside it.
What the mcp registry actually is
The official MCP registry launched in preview on 8 September 2025, built and backed by Anthropic together with GitHub, PulseMCP, Microsoft and other contributors to the ecosystem. It is a meta-registry: a catalogue of metadata and install instructions, not a store of the servers themselves, which continue to live in existing package systems like npm, PyPI and container registries. You can browse it, publish a manifest for your own server, and query it by API at registry.modelcontextprotocol.io.
That is a genuinely useful thing to have. Before it existed, finding an MCP server for a given system meant trusting a blog post, a GitHub star count, or word of mouth. A shared, structured catalogue with a consistent manifest format solves a real discovery problem.
The four things a registry entry does not tell you
- Whether the server is safe to point at production data. A manifest describes what a server claims to do. It is not a code review, and nothing in the publishing process runs the server against a live account to see what it actually does with the credentials it is handed.
- Who inside your company should be allowed to call it. The registry has no concept of your org chart. Once you install a server, deciding whether a support rep and a finance lead get the same access is entirely your problem.
- What a given caller may see once connected. Even a perfectly trustworthy server, correctly installed, answers every call the same way unless something in front of it resolves the caller's identity to a scope and applies it.
- Whether a write action needs a second pair of eyes. A registry entry might note that a server exposes a tool that mutates data. It has no mechanism for saying that mutation should be held for a human to approve before it runs.
Is the mcp registry the same thing as an mcp gateway?
No, and the distinction is worth holding onto precisely because both terms get used loosely. A registry is something you consult before you connect to anything: a directory. A gateway sits in the request path after the decision to connect has already been made, typically adding routing across multiple servers, credential injection and rate limiting to calls that are already flowing. You could use the registry to find a server and never put a gateway in front of it. You could run a gateway in front of a dozen servers none of which the registry has ever heard of. Neither implies the other.
"The MCP Registry focuses on namespace authentication and metadata hosting, while relying on the broader ecosystem for security scanning of actual server code."
The MCP Registry documentation, on what the registry itself is responsible for
Three layers, three jobs
| Layer | Question it answers | What it typically does not do |
|---|---|---|
| Registry | What servers exist, and how do I install one? | Vet server behaviour, or govern who may call it once installed |
| Gateway | Who or what may reach this server, and how is traffic managed? | Decide what a specific record-level result should look like for a specific caller |
| Permissioned context layer | What may this specific caller see, on this specific call? | Discover new servers, or manage network-level routing between them |
Table 1: discovery, connection management and per-caller entitlement are separable concerns, usually solved by separate pieces of infrastructure.
What the registry does check
To be fair to it, the registry is not doing nothing about trust. Publishing a server requires namespace authentication: server names follow a reverse-DNS format, like io.github.username/server-name, tied to a verified GitHub account or a domain the publisher actually controls. That stops someone else publishing a server under your company's name without owning the account or domain it claims to represent, and it is a genuinely useful spam and impersonation defence.
It is also, by design, not a review of what the server's code actually does once installed. The registry's own documentation is explicit that it delegates security scanning to the underlying package registries, npm, PyPI, Docker Hub and the rest, and to whichever downstream aggregator or marketplace chooses to add its own checks on top. The registry itself focuses on namespace authentication and metadata hosting. That is a deliberate, sensible scope for what it is, and it is also exactly why treating a registry listing as a safety signal for your own deployment is a mistake: the entity that verified the publisher's identity is not the entity that verified the server is safe to point at your production database.
Why this confusion happens
Both a registry and a governance layer reduce friction, which is why they blur together in casual conversation about "MCP infrastructure." A registry reduces the friction of finding and installing a server. A permissioned layer reduces the friction of trusting that server with real company data, by making sure the answer a caller gets depends on who they are. They solve adjacent problems at completely different points in the pipeline, and a team that has solved the first one can walk away with the impression that the second is handled too, because both show up under the same "MCP" heading in a planning document.
Does a bigger, better-curated registry eventually close the gap?
Not on its own. Even a registry with a rigorous review process, human-vetted manifests and reputation scoring answers "is this server generally trustworthy," which is a property of the software. It cannot answer "is this specific person, right now, allowed to see this specific record," which is a property of the request. The second question needs something that runs on every call, not something that runs once at publish time.
What to actually check before you connect a server to real data
- Does anything between the agent and the server resolve the caller to an identity with scopes, or does every caller get the same access as the credential itself?
- If a tool call can mutate data, is there a held-for-approval state, or does an agent's write happen the instant it is requested?
- Is a withheld or unentitled result distinguishable from an error, in a way that would tell an attacker something exists even though they cannot see it?
- Does the answer change when nothing about the query does, purely because of who is asking?
If the answer to the last question is no, for every caller, you have a discovery problem solved and a governance problem still open. The MCP pillar page sets out where Contextely sits relative to a registry and a gateway, context_search and the rest of the tool catalogue show what a permissioned response actually carries, and /security has the entitlement ordering written out against the code rather than described in the abstract. For the deeper mechanics of per-person checking once you have decided you need it, mcp authorization is the companion piece to this one.