Connect five MCP servers to an agent and it can burn roughly 77,000 tokens before it reads a single word of the actual task. That figure isn't logs or data — it's just tool definitions, the JSON schemas describing what each of the 58 tools does, pasted into the context window at the start of every conversation. Add a couple of fat tool results and you can cross 50,000 tokens of pure overhead before real work begins. You pay for that on every turn, and the model has to read past all of it to find the three tools it actually needs.
The reflex, when an agent underperforms, is to give it more: every tool, every doc, the whole schema, so it "has what it needs." Two pieces of recent work from Anthropic argue the opposite. Give the agent a way to find context on demand instead of shipping it all up front, and both the bill and the accuracy move in your favor at the same time.
The upfront-loading tax
The default posture of most agent frameworks is eager loading. Every registered tool's full definition sits in the context window from turn one, whether the current task touches it or not. The cost grows linearly with how many servers you plug in, and it compounds: those tokens are re-sent on every inference pass in the conversation, not just once.
The subtler cost isn't money. A window stuffed with 58 tool schemas is a bigger haystack for the model to search when it decides which tool to call. Irrelevant definitions act as distractors. So eager loading quietly buys you two problems: a higher token bill and a harder selection problem.
The first fix is to stop pasting every schema in and hand the model a way to look them up. Anthropic's Tool Search Tool splits tool use into two phases. In discovery, the agent sees only a lightweight search tool that queries a local index (regex or BM25 over tool names and docstrings). In loading, once it identifies something useful, the full definition expands into context for the next turn. Tools you want held back are marked defer_loading: true:
{
"tools": [
{ "type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex" },
{ "name": "github.createPullRequest", "defer_loading": true },
{ "name": "github.mergePullRequest", "defer_loading": true }
]
}
The arithmetic on that five-server, 58-tool setup: upfront consumption drops from about 77K tokens to about 8.7K, plus roughly 3K for the three-to-five tools the agent actually pulls in — an 85% reduction while keeping the full library reachable.
The number I'd stare at, though, is accuracy. On MCP evaluations with large tool libraries, enabling the search tool moved Opus 4 from 49% to 74%, and Opus 4.5 from 79.5% to 88.1%. Less in the window, more correct answers.
The counterintuitive result is that removing tools from context doesn't handicap the model — it sharpens it. Fewer distractors, a cleaner selection problem.
Let the code hold the context, not the model
The second technique attacks the other half of the overhead: intermediate results. In classic tool calling, every result round-trips through the context window on its way to the next call. Read a 10,000-row spreadsheet to filter for five rows, and all 10,000 rows land in context.
Presenting MCP servers as a code API changes that. Instead of exposing tools as direct calls, expose them as typed functions in a filesystem the agent explores and imports from:
servers/
├── google-drive/
│ ├── getDocument.ts
│ └── index.ts
└── salesforce/
└── updateRecord.ts
The agent reads only the tool files a task needs — progressive disclosure, not a preloaded catalog — then writes code that chains them:
const doc = await gdrive.getDocument({ documentId: "abc123" });
await salesforce.updateRecord({
objectType: "SalesMeeting",
recordId: "00Q5f000001abcXYZ",
data: { Notes: doc.content },
});
The transcript flows from one system to the next inside the sandbox and never enters the model's context. Filtering that spreadsheet happens in code; the model sees the five rows that survive. Anthropic's Google Drive-to-Salesforce example ran about 150,000 tokens as direct tool calls and about 2,000 tokens rewritten this way — a 98.7% cut. On complex research tasks, the same "let code orchestrate the tools" pattern brought average usage from 43,588 down to 27,297 tokens, a 37% reduction, with accuracy again edging up rather than down.
Why a smaller window makes a smarter agent
It's easy to file both of these under cost savings and move on. The accuracy figures say that's only half the story. A context window is a budget with diminishing returns: past some point, each additional token of marginally relevant material makes the model's job harder, not easier. Every unused tool schema is noise the model has to reason around. Just-in-time retrieval keeps the working set small and pertinent, and small-and-pertinent is exactly the condition models reason best under.
That reframes the design goal. You're not trying to give the agent everything; you're trying to give it a small, sharp working set plus a reliable way to reach for the rest.
When not to bother
This isn't free, and it isn't always worth it. If your agent has a handful of tools, skip it — the search tool plus an extra discovery round-trip costs more tokens and latency than it saves, and you should just load them. Deferred loading adds a round trip whenever the model needs a tool it doesn't already hold, which is a latency tradeoff. Code execution needs a real sandbox: infrastructure to run and isolate, plus a security surface to defend. The crossover point where dynamic discovery pays off is somewhere past a few dozen tools or once intermediate results start dominating your token budget.
The takeaway
Measure before you optimize: count the tokens your agent loads before it does any work. Add up the tool definitions present at conversation start, and check how many of them a typical task actually uses. If that number is large and mostly idle — the common case once you've wired in a few MCP servers — flip the default. Keep the always-used tools resident, mark the long tail defer_loading, and push bulk data manipulation into code so results never transit the window. You end up handing the model less to read and a way to fetch the rest, and on Anthropic's own numbers that trade buys you lower cost, lower latency, and higher accuracy at once.
Sources: Introducing advanced tool use on the Claude Developer Platform, Code execution with MCP: building more efficient AI agents