The token cost of MCP tool definitions — measured on live servers

Connect an AI agent to your company tools over the Model Context Protocol and something happens before you type a single word: every connected server hands the model a list of its tools, and each tool ships a name, a description, and a full JSON input schema. All of it lands in the context window. All of it is re-sent as input tokens on every turn of the conversation.

Most people never see this cost because it is paid silently, before your message is even part of the input. So we measured it — on live official servers, against the numbers the model vendors publish themselves, and against published academic benchmarks. This is what we found.

A word on where this comes from: we did not build our gateway’s aggregation to save tokens — it was already our answer to a simpler problem, too many tools. What tipped us into measuring it was WeAreDevelopers World Congress 2026, where the cost of context was everywhere — from Building Modern Distributed Systems using Less AI Tokens to The Retrieval Layer in Context Engineering, and Apify’s Jan Curn (MCP doesn’t suck — your agent does) making the case for running MCP as code. So we put numbers on what we had been running.

Chapter 1 — The silent tax: MCP tokens before you type

Start with the vendor’s own accounting, because it is the least disputable source available. In Introducing advanced tool use, Anthropic walks through a five-server setup and adds it up: 58 tools consuming approximately 55,000 tokens before the conversation even starts. The same post states that internally, “we’ve seen tool definitions consume 134K tokens before optimization.”

Here is how those 55,000 tokens break down across the five servers:

That is the whole tax in one picture: the number is dominated by two verbose servers, it is paid before any work happens, and it recurs on every turn. A team running ten thousand conversations a day pays for the Slack tool prose ten thousand times over, whether or not Slack is ever used.

Chapter 2 — Too many tools: token cost climbs, accuracy falls

The tax is not fixed — it grows with the tool surface. To see the shape of that growth we measured three official MCP servers live, by asking each one for its tool list (the tools/list call) and counting the size of the reply. The counts below are character-based estimates (chars ÷ 4); we call that out because it is an estimate, not a tokenizer read.

Amplitude alone — a single connected service — is roughly two-and-a-half times Anthropic’s entire five-server example. It sits at the verbose end of the range on purpose: each of its 88 tools ships a full WHEN TO USE / EXAMPLES / NOTES block, which is genuinely helpful to a model reading one tool and genuinely expensive multiplied by 88. That per-tool spread — from ~500 to ~1,600 tokens — is the honest headline: there is no single “cost per tool,” and anyone quoting one is rounding.

Plot the measured servers against the published ones and the direction is clear — raw tool-definition cost rises with tool count — though it is not a clean line: per-tool verbosity makes the middle of the range noisy — Slack’s 11 wordy tools cost more tokens (~21k) than Figma’s 26 leaner ones (~19k). We put an aggregated surface next to these numbers in Chapter 5.

That off-chart MCPVerse point is worth dwelling on: the benchmark assembles 65 servers and 552 executable tools whose combined schemas reach “approximately 147k tokens” — a full context window spent before the first instruction. And MCP-Bench deliberately attaches 10 distractor servers to every task, adding 100+ extra tools, precisely because a crowded tool surface is the realistic condition, not the edge case.

Which brings us to the second, less obvious tax. It is not only that more tools cost more tokens — more tools also make the model worse at choosing. MCP-Flow (2025), whose baseline evaluation covers real-world MCP tool use, finds that model “effectiveness further deteriorates as the number of candidate tools increases,” backed by a dedicated ablation (a test that varies only the tool count). At an extreme candidate set of 100 tools, a small tool-use model (Groq-8B-Tool-Use) collapses to 3% accuracy, and even a frontier model like GPT-4o gets fewer than 60% of its tool calls structurally valid (well-formed, with the right arguments) on real-world MCP tools. So the fat tool surface is taxed twice: once at the meter, once at the point of decision.

That is one face of the accuracy tax. The other has nothing to do with which tool gets picked: definitions don’t only add candidates — they fill the window, and models do not read a full window evenly. Liu et al. (2023) found that performance “is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle” — the “lost in the middle” effect, a U-shaped curve replicated across model families. And tool definitions sit at the very front of the input: it stacks in three layers — tool definitions first, then the app’s standing instructions, then your conversation. So a bloated surface claims the high-attention opening and pushes your actual request toward the neglected middle. A fuller window is not only slower and pricier; it is measurably worse at using what matters.

Chapter 3 — What it costs: billing, latency, and context window

Tool-definition tokens are input tokens: billed on every turn, and processed on every turn before the model can answer — so a larger resident surface raises both the bill and the time-to-first-token (how long before the model starts replying), and it does so on each message of a session, not once. The standard mitigation is prompt caching, and it genuinely helps — but it is worth understanding exactly what it does and does not buy you.

Anthropic’s prompt-caching pricing is a clean multiplier on the base input price:

A cache hit costs a tenth of the base input price. So for a stable tool set, caching largely defuses the per-turn cost. The catch is in the invalidation rule: the cache is structured tools → system → messages, and a change at any level invalidates that level and everything below it. Connect a server, disconnect one, bump a version, and every tool definition has to be written into the cache again at 1.25–2× base. Caching rewards a tool surface that holds still; it punishes a churning one. It also never removes the very first load. So caching is a real mitigation for the recurring cost and no mitigation at all for the structural one — the definitions are still resident, still competing for context, still degrading selection accuracy.

Chapter 4 — How to reduce MCP token overhead

Every serious answer to this problem reduces to the same principle: stop keeping every definition resident, and fetch detail on demand. The implementations differ, and they are converging across the market. Here is the honest landscape, with the numbers each source publishes and a confidence tag.

• Code execution with MCP (Anthropic, primary source). Present the servers as a code API the agent calls on demand, instead of loading all definitions and passing every result — the intermediate data a tool returns mid-task, before the final answer — back through the model. Anthropic’s worked example goes from 150,000 tokens to 2,000 — a 98.7% reduction. Apify ships this idea as mcpc / “MCP as code” (Jan Curn made the case at WeAreDevelopers 2026). Verified.
• Cloudflare MCP portals (primary source). search_and_execute hides all upstream tools behind just two (query, execute), keeping cost constant regardless of catalog size; minimize_tools strips descriptions and schemas to bare names for “up to 5× savings”; the default Code Mode collapses everything into a single code tool. Verified.
• Allow-listing and tool-search subagents — prune the surface to a core set, or push discovery into a fresh subagent (a separate helper model with its own context). Reported at 60–80% and 46.9% respectively by independent write-ups. Directional: we have not verified these against a primary measurement.

Chapter 5 — Cutting the token cost with gateway aggregation

mcpgate’s answer belongs to the same family as Cloudflare’s search_and_execute: instead of exposing one tool per action, it exposes a small fixed set per service — a read and a write tool, plus info/discovery — each taking an action parameter, with the full action catalog reachable through on-demand discovery. The static cost of a service therefore does not scale with how many actions it has.

One honest scope note: this attacks the token tax directly. The accuracy tax from Chapter 2 it addresses only indirectly — the model no longer meets all 88 Amplitude actions as one flat choice up front, but a search-narrowed subset at discovery time, which likely helps selection rather than hurting it. Still, what we measured here is the token saving, not the accuracy one; we are not claiming the second as proven.

Set our three measured servers next to their gateway surface. The axis is logarithmic; each row plots the raw cost and the gateway cost as two dots, and the gap between them is the saving:

Two figures here look contradictory at a glance, so separate them. The 461–640 tokens above is a service’s cost with its wrapper tools’ schemas loaded (Amplitude and Windmill happen to tokenize to the same 461). But most clients keep only the tool names resident and defer the schemas until a tool is actually used — so the whole gateway in the session we measured carried 165 tools for just 933 tokens actively resident, every schema pulled on demand. Either way, it advertises roughly 40 services and 17,000 actions; as one-tool-per-action MCP that would be millions of tokens, not loadable in any context window that exists.

Rather than take our three servers’ word for it, model your own stack — the slider below runs on the same measurements, across 34 real connectors:

None of this is a unique invention, and it would be dishonest to frame it as one. It is a production implementation of the aggregation pattern the primary sources above endorse. What matters is that it comes with a real trade-off, and we hit it ourselves: collapsing many tools behind one wrapper hides each tool’s input schema at call time. The model can no longer see, up front, that save_chart_edits requires a chartId — so it can omit a required argument and only learn its mistake from a discovery round-trip. That is exactly the “loss of per-tool schema guidance” the literature predicts for aggregation. Our mitigation is a presence check that validates required arguments against the cached upstream schema before forwarding, and echoes the schema back on a miss, so the model self-corrects in one step instead of flailing. The cost is real; it is smaller than the 30–304× it buys back, and it is worth naming rather than hiding.

Why not just code execution, then? Code execution — “Code Mode” — is the more aggressive lever. It collapses the tool surface the same way, but it also keeps intermediate results out of the model: the agent writes code that fetches, filters and chains calls in a sandbox, and only the final answer returns to the context. That second saving is why Anthropic’s worked example reaches 98.7% and Cloudflare reports 99.9% on its own API — both are whole-workflow numbers, not just the definition footprint aggregation addresses. The reason to run tools as governed calls rather than as code the model wrote is exactly that boundary: a call passes through the audit trail, the PII (personal-data) scrub, and the risk gate and confirmed=true prompt — one action at a time. Code executing in a sandbox does not. The two are composable, not exclusive: aggregate the surface to keep it small and every action inspectable, and reach for code execution where raw throughput matters more than per-action control. Which one you want is a governance decision as much as a token one.

Who pays — and in what currency

Whether this bloat shows up as a bill depends on how you run the model, and it arrives in two different currencies.

Per-token API billing — headless agents (running with no human watching), automations, retrieval pipelines, anything calling the Claude or OpenAI API directly — pays in dollars, every turn. Independent write-ups put a typical multi-server setup at 15,000–20,000 tokens of tool overhead per message (directional); at frontier-model input prices that is a real recurring line item, and prompt caching only blunts it while the tool surface holds still.

Seat / subscription clients — employees using Claude Desktop, ChatGPT, Cursor or Copilot with your tools connected — never see those dollars; the vendor absorbs them inside the flat monthly fee. Here the same bloat is paid in a different currency: context-window budget spent before the first question (so the session runs out of room and drops older history sooner), added latency, and the accuracy drop from Chapter 2.

For a mid-market company most usage is interactive today, so the everyday cost is context, latency and accuracy — not a line on an invoice. But the automation slice — where the gateway sits under a workflow engine or a headless worker — is exactly the per-token case, and it is the part growing fastest.

Which lever, when. If your tool surface is already small (under ~10–15 tools), none of this is worth engineering around: the savings are rounding error and you still pay a discovery round-trip. If it is large or volatile, aggregate it — keep the resident surface flat and every action inspectable. If raw throughput matters more than per-action control, such as a headless worker grinding a known pipeline, reach for code execution. The choice is about how you consume the model, not the token count alone.

What to take from the numbers

Three things survive the fact-check cleanly. First, the tax is real and vendor-confirmed: tool definitions cost tokens, on every turn, before any work — 55,000 in Anthropic’s own example, and far more for a single verbose server. Second, it is taxed twice, because accuracy falls too — both from having more tools to choose between and from a fuller window the model reads less evenly. Third, the fixes converge on one move — don’t keep every definition resident — and they work, with Anthropic’s 98.7% the best-verified single figure and aggregation delivering 30–304× on the servers we measured.

If one number is worth remembering: a single official MCP server we measured live on 11 July 2026 — Amplitude, 88 tools — carries roughly 140,000 tokens of tool definitions on its own, and re-sends them on every turn.

The unglamorous conclusion: connecting more tools is not free, the bill arrives before the first token of useful work, and the architecture that decides how tools are surfaced is doing more for your cost and quality than the choice of model. Measure your own surface before you assume it is small — the quickstart puts your tools behind one endpoint in a few minutes.

Related: this is the measured backbone behind Dynamic action discovery isn’t novel. Doing it safely is. — the same problem, from the design-decision angle.