What is an MCP registry, and why does it need trust?

An MCP registry is a catalogue of Model Context Protocol servers — a place that records what a server is called, where its code lives, and how a client should install or connect to it, so agents and developers don't have to hunt across npm, PyPI and random GitHub repos to find one. The official one, run by the MCP project itself, does exactly that and nothing more: it verifies who published a server, not whether the server is any good. That gap — between being listed and being trustworthy — is what a trust layer like Vouchity is built to close.

What a registry is, and why MCP needs one

In software, a registry is a lookup service: npm is a registry of JavaScript packages, PyPI is a registry of Python packages, Docker Hub is a registry of container images. Each one solves the same basic problem — given a name, tell me where the real thing is and how to get it. An MCP registry does the same job for MCP servers: given a name like io.github.acme/weather, it tells a client where the actual package or remote endpoint lives, what arguments it needs, and what version is current.

MCP needs this because the protocol itself is intentionally silent on discovery. The Model Context Protocoldefines how a client talks to a server once a connection exists — not how a client finds out that a server exists in the first place. Without a shared catalogue, every host application would need its own private list, and every publisher would need to submit their server to a dozen separate lists to be found anywhere. A registry is the piece that makes "anyone can publish a server, any client can use it" actually work in practice, rather than just on paper. For the fuller picture of what a server is and what it exposes, see our MCP server explainer.

The official MCP Registry: discovery, not vetting

The project maintains its own registry at registry.modelcontextprotocol.io, described in the official documentation as "the official centralized metadata repository for publicly accessible MCP servers," backed by contributors including Anthropic, GitHub, PulseMCP and Microsoft. It stores each server's metadata as a standardized server.json file — name, install source, execution instructions, description — and exposes it over a REST API that downstream tools can pull from.

What it verifies is identity, not quality. Server names follow a reverse-DNS format (io.github.username/server, com.example/server), and claiming one requires proving ownership of the underlying GitHub account or domain through a real challenge. That stops someone from squatting on a namespace they don't own or impersonating a well-known publisher under their exact name. It doesn't tell you whether the code behind that name is maintained, licensed, or safe to execute. The documentation is direct about this division of labor:

"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

That's not a criticism of the registry — it's an accurate description of the layer it was built to occupy. The documentation explicitly says security scanning is delegatedto the underlying package registries (npm, PyPI, Docker Hub) and to "downstream aggregators," which it expects to add curation, ratings, or additional checks on top. The registry itself calls out that its metadata is "deliberately unopinionated." It was designed to be a foundation other tools build on, not the last word on whether a server deserves your trust.

What discovery-only misses

Being listed in the official registry tells you a publisher went through a real verification challenge for their namespace. It doesn't tell you any of the following, all of which matter the moment you connect a server to an agent that can actually take actions on your behalf:

• Whether it's maintained. A namespace-verified server published two years ago and never touched since is still listed. Nothing in the registry flags staleness.
• Whether it's licensed. Across the servers Vouchity tracks, 176 — 55% — declare no license at all, which is a real legal question for anyone shipping it in a product, not just an academic one.
• What it actually asks for.A remote server with no declared authentication, or a tool description that reads like an instruction aimed at the model rather than a human, looks identical to a well-behaved server in the registry's metadata. See how tool-description injection works for a concrete example of what that looks like in practice.
• Whether the publisher is a known quantity or a namespace created five minutes ago. DNS/GitHub verification stops impersonation of an exact name, but it doesn't distinguish a first-time publisher from an established one — both pass the same identity check.

None of this is a gap in how the registry was built — it's a gap in what a registry, as a category of tool, is for. npm doesn't tell you whether a package is well-written either; that job fell to a separate ecosystem of audit tools, download counts and reputation signals built on top of it. MCP is going through the same split, just faster and with higher stakes, because an MCP server doesn't just get imported — it gets handed real permissions to a running agent.

Discovery answers a different question than trust

It helps to be precise about which question each layer actually answers:

A registry that tried to answer the trust questions itself would need to become an editorial gatekeeper — deciding, server by server, whether something is "good enough." That's a fundamentally different job from running neutral, namespaced metadata infrastructure, which is why the official registry explicitly hands it off instead of half-doing it. Vouchity exists to be the layer that picks that job up.

What a trust layer looks like with real numbers

Vouchity currently tracks 320 MCP servers across 11 categories, each computed into a Trust Score out of 100 from live GitHub and npm signals — maintenance recency, adoption, license and source transparency, declared security posture, and publisher provenance. Full detail on how each signal is weighted is in our methodology. The average score across the whole registry right now is 63/100, and 269 servers (84%) carry at least one real risk flag we surface on their page — see the current risk watch for what that looks like.

Scores aren't evenly spread. Here's the current grade distribution across the whole registry:

Only a handful of servers clear grade A. That's the point of scoring on real signals instead of install counts or GitHub stars alone: most of the ecosystem is fine but unremarkable — a working server with an actual gap somewhere, a missing license or a stale repo — and a small number are genuinely exemplary. Here are the five highest-scoring servers Vouchity tracks as of this snapshot; the ranking moves as the registry re-syncs, so check the live leaderboard for the current one.

Every one of those numbers comes from something checkable — a commit timestamp, a license file, a published download count — not a subjective house opinion. That's the difference between a trust layer and an editorial one: Vouchity doesn't decide a server is good, it measures signals that correlate with a server being safe to run and reports the result, the same way a credit score reports risk rather than personality.

How the two layers actually fit together

In practice they're not competitors — they're stacked. The official MCP Registry is closer to the phone book: a namespaced, authenticated index of what exists and where to find it, meant to be consumed by "downstream aggregators" that add exactly the kind of curation a neutral metadata store shouldn't try to own itself. Vouchity is one of those aggregators, specialized specifically on trust: every server we track resolves back to its real npm or GitHub source, and we score it independently rather than accepting a publisher's self-description at face value.

A sensible workflow looks like this: use the registry (or a client that consumes it) to find candidate servers for what you need, then use Vouchity to checkthe one you're about to install before you point an agent at it. Search across the full tracked set on the server registry, browse by use case in categories, or watch what's newly gaining adoption on trending. If you want the check to happen automatically instead of manually, Vouchity also ships as an MCP server itself — see the hosted API — so an agent can look up a Trust Score before it ever calls a tool, which is the discovery-plus-trust loop closing all the way.

For a closer look at exactly what signals go into a score and why, read how Trust Score works, or if you're evaluating a specific server by hand, our practical vetting checklistwalks through the same five signals manually. If you're a publisher on the other side of this, what makes a server trustworthy covers what to fix before you publish.

The short version

"MCP registry" describes a category of infrastructure, not a guarantee. The official one does its job well — a neutral, namespaced, authenticated catalogue that any client can pull from — and is upfront that it stops there by design. Treat a listing the way you'd treat a business having a phone number: real, findable, and not in itself a reason to trust it. For the part that actually answers "is this safe to run," that's what a Trust Score is for.