2,069 listed MCP servers point at source code that is not publicly accessible.

On 2026-07-20 we checked every repository and website URL carried by the 17,673 servers in the official MCP registry. 1,830 of the 13,105 distinct GitHub repositories those servers reference could not be reached, one in seven. What has gone is the ability to read the code before you hand it to an agent. This census measured URL reachability only; it makes no claim about whether a package still installs.

Every MCP registry has this problem, mcpindex’s own catalog included — these are our listings. The difference is that we measure it and publish the measurement.

What we found

Why “not publicly accessible” and not “deleted”

GitHub returns the same 404 for a repository that was deleted and one that was made private. We cannot tell those apart, so we do not claim to. Both mean the same thing for the reader who matters: the source backing a tool your agent may call can no longer be audited by anyone. A maintainer who took a repository private on purpose has done nothing wrong, and the wording on every affected listing says so.

Method

1. Every repositoryUrl and websiteUrl in the 2026-07-20 registry snapshot, de-duplicated to distinct URLs (13,105 repositories from 17,673 servers).
2. Each repository probed with git ls-remote, then — this matters — corroborated through the authenticated GitHub API. Anonymous git answers a missing repository with a credential prompt rather than a 404, so a checker that trusts anonymous git alone reports zero casualties and looks healthy doing it. That bug hid all 1,830 of these from our own first two passes.
3. Only HTTP 404, 410, 451 and NXDOMAIN count as unreachable. Rate limits, timeouts, 401s, 403s and 5xx are recorded as unknown and never counted against a project.
4. A random sample of 150 was re-checked by hand through a different method (unauthenticated web), a different network, and no credentials. All 150 agreed, which bounds the false-positive rate at 2.0% (95% confidence).
5. The sweep’s result digest is stamped to Bitcoin via OpenTimestamps, so the date of this measurement is independently verifiable and cannot be backdated — including by us.

Limits

• Point in time, and confirmed. The repository counts are for the 2026-07-20 census under the same bar as every per-listing flag: two failed checks at least 48 hours apart, plus agreement from a second independent vantage. Four repositories failed the first check and passed the second, so they are not counted here. The website figure is single-vantage and does not carry that bar, as the fourth bullet says.
• Unreachability, not death dates. Most affected repositories were already unreachable when we first looked, so this is a baseline: it says these were not publicly accessible on 2026-07-20, never when they stopped being accessible. Death dates accrue only for repositories that go dark after this census.
• Deleted and private are indistinguishable. Some share of the 1,830 are deliberate, not abandoned.
• 176 websites are invisible to us. They refuse connections from datacenter networks, so we record them as unknown rather than guessing. The website figure above comes from a single vantage and is not used for any per-listing flag.
• Repositories only. A reachable repository proves nothing about a running server — it proves a URL resolves. Liveness is only ever evidence against, never evidence for.

What to do about it

If you install MCP servers as packages, an unreachable repository is a real audit gap: pin the version you already reviewed, because you can no longer diff what you are running against anything. If you connect to a hosted server, the repository was never the code that executes — treat it as context, not as a reason to disconnect. Affected listings say which case applies, and maintainers can dispute any flag from the listing itself.

Cite this

The full dataset — aggregates, the per-server list, and the OpenTimestamps proof — is archived with a DOI and a CC-BY-4.0 license. Paste the BibTeX into your .bib file:

@dataset{bharti2026liveness,
  author    = {Bharti, Gautam},
  title     = {mcpindex Source Liveness -- Baseline v1: a corroborated, timestamp-anchored
              census of source reachability in the Model Context Protocol registry},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21501867},
  url       = {https://doi.org/10.5281/zenodo.21501867},
  note      = {Concept DOI; resolves to the latest version. CC-BY-4.0. Live: https://mcpindex.ai/research/source-liveness}
}

Concept DOI (series): 10.5281/zenodo.21501867. First-edition version DOI: 10.5281/zenodo.21501868.

Method and limits: how a verdict is produced. Corrections and disputes: hello@mcpindex.ai.

  listed servers                    17,673
        |  extract referenced source repositories
        v
  referenced GitHub repositories    13,105
        |
        +-- vantage A --+
        |               +-- 0 cross-vantage disagreements (48h debounce)
        +-- vantage B --+
        v
  not publicly reachable            1,830  (14.0%, one in seven)
        |
        v
  listed servers affected           2,069

  census date 2026-07-20. digest anchored to bitcoin via OpenTimestamps.
  CC-BY-4.0, DOI 10.5281/zenodo.21501867 (concept DOI - resolves to the current version).
  NEGATIVE-ONLY evidence: an absent entry means nothing publishable, never
  "verified healthy" - a reachable repo proves only that a URL resolves.

  verdict --sha256--> entry --chained to prior--> daily digest --OTS--> bitcoin block
                                                                            |
                                                          ~10 min ----------+ pending
                                                          ~1 hour ----------+ N=6, final

  PROVES     the verdict existed by some block. the chain is auditable end to end.
  DOES NOT   prove minute-level ordering inside the confirmation window.
             confirmation-depth checking is the relying party's job, against
             their own bitcoin node.