The 27% problem — and why I published 55% instead
A note on measuring the thing you're about to make a claim about, written by the person who runs this observatory. Dated 2026-08-13.
I had a number I liked. A 300-server random sample of the official MCP registry suggested only 27% of servers actually speak MCP. A great, publishable, screenshot-ready scandal.
Before I published it, I did the one thing the headline demanded of everyone else: I checked it. I wrote a versioned probe, pointed it at every server in the registry with a reachable address — all 10,813 — and sent each a real initialize handshake, then tools/list. Single pass, 12-second deadline, no retries, an honest User-Agent, method and script published.
The sample was wrong. The full census says 55% complete a real handshake. I'm publishing that correction with exactly the energy I'd have published the scandal — because the gap between the two numbers is the actual finding: one-off, unversioned measurements of this ecosystem cannot be trusted, mine included. The registry moved under me in a day; a 1,312-listing publisher flipped from all-403 to all-alive between the sample and the census. A number with no standing, reproducible instrument behind it is a screenshot, not a measurement.
What the census actually shows
- 21,000+ listings from 13,000+ publishers. 10,813 expose a remote address; the rest are local packages or empty listings.
- 55% of remote endpoints answer a real handshake. A quarter demand a login — alive, but uncheckable from outside. The rest error, don't resolve, or return something that isn't MCP.
- The alive endpoints collapse onto ~4,200 real hosts. One gateway — pipeworx.io — wears 1,312 registry listings, 22% of every live endpoint, all serving the same templated tools behind different names. A liveness checker scores it 100/100. Only fingerprinting the tool inventories and collapsing by host sees the costume.
- Of the alive servers, a literal handful speak the current (2026-07-28) protocol.
The registry, by its own FAQ, does not curate, does not health-check, and cannot delete a server. The directories that grade servers don't publish their methods. So platforms are choosing tools, and enterprises are whitelisting endpoints, off vibes.
What I did about it
I stood the measurement up as a permanent instrument instead of a screenshot. It re-probes on a schedule, holds a drift baseline — per-tool description hashes for every tool-serving server, so a tool quietly changing what it does (a rug-pull) is detectable — and it goes one layer deeper than "is it alive": it checks whether a server's answers are true, re-derived against a public primary source. 69 of 75 answers I could check this way matched the official source — US duty rates against the USITC schedule, EU trade values against the raw Eurostat file (to the euro), reference codes against ICC/WCO/UNECE/ISO. Most tools have no public source and can't be checked at all; I say so.
And a nuance the truth checks surfaced: that same pipeworx costume farm, asked for a US duty rate, returns the correct USITC number — 14 of 14. Costume naming, real data. A name check or a liveness check tells you neither; only re-deriving the answer does.
What's checkable here
Everything above is on robinsaige.com: the method and the probe script, the ruled findings with their falsifiers, the data with the SQL that produced each number, and — because a verifier that never published a mistake is the one you shouldn't trust — a corrections log that launched non-empty. It already holds 10, two of them my own; the 27%→55% miss is the first. This observatory is itself an MCP server (com.robinsaige/verifier), listed in the registry it measures, so it appears on its own scoreboard by the same rules.
Probed from a single vantage (disclosed bias: single pass, zero retries — the alive share is a lower bound). Same discipline I point at trade data for a living; here it's pointed at the infrastructure the instruments live on.