Connect five MCP servers to an agent and something quietly expensive happens: before the user types a single word, the model's context is already carrying every tool's full schema — names, parameters, descriptions, examples. Anthropic measured a heavy setup spending roughly 150,000 tokens on tool definitions alone, and about 78.5% of input tokens going to definitions the agent never touched on that turn. That's slower, pricier, and it shrinks the window left for the actual work.

The short answer: there are three real fixes, they all follow one principle — progressive disclosure, don't load a tool until it's needed — and the right one depends entirely on how dynamic your tool set is. Stable handful → curate. Dozens that shift → tool search. Hundreds you chain and filter → code execution.

Fix 1 — Curation: a small tool budget, gated#

The lowest-tech fix is the one most teams skip: don't connect everything. Pick the ten or fifteen tools the agent genuinely needs, load those, and gate the rest behind an explicit "load more" step. Microsoft's Agent Framework formalizes this as a discover / load / unload lifecycle — the agent sees a catalog, loads a tool into its budget when a task calls for it, and unloads it after. We covered that mechanism in Microsoft's progressive MCP disclosure.

Use it when your tool set is stable and small. The cost: manual upkeep, and the agent structurally cannot reach a tool you didn't pre-load. For a focused single-purpose agent, that constraint is a feature.

Fix 2 — Tool Search: discover schemas on demand#

Tool search keeps ordinary MCP call semantics but defers the expensive part. The model holds only tool names and short descriptions; when a task matches, it fetches the full schema for just those tools, then calls them normally. You keep the familiar tool-call flow and the clean audit trail of discrete calls — you just stop paying for schemas you're not using this turn.

Use it when you have dozens of tools and which ones matter changes task to task. The cost: a discovery round-trip whenever the agent reaches for something new. We put this head to head with the alternative in Too Many Tools: Tool Search vs Code Execution.

Fix 3 — Code Execution: tools as a code API#

The most aggressive fix changes the interface entirely. Instead of exposing each tool as an individual callable, you expose them as a code API and let the agent write code — usually Python or TypeScript — that calls tools inside a sandbox. The model gets only tool names and truncated descriptions in its prompt; the real schemas live in the code environment. Crucially, intermediate results (a 40,000-row query, a large file) stay in the sandbox and never re-enter the context window — the agent filters and summarizes in code and returns only what matters.

That's where the dramatic numbers come from: Anthropic reported one workload dropping from 150,000 tokens to 2,000 — about a 98.7% reduction — by moving from individual tool calls to code execution. We walked the mechanics in MCP Code Execution vs Direct Tool Calls.

Use it when the agent chains many tools, loops over results, or filters large outputs. The cost: you now run a code sandbox and you trust the model to write correct glue — a real operational surface, not free.

The decision, in one line#

Don't argue "which is best." Ask how dynamic and how large your tool set is:

And you don't have to choose globally. The mature pattern composes all three: a small curated core always on, the long tail behind tool search, and the heavy chaining workflows switched to code execution. The 2026-07-28 MCP spec makes this easier — a stateless core means these routing decisions no longer fight a sticky-session gateway.

The tax is real and it's silent. Measure your agent's token spend before the first user turn — if a five-figure number shows up and you haven't picked one of these three, that's your cheapest available speedup, sitting untouched.