The 72,000-Token Invisible Tax: What Really Happens When You Load 10 MCP Servers
If you've been using Claude Code, Cursor, Windsurf, or Codex CLI with MCP (Model Context Protocol) servers, you might have noticed something strange lately:
Even on a brand new, empty turn — before you write a single line of code — your context window is already packed, response latency feels sluggish, and your token burn rate is higher than expected.
We measured the exact payload across 50 production MCP servers. Here is what we found, why it happens, and how modern token compression drops that overhead by 99.8%.
The Measurement: Where Did 71,929 Tokens Go?
When you connect an MCP server to an AI host, the client requests the tools schema via tools/list. The server returns JSON schemas describing each tool, parameter types, nested objects, and documentation strings.
Here is the measurement from 10 common MCP servers in a typical developer workflow:
- File system toolset: ~4,200 tokens
- Git / GitHub integration: ~8,800 tokens
- Database / PostgreSQL introspection: ~12,400 tokens
- Terminal / Shell execution: ~3,100 tokens
- Web search / scraper toolsets: ~14,500 tokens
- API & Slack notification wrappers: ~28,900 tokens
Total uncompressed payload injected on every conversation turn: 71,929 tokens.
If you are paying typical API pricing on top-tier frontier models (such as Claude 3.7 Sonnet at $3.00 / million input tokens), this baseline schema injection costs:
- $0.21 per turn just for the tool definitions
- Over 100 turns in an intensive coding session: $21.00 wasted on unchanging tool definitions
More importantly, it robs your agent of working memory.
Why JSON Schema Is the Wrong Format for LLM Context
JSON Schema was built for deterministic validation in distributed REST APIs, not for autoregressive language model attention heads.
It is notoriously verbose:
-
Repetitive punctuation & syntax keys:
"type": "string","properties": { ... },"required": [...] - Deep nesting: Up to 6 levels of curly braces and indentation for simple parameters.
- Type boilerplate: A simple function taking a filename and integer line number takes 40+ tokens of raw JSON.
LLMs don't need JSON validation schemas to understand how to call a tool; they understand compact functional signatures:
def execute_query(sql: str, timeout_ms: int = 5000) -> dict
The Compact Schema Solution: Dropping from 71,929 to 124 Tokens
By applying AST schema distillation and compact schema projection (an open-source approach implemented in the mcptoon tool), you don't send the raw multi-thousand-line JSON.
Instead, the client compiles the tool definitions into a compacted representation:
- Strips redundant schema wrappers
- Inlines type annotations
- Prunes inactive parameter descriptions on initial load
- On-demand hydrates full schemas only when the tool is actively selected by the model
The Results:
- Uncompressed schema: 71,929 tokens
- Compacted schema: 124 tokens
- Token reduction: -99.8%
- Latency improvement: Time-to-first-token (TTFT) dropped by 64% in our local benchmarks.
Key Lessons for Agent Builders
If you are designing agentic systems or orchestrating multiple MCP servers:
-
Audit your tool payload size: Run a token counter on your
tools/listresponse. You might be surprised at how much dead weight is being transmitted. - Avoid dumping raw schemas: Use functional representations or deferred schema resolution.
- Preserve context budget for actual thinking: The model does its best reasoning when the context is clean and focused on code, not schema boilerplate.
How are you handling tool payload bloat in your multi-server MCP setups? Would love to hear other strategies in the comments below.
Top comments (2)
The per-turn framing ($0.21/turn, $21 per 100 turns) makes the abstract concrete — nice. One thing to add: the tax compounds with subagents. Every Task() call re-sends the full schema payload per request, so a 15-subagent fan-out multiplies your 72K by 15 before anyone reads a file. I built subagent-tax to attribute exactly that from transcripts. Your compact-schema approach (71,929 down to 124) is the ambitious fix; the boring fix that worked for me was mcp-tax style: measure per server, switch off the ones the session doesn't need. Different leverage points on the same bill.
Good catch — the subagent multiplier is the part I under-counted, and it changes the fix. In my runs the tool block is re-sent per request, so fan-out multiplies it roughly linearly, not once. That's what pushed me from "shrink the schema" to "keep a name index resident, fetch the body only on call": a ~600-token index is cheap to re-send 15 times, a 72K schema block is not. How does subagent-tax attribute it — the inherited tool block once per Task(), or once per turn inside each subagent? Those two numbers differ a lot in my setup.