Connected MCP servers
Edit any row. Leave a row blank (no name) to exclude it. All rows count toward the schema union resent every turn — whether or not that server's tools get called this session.
Session volume & pricing
—
monthly schema cost, current setting—uncached total / mo
—cached total / mo
—saved by caching
Attributed monthly cost, by server
Sorted by attributed monthly cost, highest first. The top row is often the largest tool count and heaviest schema — not necessarily the server you call the most.
| Server | Tools | Schema tok/tool | Tok/turn | Share of total | Attributed monthly cost |
|---|
How this connects to other tools
This calculator is the multi-server layer on top of two single-server tools already on this site — read both to see how the three fit together. The MCP Server Cost Calculator prices the infrastructure of running one MCP server: hosting, amortized build cost, and a monthly maintenance retainer. That number is paid by whoever operates the server and has nothing to do with how any particular LLM conversation uses it — a server can be nearly free to host and still be the single biggest line item in your token bill. The MCP Tool Schema Token Overhead Calculator prices the recurring token tax of one server's tool schemas being resent on every turn of a session — the single-server version of the schema tax. This calculator adds the piece neither of those covers: what happens once more than one server is connected to the same session at once, where the client resends the union of every connected server's schemas together on every turn, and how that combined bill should be split back out per server so you know which connection is actually worth keeping. Dedicated runtime observability products like MCPSpend take this further by measuring real per-server, per-project spend from proxy logs rather than a modeled estimate — worth pairing with this calculator once you want to verify the modeled attribution against what actually happened in production.
How this calculator works
The MCP Multi-Server Cost Attribution Calculator starts by multiplying each connected server's tool count by its average schema tokens per tool to get that server's tokens-per-turn, then sums every server's row into totalSchemaTokensPerTurn — the union the client resends on every single turn, whichever one tool actually gets called. Multiply that by turns per session to get the per-session schema token count, then by sessions per day × 30 to get the monthly schema token volume. That volume gets priced at either the uncached input price or the cached input price depending on the caching toggle, giving the monthly schema cost headline.
The attribution step is what makes this different from a plain token calculator: each server's share of total is its own tokens-per-turn divided by the combined tokens-per-turn across every connected server, and its attributed monthly cost is simply the monthly schema cost multiplied by that share. Because every server's share adds up to exactly 100% of the connected schema, the attributed costs always sum to the total monthly cost — there's no cost created or destroyed by splitting it, only reassigned. This is deliberately based on how much of the connected schema each server accounts for, not on how often its tools are actually invoked — a server can be the single most expensive line item in your bill while sitting completely idle that session, purely because it stays connected with a large tool count and verbose schemas. Prompt caching changes the dollar magnitude of the total (typically around a 90% discount once the identical schema prefix repeats turn to turn) but does not change which server holds the largest share — it only shrinks the number next to it.
Frequently asked questions
Why does connecting three MCP servers cost more than the sum of what each server would cost on its own?
It doesn't cost more per server, but it does cost more per turn than most people expect, because the client doesn't send only the tool schemas for the server you're about to use — it sends the schemas for every MCP server currently connected to that session, bundled into a single union, on every single turn. If you connect a GitHub MCP server with 26 tools, a Slack MCP server with 11 tools, a Postgres MCP server with 6 tools and a filesystem MCP server with 8 tools, the client resends all 51 tools' worth of schema on turn one, turn two, and every turn after that, regardless of which one tool actually gets called that turn. Three or four servers each individually cheap to run can add up to a schema payload of tens of thousands of tokens sitting in every request before the conversation even starts, the same union-of-connected-tools mechanic documented for heavy single servers like GitHub, whose tool definitions alone can run into the tens of thousands of tokens, just multiplied across however many servers happen to be wired into the same client session.
If a server's tools were never called this session, why does it still get attributed a cost?
Because the cost being priced here isn't the cost of calling a tool — it's the cost of the schema sitting in every request whether or not it gets used. The client doesn't selectively include only the schemas for tools it expects to call; it includes the full schema for every tool on every connected server, every turn, and that block of tokens gets billed as ordinary input tokens regardless of what the model actually does with it. This calculator attributes each server's share of the monthly schema bill in proportion to that server's share of the total connected schema — tools times average tokens per tool, divided by the sum across all servers — not in proportion to how often its tools get invoked. A server with a large tool count and verbose schemas can end up responsible for most of your monthly bill even at zero actual calls, simply by staying connected, while a server you use constantly but that exposes two small tools costs almost nothing by comparison. That mismatch between 'expensive to have connected' and 'expensive to use' is the whole point of pricing attribution this way instead of by call volume.
Does turning on prompt caching solve the multi-server schema cost problem?
It solves the dollar magnitude, not the underlying shape of the cost. Caching lets the first turn of a session pay full input price for the schema block, then read that identical block back from cache at a steep discount — typically around 90% off — for every turn after, as long as the exact same set of tools stays connected with nothing reordered or changed mid-session. That discount is real: on a typical multi-server setup it can turn a monthly bill in the thousands of dollars into a few hundred. But it does not change which server is responsible for the largest share of that bill, because the attribution is still proportional to each server's share of the connected schema, cached or not — a heavy server connected but rarely used is still the biggest line item, just at a smaller number. And caching only works while the tool list stays identical turn to turn; add, remove, or reorder a connected server mid-session and the next request misses cache and pays full price again.
How is this different from the MCP server cost calculator and the MCP tool schema token overhead calculator already on this site?
All three price something related to MCP but none of them overlap. The MCP server cost calculator prices what it costs to build, host and maintain one MCP server as infrastructure — engineering hours, a monthly hosting bill, maintenance retainer — a number that doesn't change based on how any LLM conversation uses it. The MCP tool schema token overhead calculator prices the recurring token tax of one server's tool schemas being resent on every turn of a session, the single-server version of the schema tax. This calculator is the multi-server version: it models what happens once you connect more than one MCP server to the same client session at the same time, where the client resends the union of every connected server's schemas together on every turn, then splits that combined monthly bill back out by each server's share of the total connected schema — the attribution problem that only exists once more than one server is in the room.