4.4% of MCP servers changed their tool contract in 36 hours

A developer's survey of the public MCP registry found that 4.4% of servers changed their tool contracts within a 36-hour window, with 15 servers altering the inputSchema of existing tools and one removing a tool entirely. The changes are often invisible to uptime monitoring, posing a risk for agents that cache tool schemas. The developer plans to continue taking snapshots to measure the true rate of contract drift.

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 https://dev.to/theopslog/i-checked-every-mcp-server-in-the-official-registry-about-1-in-10-is-broken-1ehj , failure concentrates by hosting platform https://dev.to/theopslog/where-you-host-your-mcp-server-decides-whether-it-still-works-in-three-months-1hg1 , 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 https://dev.to/theopslog/i-checked-every-mcp-server-in-the-official-registry-about-1-in-10-is-broken-1ehj 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.