The MCP Registry verifies namespaces, not servers

There is a persistent misreading of the official MCP Registry, and it costs people real time: the assumption that a listing there means something was checked. It does mean something. It means something narrow and precise, and once you see the shape of it, the whole MCP distribution stack makes more sense.

The registry is the official centralised metadata repository for publicly accessible MCP servers, backed by Anthropic, GitHub, PulseMCP and Microsoft. It provides four things, per its own documentation: a single place to publish server metadata, namespace management through DNS verification, a REST API for clients and aggregators, and standardised installation and configuration information. Notice what is absent from that list.

What a name actually proves

Server names are reverse-DNS, and the form of the name is determined by how you authenticated. GitHub authentication gives you io.github.username/* or io.github.orgname/* and nothing else. Domain authentication gives you the reverse-DNS form of a domain you control — com.example.*/* for example.com.

Three authentication paths exist, and they are worth knowing because they tell you exactly how much a name is worth.

Both domain methods are signature-based, with Ed25519 or ECDSA P-384 keys, and both support keys held in Google Cloud KMS or Azure Key Vault rather than on disk — a sensible touch for an organisation that does not want a publishing key sitting in a developer's home directory. The well-known path is singular and exact: mcp-registry-auth, no trailing variations. If you have ever lost an afternoon to a plural-versus-singular well-known path, as we noted when covering signed crawler identity, you will want to copy that string rather than type it.

So a registry name is an identity claim with a cryptographic or OAuth-backed proof behind it. That is genuinely useful. It makes impersonation hard, which is the single most valuable property a package index can have. It says nothing whatsoever about the code.

The moderation policy is the honest part

Most registries bury their guarantees. The MCP Registry leads with them, and the moderation policy deserves reading in full because it is a model of saying the unflattering thing out loud. Its own summary: “The MCP Registry is quite permissive! We only remove illegal content, malware, spam, and completely broken servers.”

Then the disclaimer, which is the sentence to remember: the registry “does not make guarantees about moderation, and consumers should assume minimal-to-no moderation.” It goes further and admits there may be content that should be removed under the policy but has not been yet, and that consumers “should treat scraped data accordingly.”

The removal list is illegal content (including hacking tools), malware regardless of intent, spam, and non-functioning servers. The non-removal list is the one that matters for anyone building on top: low-quality or buggy servers stay, duplicate servers stay, adult content stays, and — stated plainly — “servers with security vulnerabilities” stay.

That last one is not an oversight. Security scanning is explicitly delegated: upward to the package registries that host the actual code — npm, PyPI, Docker Hub — and downward to aggregators and marketplaces that can add their own checks, ratings and curation. The registry describes itself as focused on “namespace authentication and metadata hosting”. It is a layer, and it says which layer it is.

You are not supposed to consume it directly

This is the architectural decision most people miss. The documentation states that the registry “is not intended to be directly consumed by host applications”. Host apps are meant to consume downstream registries — marketplaces, aggregators — through a REST API conforming to the official registry's OpenAPI spec. Aggregators are expected to pull metadata “on a regular but infrequent basis (for example, once per hour)”.

The sync mechanics are clean. GET /v0.1/servers at registry.modelcontextprotocol.io takes updated_since with an RFC3339 timestamp and uses cursor-based pagination, and passing updated_since automatically sets include_deleted=true so an incremental sync sees removals. Servers carry one of three statuses: active, deprecated, or deleted. Deleted is not a hard delete — the metadata remains accessible via the API and aggregators are expected to drop it from their own indexes.

Which means the deduplication, the quality filtering and the delisting that users experience all happen in the aggregator tier. That is the same division of labour any honest directory operates under; it is what designing a content taxonomy is really about, and why a listing surface needs an opinion rather than a feed. If you run a tools directory in the AI space, the registry hands you clean identity and leaves you the entire curation problem.

The boundaries that will bite you

No private servers, and no self-hosting the official codebase

A server qualifies if its installation method is publicly available or the server itself is publicly reachable. Anything behind a private network or a private package registry — the documentation's examples are mcp.acme-corp.internal and an Artifactory-scoped npx install — is out, and the advice is to run your own private registry. But the official codebase is “not designed for self-hosting” and maintainers will not support that use case. So “run your own” means implement the OpenAPI spec, not fork the server.

Only approved package registries

Per the official registry requirements, package base URLs are allowlisted: registry.npmjs.org, pypi.org, api.nuget.org, crates.io, and a fixed set of container registries including Docker Hub, GHCR, Quay.io, Google Artifact Registry, Azure Container Registry and MCR. MCPB bundles are accepted only from GitHub and GitLab releases. A non-approved base URL fails validation outright. Packages must also carry metadata proving the publisher owns them, which is the second half of the anti-impersonation story and is the same provenance direction npm took when it moved to trusted publishing — see npm publishing without tokens.

Preview means preview

The registry documentation repeats the same notice page after page: the registry is in preview, and “breaking changes or data resets may occur before general availability”. A data reset is a strong phrase. If your product depends on registry IDs being stable, store your own copy keyed on the server name and version, and treat the registry as a source you re-derive from rather than a database you read from live. The same caution applies as with any pre-GA spec surface, which is the lesson from MCP's stateless spec migration.

A 4KB ceiling on your own metadata

Publisher-provided metadata lives under the io.modelcontextprotocol.registry/publisher-provided key and is capped at 4,096 bytes of JSON; exceed it and publishing fails with the size in the error. Custom _meta keys outside that namespace are silently dropped — silently being the operative word. Validate your payload before you ship it; the JSON formatter will tell you the byte count, and JSON to Zod is a quick way to pin the shape of a server.json in your own tooling.

FAQ

Does a listing in the official MCP Registry mean the server is safe?

No. It means the publisher proved control of the GitHub account or domain in the server's name, and that the package came from an approved registry with ownership metadata. The moderation policy states that servers with security vulnerabilities are not removed, and that consumers should assume minimal-to-no moderation.

Who actually performs security scanning?

The registry delegates it in two directions: to the underlying package registries such as npm, PyPI and Docker Hub, which run their own scanning, and to downstream aggregators and marketplaces, which can add checks, ratings or curation of their own.

How do I publish under my company domain instead of my GitHub username?

Use DNS or HTTP authentication. Generate an Ed25519 or ECDSA P-384 key pair, publish the proof as a TXT record on the domain or as a file at /.well-known/mcp-registry-auth, then log in with mcp-publisher using the matching private key. Your server name must then be the reverse-DNS form of that domain.

Can I list an internal company MCP server?

No. The registry does not support servers that are only reachable by a narrow set of users, such as those on a private network or in a private package registry. The documented recommendation is to run your own private registry, implementing the official OpenAPI spec rather than forking the official codebase, which is not designed for self-hosting.

What happens to a server that gets taken down?

Its status is set to deleted and its metadata remains accessible through the registry API so aggregators can remove it from their own indexes. In extreme cases the maintainers may overwrite or erase the metadata, for example if the metadata itself is unlawful. Appeals go through a GitHub issue naming the server and the reason.

How often should an aggregator poll the registry?

The documentation suggests a regular but infrequent cadence and gives once per hour as its example. Use the updated_since parameter with an RFC3339 timestamp for incremental sync; that automatically includes deleted servers so your index learns about removals.

A registry that tells you exactly what it does not guarantee is more trustworthy than one that implies it guarantees everything.