Context efficiency — Cheat Sheet
Curso MCP Engineering · M4
This guide explains, from scratch and taking nothing for granted, one of the most important problems you hit as your MCP server grows: what happens when you give the model too many tools, and the three proven ways to avoid it. Even though this is an advanced module, we explain it top to bottom. Read it calmly and come back to it every time you design a server.
In one sentence
Wrapping every endpoint of your API as a tool and handing them all to the model inflates the context window (the definitions are heavy, and the intermediate results pile up) and degrades the selection of the right tool. That deterioration is called context rot ("rotting" of the context). The good news: there are three concrete levers to avoid it.
The problem: tool-sprawl and context rot
When you connect a model to tools, the temptation is obvious: one tool per endpoint, and all of them loaded up front. With 3 or 4 it works perfectly. But once you add several MCP servers and reach dozens of tools, the system starts to get worse, not better. That's tool-sprawl (the explosion of tools).
Each tool costs context twice:
- Its definition — name, description and parameter schema travel in the prompt always, even if that tool is never used in the conversation.
- Its intermediate results — if the model calls tool after tool, each raw response keeps piling up in the context and fills it with noise.
The effect is twofold and bad: the context inflates (more tokens = more cost and slower) and —worse— with 50 similar descriptions the model chooses wrong more often. That drop in quality when the context fills up with things that get in the way is context rot.
The three techniques
| Technique | What it does | Saving |
|---|---|---|
Tool Search Tool (defer_loading: true) | You pass it a single search tool; the heavy definitions load on demand, only when the model needs them | ~77,000 → ~8,700 tokens |
| Programmatic Tool Calling | The model writes a script that calls the tools in a sandbox and returns only the final result; the intermediate data stays in the sandbox | 150,000 → 2,000 tokens (~98.7% less) |
| Fewer tools, more "high-level" | You redesign: few tools that do complete tasks, not one per endpoint | Less surface = better selection |
Mitigation 1 — Tool Search Tool
Instead of sending all 50 full definitions up front, you pass the model one small search tool and mark the rest with defer_loading: true. The heavy definitions don't travel until they're needed: the model searches for the right tool and only then is its full definition loaded on demand. In Anthropic's measurements, the tool context dropped from ~77,000 to ~8,700 tokens.
Mitigation 2 — Programmatic Tool Calling
Instead of requesting a tool, receiving the raw result, requesting another, and so on —filling the context with each step—, the model writes a script that calls the tools inside a sandbox (isolated environment) and only returns the final result. Anthropic's measurement: one flow went from 150,000 to 2,000 tokens, a reduction of ~98.7%.
Careful, don't mix two different results. The 150k → 2k (~98.7%) jump is from a specific flow with Programmatic Tool Calling. Separately, and as a different result, Anthropic reported ~37% fewer tokens on complex research tasks. They are two numbers from two different experiments — don't add them up or confuse them.
Mitigation 3 — Fewer tools, and more "high-level"
The third lever is about design, not mechanism: instead of 20 tools that mirror 20 endpoints, expose a few high-level tools that do complete tasks. Less surface, less ambiguity, better selection. It's usually the simplest solution and the first one you should try.
The safety rule that is not optional
Running code that the model wrote (Mitigation 2) requires a secure sandbox: isolated, with minimal permissions, without free access to your machine or your secrets. Never run that code loose. This point is covered in depth in the security lesson of the module — but keep it in mind from now on: the token saving isn't worth opening a security hole.
The heuristic (rule of thumb)
- Fewer than ~10 tools → give them all directly, don't overcomplicate. Sprawl doesn't hurt yet.
- Many MCP servers / 50+ tools → turn on the Tool Search Tool with
defer_loading. - Flows with many steps and large intermediate results → Programmatic Tool Calling (with a secure sandbox).
- Whenever you can → redesign toward fewer tools, higher-level.
Key moments in the video
- 3:11 — Tool Search Tool: how a single search tool +
defer_loadingavoids loading all the definitions up front (the jump from ~77k to ~8.7k tokens). - 5:09 — Programmatic Tool Calling: the model writes a script that orchestrates the tools in a sandbox and only returns the final result (the collapse from 150k to 2k tokens).
Quick glossary
- Tool-sprawl: the explosion of tools (one per endpoint) that inflates the context and confuses the model.
- Context window: the model's working memory, measured in tokens; it is limited.
- Context rot: the drop in quality when the context fills up with definitions/results that get in the way.
- Tool Search Tool: a search tool that, with
defer_loading: true, loads the heavy definitions on demand. - Programmatic Tool Calling: the model writes code that calls tools in a sandbox and returns only the final result.
- Sandbox: isolated environment with minimal permissions where that code runs safely.
To remember
- More tools ≠ more power. More tools = more noise.
- Each tool costs context twice: its definition + its intermediate results.
- Tool Search Tool = don't load what you don't use (on-demand loading): ~77k → ~8.7k.
- Programmatic Tool Calling = the intermediate data stays in the sandbox: 150k → 2k (~98.7%).
- Different from the previous point: ~37% fewer tokens on complex research — don't confuse it.
- ⚠️ Running the model's code requires a secure sandbox → covered in depth in security.
Turning Point Academy · MCP Engineering Course · Module 4 · Context efficiency