I Audited 200 Servers in the Official MCP Registry. One in Six Repository Links Is Dead.

TL;DR: Frequently, nothing you can read. I pulled all 21,986 servers from the official Model Context Protocol registry on August 15, 2026 and audited a random sample of 200 one at a time. Of the 163 that list a source repository, 26 return a 404, so one in six repository links in the official registry points at nothing. Only 45 of the 200 publish a security policy, meaning 77.5% give you nobody to report a vulnerability to. The code that does exist is mostly fresh. The paperwork that would let a security team check it is missing.

MCP went from a protocol spec to a software distribution channel in about eighteen months, and the registry numbers show the shape of it. The oldest entry in the official registry was published on September 9, 2025. That first month saw 351 servers published. July 2026 alone saw 5,445. Nobody built a review process to match that curve, because nobody built a review process at all.

The interesting question is not "are these servers malicious." You cannot know that from the outside, and I am not going to pretend otherwise. The answerable question is narrower and more useful: if you handed this list to a security team, what share could they audit even in principle? Is there source to read, is it still there, and is there a human to email when you find something?

What did I actually count?

Two passes, both on 2026-08-15, both reproducible.

The census. I paged the registry API at https://registry.modelcontextprotocol.io/v0/servers?limit=100&version=latest, following metadata.nextCursor through 220 pages. The version=latest filter collapses the multiple published versions each server accumulates down to one current record. That returned 21,986 servers: 21,738 marked active, 248 deprecated. 17,479 of them (79.5%) list a repository; 4,507 (20.5%) list none.

The audit. The API paginates alphabetically by reverse-DNS name, and that ordering is badly biased: repository-presence runs at 46% in the second decile and 96% in the eighth, because the io.github.* namespace has a GitHub repo by construction and the custom-domain namespaces often do not. Auditing the first 200 would have measured the alphabet. So I drew a seeded random sample instead (random.seed(20260815), random.sample(pop, 200)), which came out at 81.5% repository presence against the population's 79.5%.

For each of the 200 I fetched the repo page at https://github.com/{owner}/{repo} for its status code and for a "Public archive" banner, the Atom feed at /commits.atom for the last commit timestamp, and https://raw.githubusercontent.com/{owner}/{repo}/HEAD/SECURITY.md plus the .github/ and docs/ variants and GitHub's org-level {owner}/.github fallback. I re-checked all 26 404s serially a second time to rule out rate limiting. All 26 were still 404.

To be explicit, because the topic invites the opposite assumption: I did not install, run, or invoke a single MCP server. This is a metadata audit. Every request above fetches a public page.

What did the audit find?

Check (random sample, n=200)	Result
Listed a source repository	163 (81.5%)
Listed repo returned 404	26 of 163 (16.0%)
Repo resolved	137
Resolved but marked "Public archive"	2
Published a security policy	45 of 200 (22.5%)
No readable source at all	63 of 200 (31.5%)
Median days since last commit	19
No commit in 180 days	10 of 137 (7.3%)

That bolded row is the headline: 31.5% of the official registry could not be audited even in principle, because there is no source to read. 60 of those 63 are still installable, listing either a package or a live remote endpoint.

The number I did not expect is the 404 rate. These are not servers that declined to list a repository. These are servers that listed one, and the link is dead. The registry stores that URL as a string and never checks it again, so the metadata reads as more auditable than the ecosystem actually is. That is still the better-populated of the two agent-interoperability registries: on the other one, exactly one of 50 named A2A supporters serves a fetchable agent card.

Are the repos abandoned?

No, and this is where my own hypothesis broke. I expected to find a graveyard. The median resolved repo had a commit 19 days ago. Only 10 of 137 had gone 180 days without one. Zero had gone a year.

That null result has a boring explanation I should give rather than bury: the registry is eleven months old. A repo cannot be stale for 365 days when the whole index started in September 2025. Abandonment has not had time to appear yet, which makes the 19-day median a fact about the registry's age as much as about maintainer diligence. Check this number again in 2027 and it will mean something. Today it only rules out the lazy version of the story. The problem is not neglected code. It is absent code.

Isn't this just npm and PyPI again?

Largely yes, and the concession is real. npm has the same property: unaudited packages, dead repo links, no security policy, install scripts that run on your machine. The ecosystem works anyway. If "unvetted registry" were disqualifying, modern software would not exist. Anyone selling you MCP panic on supply-chain grounds alone is selling you something.

The difference is narrower than "supply chain scary" and it is the only part of this worth acting on. An npm package runs with your process's authority. An MCP server is handed tool-calling authority inside an agent that already holds your credentials: your repo access, your inbox, your database, your cloud console. The package does not need to exfiltrate anything itself, because the agent it is talking to can already reach all of it and will act on instructions that arrive as data. That is the lethal-trifecta problem the Comet disclosures documented six times over, except the untrusted content now arrives through a tool you deliberately installed.

The incident record is short but not theoretical. UpGuard's roundup of MCP security incidents names six, including CVE-2025-6514 in mcp-remote (July 2025), the GitHub MCP private-repo exfiltration via a poisoned issue (May 2025), and a cloned Oura Ring server pushed through registry poisoning (February 2026). Separately, OX Security disclosed an architectural command-execution flaw across the official SDKs on April 15, 2026, with ten CVEs attached. OX estimates the blast radius at "up to 200,000 vulnerable instances in total." Treat that as what it is: an upper-bound estimate from a company that sells MCP security, not a measured count. The CVEs are the checkable part.

What does this not prove?

It does not prove any server is unsafe. A missing SECURITY.md means a maintainer never filled in a template, not that the code is bad, and plenty of excellent software has a dead repo link and an absent disclosure policy. I deliberately am not naming individual servers, because "this repo 404s" is a fact about metadata hygiene and would read as an accusation it does not support.

The split also matters. Of the 108 package-distributed servers in my sample, code that actually runs on your machine, 93.5% listed a repo and only 15 (13.9%) had no readable source. Of the 88 remote-only servers, hosted endpoints you point an agent at, 51.1% had no readable source and only 6.8% published a security policy. For a hosted service, absent source is normal; you never get Salesforce's source either. But you also never handed Salesforce a token and a tool-call loop with no review, which is precisely what pointing an agent at an unknown remote endpoint does.

One caveat on scale: registry totals differ by roughly 2x across aggregators because inclusion bars differ, so always name the registry. Smithery advertises 14,618+ MCPs, which is smaller than the official registry's 21,986, the reverse of the ordering most write-ups assume. And the reference implementation repo is its own quiet lesson: modelcontextprotocol/servers currently ships 7 active reference servers against 13 archived ones, with GitHub, Slack, GitLab, Google Drive and PostgreSQL all in the archive. Even the canonical examples churn faster than the docs quoting them.

The practical version is unglamorous. Before an MCP server touches an agent that holds real credentials, open the repository link. If it 404s, you have learned something the registry will not tell you, and it took four seconds. That is a lower bar than the demo-to-production gap every agent tool fails, and most of this category still will not clear it.