Two days ago I catalogued the tool surface of the public MCP registry: a random sample of 500 live servers, 477 inventories captured, every tool's inputSchema
hashed.
Today I re-ran it against the same servers — same seed, same sample — and diffed the hashes.
21 of 475 comparable servers changed their tool contract in about 36 hours. That's 4.4%.
| Change | Servers |
|---|---|
| Schema changed on a tool that already existed | 15 |
| Tools added | 9 |
| Tools removed | 1 |
The middle row is the boring one. Adding a tool is safe — nothing that worked yesterday stops working.
The other two are the problem.
Fifteen servers changed the inputSchema
of a tool that kept its name. Among them:
get_model_pricing modelpricewatch.com
poll_for_upload ai.moda/mcp-servers/remote-camera
search_incidents gateway.pipeworx.io/ai-incident-db
wsdot_get_toll_rates wsdot.caseyjhand.com
get_article childadhd.ai
list_deputies gateway.pipeworx.io/nosdeputes-fr
If your agent discovered get_model_pricing
yesterday and cached what it looked like, it is now calling that tool with the wrong shape. Nothing announced this. The server is up. The tool is there. The name is identical. Uptime monitoring reports a perfect green.
You find out at call time, inside a run, and it surfaces as an argument validation error or — worse — as a model that appears to have hallucinated a parameter. That is a miserable thing to debug, because every instinct points at your prompt rather than at a third party's schema changing under you.
One server dropped a tool entirely: invite_user_by_email
, gone from mcp.argo.games
. That one at least fails loudly.
I measured 4.4% over a 36-hour window. That is the honest statement, and I want to be careful about what gets built on top of it.
You could naively annualise it — a constant independent 2.9%/day implies roughly 59% of servers changing within a month — and I do not think you should trust that number, including from me. Schema changes are not independent coin flips. They cluster: an actively developed server changes many times, a dormant one never changes at all. The 21 servers that moved this week are disproportionately the ones that will move next week too.
So the useful claim is narrower and still striking: on any given day, a couple of percent of the MCP servers you depend on will alter their tool contracts, and the majority of those changes will be invisible to anything that checks whether the host is up.
The way to get a real number is not a better extrapolation. It is more snapshots. I will keep taking them.
I have now measured three things about this registry: about a quarter of endpoints don't serve an anonymous client, failure concentrates by hosting platform, and now that contracts move underneath you at a few percent per day.
I started out assuming downtime was the interesting failure. It isn't. Downtime is loud, and you find out immediately. The interesting failure is the server that is definitely up and no longer does what your agent learned it does.
That reframing came from a reader, not from me. On the census post, Mads Hansen argued I should stop collapsing results into reachable-vs-broken and track four orthogonal states instead: transport reachability, protocol negotiation, authenticated behaviour, and contract compatibility. A 401 is positive evidence for the first two and says nothing about the last two. He was right, and this post is basically the fourth state getting measured for the first time.
Random sample of 500 endpoints drawn from the 5,346 registry-listed servers that complete an anonymous handshake, random.seed(20260730)
so the re-run hits the same servers. For each: initialize
→ notifications/initialized
→ tools/list
, handling SSE-framed responses and threading Mcp-Session-Id
on follow-ups (several servers require both, and you get an empty inventory if you skip either). SHA-256 of each tool's inputSchema
, sorted keys.
Baseline 2026-07-30, re-run 2026-08-01, 475 servers comparable in both. Two dropped out of the readable set and one came back — I excluded all three rather than guess what happened.
Snapshots are moments, not truth. Two of them are a line, not a trend. This is the second.