Published 2026-08-05 · reference numbers, verify before budgeting
Wiring an MCP server into an agent feels free. No signup, no per-tool bill, no meter animation. Then you look at what actually gets sent on the wire. Connect 25 tools at a typical ~1,000 tokens of schema each — the figure that came out of the modelcontextprotocol GitHub issue #2808 on real-world tool definitions — and that is 25,000 tokens riding along on every single turn of every session, whether the model calls a tool on that turn or not. At 20 turns a session and 50 sessions a day, uncached, that is $2,250 a month. Nobody put that number in the MCP quickstart.
LLM APIs are stateless. Every call is a fresh HTTP request with no server-side memory of the last one, so the client — Claude Code, Claude Desktop, whatever agent framework is driving the loop — has to re-serialize the full tool schema block into the request each time. Turn 1 pays for it. Turn 20 pays for it again. A 20-turn session does not load the tools once; it transmits them twenty times and gets billed as ordinary input tokens each time, which is exactly why the cost hides in plain sight on the invoice instead of showing up as a line item called "MCP tax."
Nobody sits down and decides to spend $2,250 a month on tool schemas. What happens is a team connects a filesystem server, a database server, a search server and a couple of internal ones "since they're there," and the tool count creeps from 5 to 75 without anyone re-pricing it. Same 20 turns, same 50 sessions a day, same $3/$0.30 per-million pricing throughout — only the tool count moves.
| Tools connected | Schema tokens | % of 200K context | No caching / mo | Cached / mo |
|---|---|---|---|---|
| 5 (one server) | 5,000 | 2.5% | $450 | $65 |
| 15 | 15,000 | 7.5% | $1,350 | $196 |
| 25 | 25,000 | 12.5% | $2,250 | $326 |
| 50 | 50,000 | 25% | $4,500 | $653 |
| 75 (five servers) | 75,000 | 37.5% | $6,750 | $979 |
| 20 turns/session, 50 sessions/day, $3.00 input / $0.30 cache-read per 1M tokens. Reference model — run your own numbers on the MCP tool schema token overhead calculator. | ||||
The line that should stop you is the third column. At 75 tools, more than a third of a 200K context window is gone before the user has typed anything — not to conversation, not to retrieved documents, not to reasoning, to tool definitions the model may call zero times that session. That is context the agent cannot use for anything else, cached or not.
Prompt caching is a real discount here: pay full price once to write the tool-schema block, then read it back at roughly 90% off — about $0.30 instead of $3 per million tokens on a Sonnet-class model — for every turn after that, as long as the block sits at a fixed, early position and never changes. That is why the cached column above runs 85% below the uncached one across every row.
The catch is that the cache only pays off on a byte-identical prefix. Add a tool, remove one, reorder the list, or let an orchestrator swap toolsets mid-session and you get a cache miss — full price again from that point forward. The cache window itself is short: five minutes on the fast tier, up to an hour on the longer one depending on provider. A session that idles between calls, or a fresh session that starts after the window lapses, gets no discount at all. Caching rewards a static tool list and punishes anything that reshuffles the schema mid-conversation — which is precisely what a lot of orchestration layers do by design.
The moment a server is connected, its schemas go into every request of every session that has it attached — called or not. An idle tool is not a free option sitting in the background; it is roughly 1,000 tokens of input cost per turn, identical to a tool that gets invoked constantly, and it is 1,000 tokens the model is not spending on the actual conversation. Five servers at fifteen tools each is 75,000 tokens of schema before a single user message arrives, even if sixty of those seventy-five tools never get called. Connecting every available MCP server "just in case" is not a neutral default — it is a standing monthly charge plus a context tax, paid whether or not any of it gets used.
Worth separating cleanly, because the two numbers get confused constantly: what it costs to build, host and maintain an MCP server — covered on the MCP server cost calculator — is infrastructure spend paid by whoever operates it, and it does not move with how much any given conversation uses it. The tax in this article is a completely different bill, paid by whoever is footing the LLM API invoice, that scales with sessions and turns rather than engineering effort. A server that costs zero dollars to host on a local stdio process can still be burning hundreds of dollars a month in schema tokens on the other side of the ledger. Both are real. Neither substitutes for the other in an honest budget.
MCP tools are not expensive to call. They are expensive to have connected, on every turn, whether called or not — and that cost is nearly invisible because it arrives as ordinary input tokens on a bill that already has plenty of those. Caching cuts the dollar figure by about 85% and does nothing for the context-window share, which is the number that actually degrades a long session. The fix costs nothing: connect fewer servers, keep the list stable, and check the calculator before the tool count creeps past what anyone priced.
Methodology: the ~1,000-token average schema size is the community-reported figure from modelcontextprotocol GitHub issue #2808, not a measurement of any specific deployment — real schema size varies with how verbose each tool's parameter descriptions are. Pricing ($3.00 input / $0.30 cache-read per 1M tokens) reflects a Sonnet-class model's published rates as of August 2026. The worked table is a constructed scenario meant to show how the numbers scale with tool count, not telemetry from a production system. Confirm current pricing and your own turn/session counts before budgeting.