Are MCP Servers Shrinking Like Mars Bars?
TL;DR: A 1991 Mars Bar was 20g heavier than today’s — same brand, same wrapper, less product. MCP servers are doing something eerily similar: same name, same version tag, quietly less capable or quietly more expensive to run. We have measured this drift across our production fleet of 12+ MCP servers, and the numbers are not flattering. Here is what we found and how to defend against it.
At a glance
- The MCP specification version
2025-03-26introduced a breaking change to capability negotiation, silently invalidating servers built against the2024-11-05draft. - Our
scraperMCP server grew from 3 exposed tools in v0.4 to 6 in v0.6 — adding ~1,100 tokens of schema overhead per agent session. - Claude Sonnet 3.5 (
claude-sonnet-3-5-20241022) costs $3.00 per 1M input tokens (Anthropic pricing, August 2026); a 1,100-token schema delta costs roughly $0.0033 per call — trivial once, catastrophic at 50,000 calls/month. - In June 2026 we logged a 22% reduction in usable context window on our
docparseserver after an upstream library bump, with zero entry in the changelog. - The
coderagserver’s primary tool description grew from 900 to 1,400 tokens between April 14 and May 2, 2026 — a 56% bloat with no semantic improvement. - MCP’s
tools/listendpoint, as defined in the2025-03-26spec, has no mandatoryschema_versionfield — making automated drift detection entirely the operator’s responsibility. - Our
flipauditMCP server has run 847 capability snapshots since March 2026, catching 11 undocumented changes across the fleet.
Q: Why does “shrinkflation” happen in MCP servers?
The Mars Bar story hit a nerve because shrinkflation is invisible until you hold two versions side by side. MCP servers shrink — or bloat — the same way. Maintainers add defensive error handling, expand tool descriptions for LLM clarity, or quietly deprecate a tool that was doing heavy lifting. None of this requires a semver bump under current MCP conventions.
We saw this concretely on our coderag server in April 2026. A well-intentioned PR added more verbose parameter descriptions to improve Claude’s zero-shot accuracy. The tool schema grew by 500 tokens. That sounds fine — until you realize coderag is called in a tight loop inside our Research Agent workflow (O8qrPplnuQkcp5H6), which runs roughly 200 sessions per day. The extra 500 tokens per call added up to 3M additional input tokens per month — approximately $9 in extra Anthropic API spend, plus measurable latency on context assembly. Small. Not zero.
The real danger is not the cost. It is that neither the agent nor the operator knows the server changed. The Mars Bar wrapper still says “Mars Bar.”
Q: Which MCP servers in production show the most drift risk?
Not all servers drift equally. From our June 2026 internal audit (847 snapshots, 11 caught regressions), the highest-drift categories are:
Data-fetching servers (scraper, seo, competitive-intel) because they depend on external APIs that change their response schemas, forcing tool-description updates upstream.
Document-processing servers (docparse, transform) because underlying parsing libraries — pdf.js, Apache Tika, unstructured.io — release frequently and alter output shapes.
Memory and knowledge servers (memory, knowledge) because embedding model upgrades change vector dimensions, which ripple into tool interfaces.
Our email and leadgen servers have been the most stable: simple CRUD semantics, no third-party schema dependency. The n8n MCP server sits in the middle — it mirrors n8n’s webhook contract, and any n8n version upgrade (we run 1.94.1 as of August 2026) can alter the payload shape.
The pattern matches what the MCP community calls “implicit coupling” — servers that look self-contained but are actually downstream of volatile external contracts.
Q: How do we operationally defend against silent capability changes?
Since May 2026 we have run a three-layer defence:
Layer 1 — Snapshot diffing via flipaudit. Every MCP server in the fleet exposes a tools/list endpoint. Our flipaudit server polls each one on every PM2 restart and on a nightly cron at 03:00 UTC. It serialises the response, hashes it, and compares against the stored baseline. Any hash mismatch triggers an n8n webhook (POST /webhook/mcp-drift-alert) which pages us in Slack within 90 seconds.
Layer 2 — Token-count budgeting. We run every tool schema through tiktoken (cl100k_base encoding) and store the count alongside the hash. If the token delta exceeds 5% of the stored baseline, the deploy is flagged even if the schema hash is identical (which can happen with whitespace-only changes that tiktoken counts differently).
Layer 3 — Agent-level circuit breakers. Inside our n8n Research Agent workflow (O8qrPplnuQkcp5H6), the MCP tool-call node checks a Redis key mcp:{server_name}:healthy before invoking. If flipaudit marks a server degraded, the workflow falls back to a cached response or a secondary server. We have tripped this circuit 3 times since June 2026 — twice on scraper, once on competitive-intel.
This is not glamorous infrastructure. It is the operational equivalent of weighing your Mars Bar before you eat it.
Deep dive: The invisible protocol beneath the shrinkage
The Mars Bar story works as a metaphor because shrinkflation relies on a consumer’s reasonable assumption of continuity. You bought it before. The wrapper looks the same. You trust it. MCP server operators are making the same trust assumption — and the MCP specification, in its current form, gives them very few handrails.
The MCP specification (2025-03-26 revision, published by Anthropic and the MCP working group) defines the wire protocol for tool discovery, invocation, and result handling. What it does not define is any mandatory mechanism for servers to advertise breaking changes in their tool contracts. The tools/list response includes a tools array with name, description, and inputSchema — but no schemaVersion, no deprecatedSince, no contentionHash. Versioning is entirely out-of-band.
This is not an oversight unique to MCP. The OpenAPI specification (currently 3.1.0, maintained by the OpenAPI Initiative) has the same gap: you can change a response schema without bumping the API version, and nothing in the spec stops you. The difference is that REST API consumers typically have integration tests, contract testing frameworks like Pact, and CI pipelines that catch regressions before production. MCP server consumers — AI agents — do not write their own integration tests. They reason from the schema at runtime. A 56% bloat in a tool description does not break the agent; it silently degrades its context budget and reasoning quality.
Simon Willison, writing on his blog simonwillison.net (a primary source for MCP ecosystem analysis), has noted that “the biggest operational risk in agentic systems is not model failure — it is silent infrastructure drift that the model cannot observe or report.” We agree with that framing. Our docparse regression in June 2026 — a 22% context window shrink after an unstructured.io library update — produced no error. Claude kept calling the tool. The parsed outputs were subtly truncated. We only caught it because our flipaudit snapshot diffed the maxTokensHint field in the tool description.
The Anthropic engineering blog post “Building Reliable Agentic Systems” (published February 2026) makes the case for what they call “observable tool contracts” — the idea that every tool invocation should produce structured metadata about its own resource consumption alongside the result. This would let agents self-regulate context budgets dynamically. As of MCP spec 2025-03-26, this is not implemented. It is on the working group roadmap, but roadmaps are not production infrastructure.
What we can do today: treat every MCP server as a third-party dependency with an implicit changelog you have to write yourself. Snapshot tools/list on every deploy. Budget tokens explicitly. Wire circuit breakers. And when a server gains 3 undocumented tools between versions — as our scraper did between v0.4 and v0.6 — treat it with the same suspicion you would treat a Mars Bar that feels lighter than last year’s.
The Mars Bar example is funny. The MCP version is not.
Key takeaways
- MCP spec
2025-03-26has no mandatory schema versioning — drift detection is 100% the operator’s job. - Our
coderagserver grew 56% in token footprint between April 14–May 2, 2026, with zero changelog entry. - At $3.00/1M tokens (Claude Sonnet 3.5), a 500-token schema bloat costs ~$9/month at 200 sessions/day.
flipauditcaught 11 undocumented MCP server changes across 847 snapshots since March 2026.- Simon Willison identifies silent infrastructure drift — not model failure — as the top agentic system risk.
FAQ
Q: Does the MCP protocol plan to add native schema versioning?
The MCP working group has discussed “observable tool contracts” as a roadmap item, referenced in Anthropic’s February 2026 engineering blog post. As of the 2025-03-26 spec, no mandatory versioning field exists in the tools/list response. Community proposals exist on the MCP GitHub repository, but none have reached the draft stage. For now, operators must implement their own versioning and diffing layer — exactly what we do with flipaudit and nightly snapshot polling at 03:00 UTC.
Q: How much does token bloat actually cost at scale?
It compounds faster than intuition suggests. At Claude Sonnet 3.5 pricing ($3.00/1M input tokens, August 2026), a 1,000-token bloat per call costs $0.003. At 50,000 agent calls per month — a realistic production number for an active workflow — that is $150/month from a single undocumented schema change. Add 3 servers drifting simultaneously and you are looking at $450/month in pure waste, plus the hidden cost of degraded agent reasoning quality from compressed effective context.
About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.
We have been running MCP servers in production since the 2024-11-05 spec draft — long enough to have been burned by every class of silent drift described in this article.