Connecting a tool server takes about a minute. You paste a command, the client restarts, and forty new tools appear. Nothing in that minute tells you that you have just added a standing charge to every model call your product will ever make, for as long as the server stays connected.
The charge is not hypothetical and it is not small. Anthropic published an audit of one ordinary five-server setup: GitHub, Slack, Sentry, Grafana and Splunk together came to about 55,000 tokens of tool definitions, read before the conversation starts. Add Jira, worth roughly another 17,000, and the setup passes 70,000 tokens of schema that the model reads in order to answer "what changed yesterday".
This post is the arithmetic for that, a calculator you can point at your own tool list, and the part most write-ups miss: the two problems it causes are separate, and the fix for one does nothing for the other.
The number is per call, and that is the whole problem
Start with the smallest possible measurement, because Anthropic publishes both halves of it. A bare request with a one-line system prompt and a two-word message counts 14 input tokens. The same request with a single get_weather tool attached counts 403.
One tool, with one string parameter and a one-sentence description, costs 389 tokens.
Two things are folded into that. The first is the schema itself: the name, the description, and the JSON Schema for its arguments, serialised into the prompt. The second is a fixed tool-use system prompt that the API adds the moment the tools array is non-empty. Anthropic publishes that table per model: 354 tokens on Claude Sonnet 5, 286 on Opus 5, 496 on Haiku 4.5, with tool choice set to auto. Forcing a tool call costs more again.
Neither is deduplicated across a conversation. The tools array is a field in the request body, so a ten-turn conversation sends it ten times. The provider is not being greedy here; it is stateless, and it cannot know that your client is sending the same forty schemas it sent ninety seconds ago. But it means the intuition people carry over from system prompts — write it once, pay for it once — is wrong in the one place it costs the most.
What a realistic tool list actually weighs
Tool schemas vary more than you would expect. The five-server audit works out at roughly 743 tokens per tool for GitHub and about 1,900 for Slack, because Slack's tools take more arguments and its descriptions carry more caveats. Across all 58 tools the average is about 950.
At 950 tokens each, 58 tools is 55,100 tokens on every call. On a 200,000-token context window that is 28% of the window gone before the user's question arrives, and before any tool has returned a single result. If you are also running an agent loop, that 28% is the floor the step-by-step growth in context starts from, not something it replaces.
The independent work that exists puts this in the same range. A paper on what its authors call the MCP tax, published in April 2026, places practitioner reports "between roughly 10k and 60k tokens in typical multi-server deployments", and reports 47,300 tokens of per-turn tool payload on its own simulated 120-tool, six-server benchmark. Worth reading with its own caveat in hand: the authors are explicit that their token counts are measured on a simulation while the end-to-end cost, latency and quality figures are projections rather than live measurements, and they mark them as such. The token counts are the part to trust.
Two problems wearing one coat
Here is where most advice goes wrong. "Your tools are eating your context" and "your tools are eating your budget" sound like the same complaint. They are not, and they have different fixes.
The budget problem has a boring fix, and you should apply it today. Tool definitions sit at the front of the prompt and never change between calls, which makes them the ideal cacheable prefix. Marking them cached prices them at the provider's cache-read rate instead of full input. Our worked example, 58 tools at 20,000 calls a day on Sonnet 5, goes from about $2,498 a day to about $430. The tools alone account for $2,204 of that first figure, which is $804,000 a year. If you read nothing else here, go and check whether your tool block is cached, because the change costs nothing in answer quality and takes an afternoon. The mechanics are in what prompt caching actually saves.
The context problem has no such fix, because caching shortens nothing. A cached prefix is cheap to send and still fully present: the model reads all 55,100 tokens of schema, and picks one. That has a measurable cost in accuracy, not just in tokens. When Anthropic moved the same tool library behind a search tool, so only the handful being used were expanded into full definitions, tool-selection accuracy rose from 49% to 74% on Opus 4, and from 79.5% to 88.1% on Opus 4.5. The context dropped from roughly 77,000 tokens to about 8,700, an 85% reduction.
Note the direction of the accuracy numbers. Removing information made the model better at its job. That is not what most teams expect, and it is the strongest argument for pruning that exists.
Read the third and second bars together. Eager-and-cached costs less per day than lazy-and-uncached, which tells you that if you only ever do one of these, do the caching. It also tells you that the caching was never about the context, and the team that stops there still has 28% of its window spent on a menu.
Work out your own numbers
Count your own tools rather than trusting the averages above. Anthropic's count_tokens endpoint takes the same tools array as a real request and is free to call, so the honest version of this exercise takes ten minutes: count a representative request with your tool list attached, count it again with tools removed, and subtract.
calculator · reference counts checked 23 Sep 2026
What your tools parameter costs per call
cost a day, four ways to carry the same tools
The tools parameter is part of the request, so it is counted on every call and never deduplicated between them. Enabling tools also adds a fixed tool-use system prompt: Claude Opus 5 286, Claude Sonnet 5 354, Claude Haiku 4.5 496 tokens with tool_choice auto, and 300 assumed for models Anthropic does not publish a figure for. Caching prices the static prefix at the provider's cache-read rate; it does not shorten it.
The defaults are the audited five-server setup on Sonnet 5 at 20,000 calls a day. Change the tool count and the per-tool size to yours; the per-tool figure is the one worth measuring rather than estimating, because a single verbose server can carry a third of the total.
What to do about it, in order
| Step | Effort | What it changes |
|---|---|---|
Count the tools parameter with count_tokens | Ten minutes | You stop guessing |
| Cache the tool block and base prompt | An afternoon | Roughly 80% off the tool bill, nothing else |
| Delete servers nobody has used in a month | An afternoon | Bill and window, permanently |
| Trim descriptions and arguments | A day per server | Bill and window, and usually accuracy |
| Load schemas on demand | A week | The window, and tool-selection accuracy |
The order matters. Teams reach for on-demand loading first because it is the interesting engineering, and it is the step most likely to introduce a new failure mode: a tool that exists but is never found is worse than a tool that was never attached, because nothing in your logs says it was missing.
Deleting unused servers is unglamorous and beats all of it. In most setups the audit finds two or three servers that were connected for one investigation in March and never removed. They have been charged for on every call since.
:::note kind: warn title: The number moves without you A server updates, adds eleven tools, and your per-call cost rises. Nothing in your repository changed, no deploy happened, and no alert fired. If you depend on third-party tool servers, put the token count of your tools array on a dashboard next to your other cost metrics, and alert on the step change. This is the same argument as keeping a gateway in front of your providers: the things that move are not all yours. :::
What the numbers cannot tell you
The arithmetic here is honest about cost and mostly silent about value. Forty tools that make an agent genuinely capable are worth more than the 38,000 tokens they cost, and a team that prunes purely on token count will eventually delete the tool that was carrying the product.
Two limits worth stating plainly. First, the 950-token average comes from one published audit of five servers; your servers are not those servers, and a tool that takes a large structured payload can be several thousand tokens by itself. Second, the accuracy figures above were measured by the vendor on its own models with its own benchmark. The direction is consistent with what the independent work reports and with what anyone who has watched a model pick the wrong tool from a long list would expect, but treat the exact percentages as vendor numbers, because that is what they are.
What the arithmetic does settle is the shape of the problem: this is a recurring per-call charge that most teams have never measured, that grows when other people ship, and whose two symptoms need two different fixes.
The short version
- Tool definitions are part of every request and are never deduplicated. Their cost is per call.
- One trivial tool is about 389 tokens in Anthropic's documented example; attaching any tools also adds a fixed system prompt of 286 to 496 tokens depending on the model.
- A realistic five-server setup measured about 55,000 tokens, roughly 28% of a 200,000-token window, before the question arrives.
- At 20,000 calls a day on Sonnet 5, that is around $2,204 a day for the tools alone. Caching the tool block takes the whole call from about $2,498 a day to $430.
- Caching fixes the bill and not the window. Loading schemas on demand fixes the window, and improved tool-selection accuracy from 49% to 74% in Anthropic's own measurement.
- Do them in this order: count, cache, delete what nobody uses, trim what remains, and only then build on-demand loading.
questions people ask
Does prompt caching remove the tool overhead?
It removes most of the cost and none of the length. A cached tools block is billed at the provider's cache-read rate, which is roughly a tenth of input price, but it is still sent and still read in full. Your context window and the model's tool-selection problem are unchanged.
How many tools is too many?
There is no fixed number, because schemas vary from about 300 to several thousand tokens each. The useful threshold is a share of the window rather than a count: once your tools parameter passes about a quarter of the context you have to work with, you are choosing between tools and conversation on every call.
Do tool definitions count as input tokens for billing?
Yes. Anthropic lists the tools parameter, tool_use blocks and tool_result blocks as sources of additional tokens, all charged at normal input rates. Server-side tools can add usage-based charges on top.
Is this specific to MCP?
No. MCP makes it easy to attach many tools at once, which is why it gets the blame, but the cost comes from the tools parameter and applies identically to tools you define by hand. A hand-written client with 58 tools pays exactly the same.
How do I measure my own overhead without guessing?
Call the token counting endpoint twice with a representative request, once with your tools array and once without, and subtract. It is free, it accepts the same request shape as the Messages API, and it takes about ten minutes to wire into a test.