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%.
What changed
| 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.
The dangerous category is the quiet one
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.
What this rate does and does not mean
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.
Why I care about this more than the uptime numbers
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.
Method
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.
Top comments (2)
This fourth axis is already useful. Two refinements would make the next snapshots even stronger. First, “tool added” is not always behaviorally safe for an agent: a new overlapping tool can change selection, increase catalog cost, or redirect calls that previously went elsewhere even though old invocations still validate. Second, a schema hash tells you that syntax moved, not the compatibility direction. Classify diffs as required-field added/removed, enum narrowed/widened, type/default/constraint changed, and replay a small corpus of previously valid calls against the new schema. I would also hash tool descriptions separately, because semantic behavior can drift while
inputSchemaremains byte-for-byte compatible. That gives consumers actionable states: compatible expansion, selection-risk change, validation break, or semantic-only drift.This is the MCP failure mode I worry about most. A renamed or deleted tool is noisy. A same-name schema drift makes the agent look confused, so the debugging path starts in the prompt instead of the dependency. I would probably snapshot schemas as build artifacts and fail fast when the contract hash moves.