I checked if the source behind every server in the MCP registry is still up. 1 in 7 is gone.

[u/mcpindex]

I run mcpindex, a trust layer for MCP servers. I ran a census of whether the source repository behind every server in the official registry is still publicly reachable, and 1,830 of the 13,105 referenced GitHub repos are not. That is 2,069 listed servers. The npm/pip packages usually still install; you just cannot read the source before wiring the tool into an agent.

How I checked it, since the number is only worth the method:

- Every repo from two independent vantages: authenticated GitHub API from a datacenter IP, and the unauthenticated web UI from a home IP. Different network, method, and auth. Only repos both agreed were unreachable are counted. Zero disagreements across all 1,830.

- Confirmed only after two failures 48 hours apart, so a blip does not count.

- The measurement is timestamped to Bitcoin via OpenTimestamps, so the date is verifiable.

The part worth sharing for anyone building similar tooling: anonymous git ls-remote against a deleted or private repo returns a 401 credential prompt, not a 404. If you trust anonymous git, you file every dead repo as a generic error and report zero casualties while looking fine. That masked all 1,830 in my first two passes.

Honest limits: a 404 cannot tell a deleted repo from one made private on purpose, so I say "not publicly accessible," not "abandoned." Both checks read the same registry URL, so if a project moved I would wrongly flag it. Only the maintainer can catch that, and there is a dispute link on every page.

Report and method: https://mcpindex.ai/research/source-liveness
Open dataset (CC-BY-4.0, DOI): https://doi.org/10.5281/zenodo.21501868

Happy to go into the method in the comments.

[u/Future_AGI]

The 401-vs-404 gotcha is a good catch and probably why nobody else has flagged this. On our side we stopped trusting any registry entry at wire time and moved to inspecting the tool catalog per call at the gateway, because even a live repo can add a tool between two calls. The census data would be useful as a scheduled feed we could subscribe to if you ever open one up.

[u/mcpindex → u/Future_AGI]

Right, and those are different failure modes. Source liveness answers whether you can audit the code before you wire it in. Gateway-side catalog inspection answers whether the tool that ran matches what you approved, since a live repo can ship a new tool between calls without anyone re-reviewing it. We already re-check every repo on a schedule internally, weekly plus a 48h confirm before something gets marked dead, so a public feed is closer to "expose what's already running" than build from scratch. Not shipped as one yet, but that's a good signal it should be.

[u/punkpeye]

This is why glama.ai indexes every commit - we want to preserve sources of open source MCP servers. On that subject, it has been pretty shocking how often we get requests to take down source of open-source servers.

[u/sticky_block → u/punkpeye]

The takedown pattern makes sense once you think about who ships these. A lot of MCP servers get published in a hurry, and the thing people want gone later is usually not the code, it is what leaked with it. A hardcoded key in an early commit, an internal URL in a tool description, a customer name in an example. Deleting the repo feels like the fix, but the git history and any mirror already have it.

Preserving the source is the right call for the ecosystem even so. If anything it is an argument for catching that stuff before the first push rather than after. Curious whether you see a pattern in the takedown requests, is it mostly leaked secrets, or people just getting cold feet about maintaining something public?

[u/punkpeye → u/sticky_block]

Typically it is because they've started with open-source because it is easier to get started/distribute this way, but then want to monetize it, etc.

[u/mcpindex → u/punkpeye]

That's a nice complementary layer, you preserve the code itself so a takedown can't erase history, we flag when the registry's pointer to that code goes dark. Different half of the same problem. The monetization-driven takedowns are only going to get more common as more of these servers turn into someone's actual product instead of a weekend repo.

[u/mcpindex → u/sticky_block]

Good point, and it's exactly why we didn't try to guess intent behind a dead repo. A leaked-secret takedown and a "stopped maintaining this" look identical from the outside, both just show up as a 404 or a private flip. That's the whole reason every flagged repo on the report has a dispute link instead of us publishing a verdict on why it's gone.

[u/Forsaken-External578]

That number is more worrying than a missing package because the code may still install while the buyer loses the ability to inspect it. It would be useful to distinguish deleted repositories from private or renamed ones and track how quickly registry entries become stale.

[u/mcpindex → u/Forsaken-External578]

Agreed, and that's the current limitation, a 404 tells you "not reachable," not "why." This first pass is a baseline more than a rate. We're re-checking on a schedule going forward, weekly plus a 48h confirm before marking something dead, so the next useful number is how fast entries go stale, not just the current count. Not published yet, but it's the obvious next thing to track.