Question 1

What is the MCP tool-schema token tax, and why does it get charged on every single turn?

Accepted Answer

When you connect an MCP server (or several) to a client like Claude Code or Claude Desktop, that client bundles the JSON schema for every tool the server exposes — name, description, parameter types, examples — into the request it sends the model. If you have 25 tools averaging around 1,000 tokens each, the rough community figure that came out of the modelcontextprotocol GitHub issue #2808 on real-world tool schemas, that is 25,000 tokens of pure tool definitions before you have typed a word. LLM APIs are stateless: each call is a fresh HTTP request with no server-side memory of what you sent last time, so unless caching is involved, that entire schema block gets serialized and re-transmitted, and billed as input tokens, on turn 1, turn 2, and every turn after that for as long as the session runs. Twenty turns in a session means you paid for those 25,000 tokens twenty times over, not once. That is the tax — not a one-time cost of loading the tools, but a recurring line item baked into every request the agent loop makes, whether or not any tool actually got called on that particular turn. It shows up on the invoice as ordinary input tokens, which is exactly why it goes unnoticed until someone adds it up.

Question 2

How does prompt caching change this, and where does it stop working?

Accepted Answer

Prompt caching lets you pay full input price once for a block of tokens and a steep discount — typically around 90% off, so roughly $0.30 instead of $3 per million tokens on a Sonnet-class model — for reading that same block back on subsequent calls within the cache's active window. Tool schemas are a good caching candidate because they usually sit at a fixed, early position in the request and do not change turn to turn. Model that assumption and this calculator's $2,250-a-month uncached bill on 25 tools, 20 turns per session and 50 sessions a day drops to roughly $326, about 85% saved. But caching only helps if the prefix is byte-identical. Add a tool, remove one, reorder the list, or change a description mid-session — common when an orchestrator swaps toolsets dynamically — and you get a cache miss, paying full price again from that point forward. The cache also expires: five minutes on the short-lived tier, up to an hour on the longer one depending on provider and settings. A session that goes idle between calls, or a fresh session started after that window lapses, starts back at full price with no discount at all. Caching is a real discount, not a fix: it rewards static tool lists and punishes anything that reshuffles the schema mid-conversation.

Question 3

Does connecting more MCP servers cost anything if I never actually call most of the tools?

Accepted Answer

Yes, and this is the part teams miss because it feels like it should not be true. The moment an MCP server is connected, its tool schemas go into the request payload for every turn of every session that has that server attached, regardless of whether the model ever invokes one of those tools. An unused tool sitting in context is not free; it is roughly a thousand tokens of input cost per turn, same as a used one, and it is also a thousand tokens the model is not using for your actual conversation, retrieved documents or code. Connect five MCP servers with fifteen tools each and you are carrying seventy-five tool schemas — roughly 75,000 tokens, over a third of a 200K context window — before a single user message arrives, even if sixty of those seventy-five tools never get called that session. That is why wiring up every available MCP server by default is bad practice for agent setups: it inflates cost per turn, crowds out useful context in ways that can degrade retrieval and reasoning on long sessions, and adds latency, all for tools sitting idle. The fix is not avoiding MCP, it is scoping which servers and which tools within them are actually attached to a given agent or session instead of connecting everything available.

Question 4

How is this different from the MCP server cost calculator already on this site?

Accepted Answer

They price two unrelated costs that happen to share the letters MCP. The MCP server cost calculator on this site answers what it costs to build, host and maintain the MCP server itself — engineering hours to build it, a monthly bill for wherever it runs, whether that is Cloudflare Workers, Fly.io, Railway, or a local stdio process that costs nothing to host, plus ongoing maintenance. That is infrastructure spend, paid by whoever operates the server, and it does not change based on how much any particular LLM conversation uses it. This calculator prices something completely different: the token cost an LLM API bill absorbs because that server's tool schemas are sitting in every request's context. That spend is paid by whoever is footing the LLM API bill, often the same team but sometimes not, it scales with sessions and turns rather than engineering effort, and it exists even for a server that costs zero dollars to host, because the cost here was never about running the server — it is about what the model provider charges to read the tool definitions on every single call. A team can have a nearly free MCP server by this site's other calculator and still be burning hundreds of dollars a month in schema tokens by this one. Both numbers are real, they do not overlap, and neither substitutes for the other in an honest budget.

MCP ツールスキーマトークンコスト計算ツール

より多くのツールを接続するときのセッションあたりのコスト

上記の数字の出典

これが他の MCP およびコンテキストコストラインにどのように接続されるか

この計算機の仕組み

より多くのツールを接続するときのセッションあたりのコスト

上記の数字の出典

これが他の MCP およびコンテキスト コスト ラインにどのように接続されるか

この計算機の仕組み

これが他の MCP およびコンテキストコストラインにどのように接続されるか