Stack three MCP servers in Claude Code and you can burn through 143,000 of a 200,000-token context window before your agent has done a single thing useful. That is not a fringe misconfiguration. It is the default.
The Model Context Protocol now has over 22,000 publicly listed servers - a number that felt impossible eighteen months ago, and that has turned MCP into genuine infrastructure. But the speed of adoption has outrun a structural problem that most teams only notice when their inference bill arrives.
Why MCP blows up your context window
When an agent connects to an MCP server, it receives the complete schema of every tool that server exposes. The agent gets the full schema of every available tool. This is powerful for exploration - the agent can see everything it could potentially do - but expensive for execution.
GitHub's MCP server illustrates the problem concretely. GitHub's MCP server ships with 93 tools totaling approximately 55,000 tokens of schema definitions. That is roughly half of GPT-4o's context window consumed before you ask a single question.
For the simplest query - "What language is this repo written in?" - CLI used 1,365 tokens while MCP consumed 44,026. That is a 32x difference. Even the best-case scenario (checking CI status) showed MCP using 10x more tokens than CLI.
That gap is almost entirely schema, not output. The difference is almost entirely schema: 43 tool definitions injected into every conversation, of which the agent uses one or two.
The problem compounds when you install several servers at once. One team reported three MCP servers consuming 143,000 of 200,000 available tokens - 72% of the context window burned on describing what the agent could do, leaving barely enough room for what it should actually do.
The benchmark numbers, and what they do and don't prove
The Scalekit benchmark (75 runs, Claude Sonnet 4, statistically significant at p < 0.05) showed MCP costing 32x more in tokens for simple tasks. The repo is public on GitHub and the methodology is pre-registered - hypotheses were committed before any runs began.
But the comparison has a specific scope it is easy to miss. 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. Slack, Notion, Salesforce, HubSpot - none of these have a shell interface that covers the same surface area as their MCP servers.
The comparison is a category error. 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 of the stack, and production architectures need both.
The real takeaway from the benchmark is narrower than the headline suggests: the token overhead is a schema-loading problem, not a protocol problem.
How to cut the overhead without ditching MCP
Instead of injecting all 43 GitHub tool schemas, a gateway returns only the 2-3 tools relevant to the current request. That takes MCP from 44,000 tokens to roughly 3,000 - approaching CLI efficiency. About 90% token reduction.
There are three practical levers:
Schema filtering at a gateway. Route agent requests through a proxy that serves only the tools relevant to the current task. The 32x cost difference measures a specific implementation problem: MCP servers dumping all 43+ tool schemas into context on every turn. With schema filtering via a gateway, the gap shrinks to roughly 3x for simple tasks, and MCP actually becomes cheaper than CLI for complex tasks.
Use CLI where a good one exists. For well-defined, repeatable tasks against GitHub, git, or AWS, a CLI call is cheaper and debuggable: every command is a plain text string a human can inspect and rerun.
Lazy tool loading. The MCP spec itself is evolving toward lazy tool loading
the 2026-07-28 spec revision is part of that trajectory.
| Approach | Token cost (vs CLI baseline) | Reliability | Auth / multi-user |
|---|---|---|---|
| CLI (gh, git, etc.) | 1× | 100% | Per-dev credentials only |
| MCP direct (no gateway) | 10-32× | ~72% | OAuth per server |
| MCP via gateway | ~1.5-3× | ~99% | Centralised, scoped |
| mcp2cli wrapper | ~1.04-1.1× | matches CLI | Inherits CLI limits |
The gap between CLI and well-implemented MCP is roughly 1.5x, not 32x. The question is whether your team has the gateway in place.
Beagle in action#engineering, 11:02amWhat the 2026-07-28 spec revision actually changes for this
The spec that shipped on July 28 is stateless - no initialize handshake, no Mcp-Session-Id. Every request is self-contained, so your server runs behind a plain load balancer. That is structurally good for the reliability gap: stateless requests fail independently rather than cascading.
It does not fix the schema overhead by itself. A stateless server still advertises its full tool list on server/discover. But it does make gateway-layer filtering easier to implement, because there is no session state to preserve across the schema-trim. You can intercept any request, return a filtered tool list, and not worry about breaking a connection that was mid-handshake.
Since Anthropic released MCP in November 2024, the ecosystem has grown to over 17,000 publicly listed servers. OpenAI and Google DeepMind adopted it in early 2025, and it was donated to the Linux Foundation's Agentic AI Foundation in December 2025. At that scale, the schema-loading default is not a niche bug - it is the default experience for most teams wiring up agents right now.
The MCP ecosystem is big enough now that the protocol is not going away. The teams that feel the token squeeze worst are not the ones using MCP - they are the ones using it without a filtering layer. That is a fixable architecture problem, and the benchmark data makes it concrete enough to justify the fix.
MCP token cost: common questions
Why does MCP use so many more tokens than CLI?
MCP servers advertise their complete tool schema to the agent at the start of every connection. A server with 43 tools sends all 43 definitions, even if the agent only uses one. CLI bypasses this entirely - the agent executes a command and gets back its output, with no schema overhead. The fix is schema filtering at a gateway layer.
Is the Scalekit MCP vs CLI benchmark reliable?
The benchmark ran 75 head-to-head comparisons using Claude Sonnet 4, with pre-registered hypotheses and statistical significance at p < 0.05. The repo is public. The numbers are credible, but the scope is specific: GitHub tasks where both a CLI and an MCP server exist. Most SaaS integrations have no CLI equivalent, so MCP is the only viable option regardless of cost.
Can I use CLI instead of MCP for most tasks?
Only for systems that expose a maintained CLI with the coverage you need. Git, GitHub, AWS, and Google Workspace (via the March 2026 gws CLI) are strong candidates. Anything behind an OAuth-authenticated SaaS API - Notion, Linear, Salesforce, Slack - requires MCP or a direct REST integration. Production agents typically use both.
What is the cheapest way to run MCP in production?
A gateway that serves filtered schemas is the highest-leverage change: the Scalekit benchmark shows it cuts token cost from 32x down to roughly 1.5-3x compared to CLI, while keeping MCP's auth and multi-user benefits. Connection pooling in the same gateway layer also closes the reliability gap from 28% failure to around 1%.
Does the July 2026 MCP spec update fix the token overhead?
Not directly. The 2026-07-28 stateless spec removes session state, which makes load balancing and gateway interception simpler to implement. But the tool schema is still advertised on server/discover - the spec does not yet mandate lazy loading. That is on the roadmap but not shipped.