How MCP tool contracts change in the wild

Live since Edition v1

Everything below is auto-derived from the crawl corpus on every pipeline run - never hand-copied - and has accrued since the frozen edition above. Last derived 2026-07-22 (UTC).

What changed: 2,518 deduped incidents by kind

An incident is one (server, tool, change kind) triple, deduped across the whole window - the same tool changing the same way on five days counts once, with its occurrence span retained. Raw events observed: 63,471, of which 3,100 touched a safety-relevant contract field.

Did the version move? The silent share, with its basis

For each incident we join the server's declared version across the pair of snapshots where the change first appeared. The silent share - the share of incidents that landed with the declared version unchanged - is 62.3%. Basis: deduped safety incidents, first-occurrence delta. That basis matters: the /ledger lede counts per-tool version behavior over every observed transition, a different (also labeled) basis, so the two numbers are reconcilable rather than interchangeable.

Version unchanged across the change

1,569 · 62.3%

Version changed with the change

949 · 37.7%

No version declared at either snapshot

0 · 0%

"Version changed" means the declared version string differed across the pair - direction is never computed, so no claim about upgrades is made. A change arriving with an unchanged declared version is an observation about version behavior, not an accusation of intent.

Annotation flips: first labels vs changed guarantees

123 incidents flipped a tool to destructive. They split two ways: 68 were first-labelings - the old tool record carried no annotations block at all, so the flip is a server declaring safety hints for the first time, the ecosystem's labeling maturing - and 55 were guarantee changes, where an existing annotations block moved to destructive. First-labeling is the majority: most flips read as labels maturing, not guarantees changing. The segmentation below crosses each flip class with its version behavior.

Removals: mostly replacement, rarely deletion

878 tools were removed (879 removal events - a tool can be removed, return, and be removed again). 740 (84.3%) were part of a toolset replacement - the same server shed five or more tools in one snapshot pair, typically an API redesign - while 138 were single-tool removals. The copy follows the data: replacement is the dominant reality; the rare single deletions are the events worth a second look. Removal entries are historical observations - a same-named tool may have since returned.

Unstable contracts, counted apart

78 tools serve unstable contracts (104 incidents, 5.8% of events): the contract changed on five or more distinct days, reverted to an earlier hash, or churned its hash while the schema stayed the same (dynamic metadata). Counting an oscillating contract as fresh drift every day would inflate the numbers, so the unstable class is excluded from the headline counts and reported here as its own finding. Excluding it, the deduped incident count is 2,414 and the share landing with the declared version unchanged rises to 63.3% (same basis as above) - the segmentation strengthens the headline rather than propping it up.

Coverage, stated honestly

This corpus is 25 snapshots across 42 days (2026-06-09 to 2026-07-21, 24 adjacent pairs), including a 21.1-day gap (2026-06-20 to 2026-07-11) when the crawler was down. It is not an unbroken daily series and we do not present it as one: incidents are deduped across the gap rather than papered over it, and changes that happened entirely inside the gap window were never observed.

Methodology

• Population: roughly 2,090 reachable remote servers of the indexed official registry. Indexed and crawled are different populations - a local-only or unreachable server never appears here, and absence from this report is not a clean bill of health.
• Merge per name: registry entries sharing one name are merged to a single record before diffing (winner: reachable, then most tools; other endpoints retained as alternates), so two deployments contending for one name can never mint phantom drift against each other.
• Flap guard: each snapshot pair is scoped to servers reachable in both snapshots before diffing, so a server flapping out of reachability never reads as mass tool removal.
• Dedup: incidents are one (server, tool, change kind) triple with first-seen / last-seen / occurrence count. Version behavior is joined per incident from the snapshot pair where it first appeared, anchored on content hashes.
• Unstable exclusion: five or more distinct change days, a hash revert, or a dynamic-metadata signature flags a tool unstable; the class is excluded from headline counts and reported separately above.
• Anonymization: tools and servers are salted fingerprints on every public surface of this dataset. This page names no server; per-server context lives on the named server pages with their own fairness labels.

The full pipeline, taxonomy, and disclosure history: /methodology.

Appendix · the census behind these numbers

These numbers are observations after the fact.

The report tells you contracts change underneath agents; it cannot stop the next one. The gate pins every tool contract your agent uses on first sight and holds the call when a pinned contract changes - the check that keeps being true on Tuesday.

See your first HOLD in 2 minutes →

Background: silent contract drift · mcp.lock

For platform teams

mcpindex is a policy layer for MCP adoption. Pin every approved server's tool contracts at adoption time, so what your agents run is what you reviewed. The gate holds a call when a pinned contract changes underneath it - including changes that arrive with the declared version unchanged - until someone re-approves. The receipts page is the audit artifact: per-install evidence of what was held and why. All of it is a deterministic contract diff, never a safety verdict, and the methodology is public.

Evaluating MCP trust for a team? Email gb@mcpindex.ai - early design partners get input on the roadmap.