—with caching / mo
—saved by caching
—of context window used
Cost per session as you connect more tools
Same turns per session and pricing as above — only the tool count changes. This is how agents that connect five or six MCP servers for convenience quietly rack up a bill nobody priced.
| Tools connected | Schema tokens | % of context | Cost/session, no cache | Cost/session, cached |
|---|
Where the numbers above come from
The first turn of a session always pays full input price — there is nothing to read from cache yet. Every turn after that reads the identical schema block from cache, at the discounted rate, as long as nothing about the tool list or the preceding prompt changes.
How this connects to the other MCP and context cost lines
This page prices the recurring token tax of having MCP tools connected — it is not what it costs to run the server behind them. Price that side of it, hosting, build and maintenance, on the MCP server cost calculator. If tool schemas are only part of what is crowding your context window, the context window cost calculator prices the whole picture including retrieved documents and conversation history. The caching math used here — one full-price read, then discounted reads for the rest of the session — is the same mechanism behind the prompt caching savings calculator, worth checking if you cache more than just tool definitions. And if your tool schemas sit inside a larger fixed system prompt, the system prompt cost calculator prices that whole preamble, tools included, as a single per-request tax.
How this calculator works
The MCP Tool Schema Token Cost Calculator multiplies your connected tool count by the average tokens per tool schema to get the token weight sitting in context before a conversation even starts — divide that by your context window size for the striking of-context percentage. Without caching, that block gets re-sent and billed at the full input price on every turn of a session, so the uncached monthly cost is schema tokens × turns × sessions × 30 × input price. With prompt caching, only the first turn of each session pays full price; every turn after that reads the identical block from cache at the usually far cheaper cache-read price, so the formula becomes one full-price read plus turns-minus-one cache-price reads, multiplied out across sessions and days.
The result depends most on how many tools are connected and how long sessions run. A session with more turns amortizes the one expensive first turn over more cheap cached reads, which is why the caching-savings percentage climbs as turns per session increases, and why a single-turn session gets no benefit from caching at all — there is no repeat read left to discount. Tool count and average schema size drive the uncached side just as strongly, and they drive the context-consumed stat regardless of caching, because a cached-but-still-present schema block still occupies context the model has to read on every turn. Figures here are a transparent model built on the community-reported roughly 1,000-token average schema size, not a measurement of any specific deployment — real schema size varies with how verbose each tool's parameter descriptions are.
What is the MCP tool-schema token tax, and why does it get charged on every single turn?
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.
How does prompt caching change this, and where does it stop working?
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.
Does connecting more MCP servers cost anything if I never actually call most of the tools?
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.
How is this different from the MCP server cost calculator already on this site?
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.