One developer opened a Claude Code session with 10 MCP servers configured and watched 164,000 tokens disappear before typing a single character. That setup - 10 MCP servers, 212 tools - consumed 82% of the available context window before a word was typed. The work hadn't started. The money was already spent.
This is the MCP context tax, and it has become the dominant operational problem for teams that have moved past MCP as a curiosity and started using it seriously.
Why MCP schema injection is the new token leak
The mechanics are simple. MCP was designed for discoverability: when an agent connects to a server, it receives the full schema of every available tool. That is powerful for exploration, but expensive for execution. A well-documented tool burns 500-1,500 tokens on its own. A server with 50 tools consumes 25,000-75,000 tokens. Stack several servers together and the math becomes brutal.
The GitHub MCP server is the canonical example. For the simplest possible task - "what language is this repo?" - the CLI agent needs 1,365 tokens. The MCP agent needs 44,026. The difference is almost entirely schema: 43 tool definitions injected into every conversation, of which the agent uses one or two.
Apideck's production data made this concrete. In a deployment connecting GitHub, Slack, and Sentry MCP servers - just three, totaling roughly 40 tools - 143,000 of a 200,000-token context window were consumed by tool schemas. That is 72% of the available context burned before a single user query was processed.
The schema overhead is not a bug in any one server. It is the default behavior of the protocol. The MCP host loads everything it knows at startup. The model reads all of it, every time.
The cost in dollars, not just tokens
Scalekit replicated a controlled experiment on Sonnet 4 at 10,000 operations per month and recorded $3.20 for CLI versus $55.20 for MCP, a 17x gap on identical workloads. The benchmark ran 75 trials and was statistically significant.
At production scale, the numbers compound fast. At a 200-engineer team paying typical rates, the context tax alone is roughly $220 per working day, or about $55,000 per year, before any productive work tokens. That is the overhead for having tools registered. Not for using them.
The dollar gap is real enough that Perplexity's engineering team made it a public decision point. In March 2026, Perplexity CTO Denis Yarats publicly announced that Perplexity was moving away from MCP for internal production systems, citing context window consumption and authentication friction as two blockers. For a company running AI queries at scale, paying a 72% context tax per session was operationally untenable.
This created a genuine debate in the developer community - not about whether MCP is useful, but about whether the default behavior was ever supposed to be the production behavior. The "dump everything into context" approach was always a prototype shortcut. Production was never supposed to work that way.
What Claude Code's MCP Tool Search actually changed
Anthropic's Thariq Shihipar announced MCP Tool Search on January 14, 2026.
Claude Code 2.1.7 introduced it as a lazy loading mechanism that reduces token consumption by 85%.
The mechanism: instead of loading all tool definitions at session start, Claude Code loads a lightweight search index and fetches tool details on-demand when you actually need them.
Tool Search activates automatically when your MCP tool descriptions would use more than 10% of your context window.
The token savings in Anthropic's internal testing: from ~134K to ~5K. That is an 85% reduction while maintaining full tool access.
MCP Tool Search is now enabled by default for all users. You do not need to opt in.
Run /context in a Claude Code session to see live token usage, or /doctor for a per-server breakdown.
Beagle in action#engineering, 10:02amThe fix is real. But it trades one problem for another, smaller one.
The agent can fail to retrieve the right tool from search because the description doesn't match the model's paraphrase of intent. Both are mitigated by writing tighter descriptions and naming tools well.
A server with vague tool names - do_thing, run_query - will see more misses than one with precise, action-oriented names.
There is also the question of the server_instructions field, which most server authors have treated as optional boilerplate.
It acts as the metadata that helps Claude know when to search for your tools, similar to skills. Previously a "nice to have," it is now critical.
Three things to actually do about it
The fix is on by default in Claude Code, but the underlying architecture problem affects any host that hasn't implemented lazy loading.
If you are using Claude Code: Upgrade past v2.1.7 and verify Tool Search is active with /context. Check that your MCP servers have specific server_instructions and clearly named tools. The tool search is only as good as the descriptions it indexes.
If you are building a custom MCP server: Token efficiency is three problems at three architectural layers: server-side verbosity in tool schemas, protocol-level support for lazy or filtered discovery, and host-side filtering before anything hits the context window. You control the first layer. Write tight tool descriptions. Each tool is a retrieval candidate, not a README.
If you are deciding whether to use MCP or CLI: The CLI-vs-MCP debate benchmarks the 5% of integrations where the comparison makes sense. The other 95% are SaaS systems where no CLI exists and never will. There is no Workday CLI. There is no Greenhouse CLI. For those systems, the question is not CLI vs MCP - it is how to use MCP without paying the full schema tax.
The ecosystem has crossed 22,000 MCP servers. It has moved from 2025's "wild proliferation" into 2026's infrastructure phase. That maturation means the defaults that were fine for demo setups are now the biggest cost line that no one budgeted for. The fix exists - lazy loading works - but it requires server authors to treat their tool descriptions as search documents, not documentation.
MCP context window token cost: common questions
What is the MCP context tax?
Every MCP server sends its full tool schema - names, parameter types, descriptions - to the model at session start. This happens before any work begins. A server with 50 tools can burn 25,000-75,000 tokens on schemas alone. Connect three servers and you can lose 70% of a 200K context window to definitions.
How much more expensive is MCP than CLI for the same task?
Scalekit's benchmark measured the simplest possible task at 1,365 tokens via CLI and 44,026 via MCP - a 32x difference driven almost entirely by schema injection. At 10,000 operations per month on Sonnet 4 pricing, that translates to $3.20 via CLI versus $55.20 via MCP.
What is Claude Code's MCP Tool Search and does it fix this?
Claude Code 2.1.7 introduced MCP Tool Search, a lazy loading mechanism that reduces token consumption by 85%. Instead of preloading all tool schemas, it builds a lightweight index and fetches definitions only when the agent needs a specific tool. It is on by default; no configuration is required.
Does lazy loading hurt agent performance?
It can, if tool descriptions are vague. The agent now searches for tools by description match rather than scanning a full list. The agent can fail to retrieve the right tool if the description doesn't match the model's paraphrase of intent. Tighter descriptions and precise naming mitigate both problems.
Should I stop using MCP and switch to CLI?
CLI is an invocation mechanism; MCP is an integration protocol. Saying "CLI is better than MCP" is like saying "cURL is better than OAuth." They operate at different layers, and production architectures need both. For SaaS systems with no CLI equivalent, MCP with lazy loading is the correct path.