—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.