How these numbers were measured

13.3% of the endpoints the official MCP registry declares fail the MCP initialize handshake: 2751 of 20717, measured on 2026-09-17. The listing was walked to the end - 32835 entries - rather than sampled.

Separately, 4.4% of the npm and PyPI packages those entries name are not installable as named: 557 of 12775. Nothing was installed to find that out - the package registry's own document says whether the package and the declared version exist.

Why published figures for this disagree

Figures for how much of the MCP ecosystem is broken range from about one in ten to more than half. They are not measuring the same thing, and the number moves for three reasons before anyone probes anything.

• The denominator. Entries, or entries declaring a remote endpoint, or endpoints? Those are three different numbers for one registry, and dividing by the smallest triples the rate.
• The definition. Does a server that demands authentication count as broken? Does an abandoned repository? Each answer is defensible and each produces a different figure.
• How much was read. A listing capped before its end is a prefix, and a rate over a prefix is a rate over whatever happened to be first. This registry's own coverage claim was wrong twice for that reason, which is why every harvest now records what it examined next to what it found.

So the figure above is published with its denominator attached, and every record carries the request that produced it. You are not asked to accept the rate; you are given what you need to recompute it.

What was deliberately not counted

Each of these was produced by this registry's own harvesters and then rejected. They are the difference between a defect and a thing that merely failed.

A server that answers 401 with a usable challenge

167 of 171 endpoints in one commercial catalogue refuse an anonymous handshake with a 401 carrying WWW-Authenticate and a resource_metadata pointer that resolves. That is the MCP authorization specification working. Counting it would have published 272 false claims in an afternoon.

A server that demands payment

402 means something is there to pay for. It is alive.

Anything we were rate-limited out of

429 is our own crawl pressure, never the subject's defect.

A package we did not install

Two thirds of the MCP registry ships only as an installable package. Nothing is ever installed to inspect it, so what is checked is whether the package registry publishes the package and the exact version the entry declares - not whether the code works.

A deprecated package, counted apart from a missing one

A deprecated package installs and runs, and its registry usually names the replacement. It is recorded, under its own kind, and never folded into 'there is nothing to install'.

A response we could not read as a defect

405, 406 and 400 can mean our request was at fault. A registry that blames the subject for its own malformed call is measuring itself.

An operation nobody examined

Absence from this registry is absence of observation. It is never published as health.

What a record contains

A claim, what was observed, and a check: a method, a URL and the result we saw. Run the check. If it answers differently, the record is withdrawn - 40 already have been. Nothing here asks to be believed.

Records are re-checked nightly and never deleted. A withdrawal is not a claim of health: it means this particular check stopped supporting this particular claim.

The open classes, by size

Built from errata-2026-09-10@21826040e38a on 2026-09-10. The whole registry is machine-readable, and llms.txt says the same thing in one screen. To ask about one tool: /check?tool=<identity>.

All subjects