MCP Registry 發佈時檢查套件，後續核對發現 13.3% 條目有失配

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.

What	Count	Out of	Share
Repository link returns 404 (missing or private)	4,298	28,743 entries with a GitHub link	15.0%
Listed version is withdrawn upstream (npm deprecated / PyPI yanked)	663	14,431 npm/PyPI entries	4.6%
Linked repository is archived	309	24,256 reachable repos	1.3%
Listed package or version can't be installed at all	157	14,431 npm/PyPI entries	1.1%
Active, but no package, no remote and no website	216	38,977	0.6%

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:

Open your registry entry's repository.url. Does it still load?
Is the version you list still published, and not deprecated or yanked?
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: hello@protocolprobe.com.