إنتقل إلى المحتوى الرئيسي

The MCP Token Tax

متقدّم

There's a fight on Hacker News and X this month: why burn tens of thousands of tokens on a single MCP operation when the same thing over a CLI costs a couple hundred? It sounds like MCP-bashing. It isn't. The people arguing loudest are the ones who love agents — they've just met the bill. This page is the practical guide to that bill: where the tokens actually go, the two costs almost nobody separates, and the three fixes that turn a 150,000-token workflow into a 2,000-token one.

What you'll learn
  • Separate the TWO distinct MCP token costs: tool-definition loading and intermediate results
  • Understand why the schema cost is paid per-conversation, not once
  • Use defer_loading and the Tool Search Tool to load tool schemas on demand
  • Use code execution / Programmatic Tool Calling to keep large results out of context
  • Decide, per task, when an MCP tool is worth it and when a plain CLI call wins

Two costs, not one​

When you connect an MCP server, the client asks it for tools/list and gets back every tool with its full JSON schema. That whole block is injected into the model's context. Most people stop their mental accounting there. But there are two separate taxes, and the second one is usually bigger.

Cost 1 — Tool definitions. Every connected tool's name, description, and parameter schema sits in context. Anthropic's own framing: "In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request." A single enterprise server can publish dozens to hundreds of tools; third-party analyses put a 400-tool server at roughly 400,000 tokens of schema alone — more than Claude's 200k context window can hold.

Cost 2 — Intermediate results. When the model calls a tool directly, every result flows back through the model's context, even the parts you never wanted it to read. Anthropic's example: pull a two-hour meeting transcript from one tool and pass it to another, and the full transcript passes through the model twice — potentially ~50,000 tokens — just to produce a one-line summary.

Watch out
  • Cost 1 is paid EVERY turn until prompt caching kicks in — the schemas are re-sent with each request in the conversation, not loaded once. A big tool catalog is a tax on the whole session, not a one-time fee.
  • Cost 2 scales with your DATA, not your tool count. Ten tiny tools can be cheaper than one tool that returns a giant blob.

The numbers, from the primary sources​

FixTaskBeforeAfterReduction
Code execution with MCPGoogle Drive → Salesforce workflow150,0002,00098.7%
Tool Search ToolLoad defs before work begins~77,000~8,70085%
Programmatic Tool CallingComplex research task43,58827,29737%

All three rows are Anthropic's published figures. The surprising part isn't the cost — it's the accuracy: with the Tool Search Tool, tool-selection accuracy rose (Opus 4.5 went 79.5% → 88.1%; Opus 4 went 49% → 74%). Fewer tools crowding the context means the model picks the right one more often. Cost and quality move the same direction here, which is rare.

Fix 1 — Load tool schemas on demand​

Instead of injecting all schemas upfront, mark them defer_loading: true. Claude then sees only a lightweight index; when it needs GitHub, it calls the Tool Search Tool, which returns only the matching GitHub schemas — not the 50+ tools from every other server. Anthropic reports this preserves ~191,300 tokens of context versus ~122,800 with everything preloaded.

You are watching this pattern right now if you use Claude Code with many MCP servers: tools arrive deferred, and the agent fetches each schema through a search step only when a task needs it. Community reports say Claude Code auto-enables MCP Tool Search once your connected tool descriptions would exceed ~10% of the context window — verify the exact trigger in your version.

Guided walkthrough1 of 3
  1. List active servers and roughly how many tools each publishes. A server you connected for one task last week is still taxing every turn today.

Fix 2 — Keep results out of context with code execution​

The deeper fix targets Cost 2. Instead of the model calling tools one-by-one with every result passing through it, the model writes code that calls the tools, and the intermediate data stays in the execution environment. Anthropic exposes MCP servers as a file tree of tools the agent explores like a filesystem, loading only the definitions it needs — and "intermediate results stay in the execution environment by default… the agent only sees what you explicitly log or return."

That single design change is what collapses the Drive→Salesforce workflow from 150,000 to 2,000 tokens: the records move through code, and only the final count comes back to the model. On the Developer Platform the same idea ships as Programmatic Tool Calling — Claude writes Python that orchestrates several tools and filters outputs before they ever hit its context.

Pro tip
  • Rule of thumb: if a tool RETURNS something big (a transcript, a query dump, a file), you want code execution so the blob is processed out-of-context. If a tool just DOES something small (create an issue, send one row), a direct call is fine.

Fix 3 — Know when a CLI call just wins​

Sometimes the right answer isn't a better MCP setup — it's no MCP at all. The HN/X argument has a real point: a shell command like gh pr list or psql -c '…' costs a couple hundred tokens round-trip, while the equivalent MCP path pays for schemas plus a structured result. If the agent already has a terminal and the CLI exists, that's often the leanest path.

Prefer the CLI when the tool is already a CLI

# Instead of connecting a GitHub MCP server for read-only work,
# let the agent use the gh CLI it already has:
gh pr list --state open --json number,title,author

# ~200 tokens of command + compact output, no schema tax,
# no server to keep connected across the session.

MCP earns its overhead when you need typed, permissioned, cross-surface capability — a database with a read-only role, a browser it can drive, a SaaS API with OAuth — or when the same tools are reused across many turns so caching amortizes the schema cost. Reach for a CLI when the capability is a one-off, already scriptable, and returns something small. Neither is "better"; they're different points on a cost curve.

Key takeaways
  • MCP has two token costs: tool-definition schemas (paid ~every turn) and intermediate results (scales with your data).
  • Tool Search + defer_loading cut the schema cost ~85% AND raise tool-selection accuracy — load schemas only when searched.
  • Code execution / Programmatic Tool Calling keep big results in the execution environment; only what you log or return reaches the model (150k → 2k in Anthropic's example).
  • The cheapest optimization is connecting fewer servers per task.
  • When the capability is a one-off that returns something small and already has a CLI, a shell call (~200 tokens) beats an MCP round-trip.
MCP economics terms
اضغط Enter أو مفتاح المسافة لقلب البطاقة. استخدم مفتاحي السهمين الأيسر والأيمن للتنقل بين البطاقات.تم إظهار المصطلح.
1 / 5

Check yourself

0/4
  1. Why is the tool-definition cost worse than a one-time fee?
  2. A tool pulls a 2-hour transcript and hands it to a summarizer tool via direct calls. What's the hidden cost?
  3. You need a single read-only 'list open PRs' during a coding session and the agent has a terminal. Leanest option?
  4. What surprising thing happens to tool-selection accuracy when you use the Tool Search Tool?

Sources & further reading​