# Raw data behind the State of the MCP Registry page

Every figure on the page comes from these files. They are published so the arithmetic can
be re-walked by someone who does not trust it, which is the only version of "carefully
measured" that is worth anything.

| file | what it is |
|---|---|
| `census-2026-07-30.json` | Full-registry sweep, 2026-07-30. All 10,716 active-latest remote URLs, each with a health class and HTTP status. This is the baseline every later comparison is anchored to. |
| `successor-probe-20260803.json` | The successor probe, 2026-08-03. For every 7/30 URL that was no longer the active-latest entry on 8/2, both the old endpoint and its current successor probed in the same run. Contains the resolved pairs, the full 2×2, the four contract-continuity rows, and the raw probe result for all 1,217 URLs. |

## Method, in one paragraph

Endpoints are probed anonymously over HTTP with an MCP `initialize` handshake
(protocolVersion `2025-06-18`) followed by `tools/list`. A server counts as answering only
if `tools/list` returns a result. Servers requiring credentials return 401 and are counted
as not answering — the right reading for "can a caller use this", the wrong one for "does
this server exist"; both are recoverable from the per-URL error codes in the files.

## Known limits

- Anonymous probes only. Auth-gated servers are indistinguishable from broken ones.
- Single observation window per run. A 503 may be a deploy, not a death.
- Successor resolution uses the registry's `name` field, which is self-declared by the
  operator whose endpoint moved. Contract continuity — the stronger witness — could only be
  checked for 4 pairs, and is reported as individual rows rather than a rate.

Source for the probe scripts: the `mcp-uptime` project. Questions and corrections:
[@theopslog on dev.to](https://dev.to/theopslog).