The MCP registry checks a package at publish. Here's what drifts after that.

When you install an MCP server from the official registry, you get exactly the package version the entry lists. The registry checks that version when the entry is published: it fetches it from npm or PyPI and confirms the package names the server.

I read the registry's source to see what happens after that. The package check runs again only when the publisher edits the entry. Nothing re-checks entries on a schedule. Repository links are checked against a URL pattern and never fetched.

That's a reasonable design for a young registry, and it isn't anyone's mistake. But it means entries can drift. So I checked the whole registry against npm, PyPI and GitHub and counted what no longer matches.

What I counted

Registry snapshot 2026-10-04: 38,977 servers (the latest version of each name). Lookups ran on 2026-10-06.

Together, at least 5,192 of 38,977 entries (13.3%), more than 1 in 8, had at least one of these.

A few notes on reading this:

• The 157 are the clearest case of drift. All of them were published after the registry's version check existed. If validation was on (it is by default), each one passed an exact-version check and the package or version disappeared later.
• Withdrawn doesn't mean malicious. I classified the publishers' own deprecation messages. Most are renames, moved distributions and discontinued packages. A few say the backing service shut down, and 12 publishers cite a security issue. A registry-driven install still gets the withdrawn version, with no warning.
• A 404 can be a renamed or private repo. I don't tell those apart.

The fix is now being tracked

I opened a feature request on the registry, modelcontextprotocol/registry#1715. It asks to re-run the existing checks on a schedule and record the result (for example lastVerifiedAt plus a status) instead of deleting anything.

On 2026-10-23, a member of the MCP organization consolidated the older re-validation request (#93) and five endpoint-health reports into that issue, so periodic re-validation now has one implementation tracker. The direction in the thread: dated results, explicit "auth-required / transient / unknown" states, and no removal on a single failed check.

That last point matters. A missing repo or a yanked version is a fact a client should see. It shouldn't silently turn into a takedown.

What this doesn't say

• Nothing here says whether any server is safe or unsafe. I didn't run or call any server's tools. Everything comes from the registry and public package records.
• The numbers are a dated snapshot. The registry has grown since then, and I haven't recounted these figures.

If you publish an MCP server

Five minutes of housekeeping:

1. Open your registry entry's repository.url. Does it still load?
2. Is the version you list still published, and not deprecated or yanked?
3. If you renamed or moved the package, publish an update that points to the new one.

Full tables, with each figure's source and date: https://protocolprobe.com/mcp/reports/registry-vs-reality
Dataset (CC BY 4.0, citable): https://doi.org/10.5281/zenodo.23386799

Disclosure: I built ProtocolProbe, a free directory that reads the registry's public data. Corrections welcome: [email protected].