- MCP servers load the full definition of every exposed tool into the model’s context at conversation start, whether those tools are used or not.
- Real-world measurements show this overhead can consume most of the context window (e.g., 143,000 of 200,000 tokens across three servers), leaving far less room for the actual task.
- This front-loaded schema cost translates directly into meaningful spend (e.g., tens of cents per request and potentially thousands of dollars per developer per year) just to “re-describe” tools.
- Benchmarks comparing identical operations found MCP can use 4–32× more tokens than invoking the same capabilities via a CLI, dramatically increasing cost for the same outcome.
- The core issue is when the cost lands: CLIs are invoked on demand, while MCP pays upfront for discovery by shipping the “manual” into context; even MCP’s creators point toward approaches that avoid loading everything at once.
Every tool an MCP server exposes loads its full definition into the agent's context window at the start of the conversation, used or not.
One team measured three MCP servers consuming 143,000 of their 200,000 tokens before the agent read a single instruction.
A benchmark of 75 identical operations found MCP costing 4 to 32 times more tokens than calling the same tool through a CLI.
The bill arrives before the work starts
The pitch for the Model Context Protocol was clean. Stop hand-rolling integrations, expose your tools through a standard server, and any agent can discover and call them. For a year that was the reflex. New capability for your agent meant a new MCP server.
The part that did not make the pitch is what happens at the start of every conversation. When an agent connects to an MCP server, the definitions for every tool that server exposes get loaded into the model's context. Not the tools the agent decides to use on this particular run. All of them. The name, the description, the JSON schema, every field description, every enum, the system instructions. Each tool runs somewhere between 550 and 1,400 tokens, and the agent pays for that before it has read the task.
One team reported three servers eating 143,000 of 200,000 tokens. That is 72 percent of the window spent describing tools the agent might never touch, leaving barely a quarter of the context for the actual code, the actual conversation, the actual work. The agent walks in already most of the way full.
What this costs in money, not just room
The token math is easy to wave off until you put a price on it. At Sonnet's three dollars per million input tokens, 90,000 tokens of schema overhead is about 27 cents a request. Run that agent a thousand times a day and you are spending 270 dollars daily to re-describe tools that mostly sit idle.
Scale it to a team. A power developer running ten MCP servers, fifteen tools each, burns roughly 75,000 tokens at every conversation start. Ten conversations a day puts that near 3.75 dollars per developer per day in tool definitions, or about 1,370 dollars per developer per year. That is not the cost of the work. That is the cost of the menu.
The Scalekit benchmark made the comparison direct. Seventy-five head-to-head runs of identical operations, MCP against a plain CLI. MCP cost 4 to 32 times more tokens. At ten thousand monthly operations, the GitHub CLI ran about 3.20 dollars while the equivalent MCP path ran about 55 dollars. Same result, seventeen times the bill.
Why a CLI is cheaper than a protocol
This is not a knock on MCP being badly built. It is a difference in when the cost lands.
A CLI is discovered on demand. The agent runs a command, and that command is roughly 200 tokens, just the line it typed. The shell already knows what gh or kubectl can do. The agent does not carry the manual in its head, it just calls the thing and reads what comes back. The knowledge of how to use the tool lives in the tool, in training data, in a help flag the agent can read when it actually needs it.
MCP front-loads the manual. To make discovery work without the agent already knowing the tools, the protocol hands the model the full schema for everything up front. That is genuinely useful when the agent faces a tool it has never seen. It is pure waste when the agent uses three tools out of a hundred and a CLI for those three would have cost a few hundred tokens total.
Anthropic published an engineering piece on exactly this, framing the fix as code execution with MCP: let the agent write code that calls tools, rather than loading every tool definition into context and round-tripping every intermediate result through the window. The company that co-created the protocol is telling you not to load all of it at once.
The pattern that actually works
The answer going around, and the one worth copying, is not to rip MCP out. It is to stop using it as the thing that is always loaded.
Use MCP as a registry. Keep it as the discovery layer, the catalog the agent can search when it needs to find a capability. Then dispatch the actual execution to a CLI wherever a CLI exists, and fall back to a direct MCP call only where it does not. You get structured discovery without paying schema rent on every tool for every conversation. One team that restructured this way reported going from 150,000 tokens to 2,000 for the same workflow, a 98.7 percent cut.
If you have used a recent agent harness that loads tool schemas on demand instead of all at once, you have already seen the lighter version of this. The tools are there. Their full definitions are not in the context until the agent asks for them. The difference in headroom is not subtle.
The practical audit is short. Count your connected MCP servers. Multiply tools by roughly 1,000 tokens. If that number is a meaningful slice of your context window, you are paying it on every single conversation, and most of those tools are not getting called. For the ones with a real CLI, the CLI is almost certainly cheaper, and the agent will be just as capable with more room left to think.
MCP solved a real coordination problem and it is not going anywhere. The mistake was treating "expose every tool to every agent all the time" as free. It was never free. It was just billed somewhere you were not looking.
Sources: Anthropic, Code execution with MCP, BSWEN, How MCP tool definitions inflate your AI agent token costs, Apideck, Your MCP server is eating your context window, Firecrawl, MCP vs CLI for AI agents.
Audit how many MCP servers and tools you load by default and measure the token hit before the agent even starts working. Where possible, shift from “always-on” tool schemas to on-demand discovery—use MCP more like a registry and only pull in the few tool definitions you actually need for a given run, or prefer CLI-style calls for common operations. If you must use MCP broadly, look for patterns that keep intermediate work out of the context window (e.g., code execution that calls tools) so you’re not paying to carry the entire manual every time.