Many tools vs code — Guided reading
Curso MCP Engineering · M4
This reading accompanies a real and open controversy in the MCP community (2025): is it better to expose many tools (one per endpoint) or few tools + code? You'll read it from scratch, with both positions quoted fairly. The goal is not for you to memorize "the right answer" —there isn't one yet—, but for you to come out knowing how to reason about the trade-off for your own case. That, precisely, is capstone-level thinking.
Why this matters
Up to here you learned to build MCP servers that expose tools. The natural reflex is: "I have 30 endpoints in my API → I expose 30 tools". And it works. But in 2025 an honest debate opened about whether that reflex is the best way to work. It's not a matter of style: it touches how much it costs (in tokens and money), how well the model chooses, and how secure and debuggable your system ends up.
Position A — "Many tools, one per endpoint" (the ecosystem default)
It's the dominant pattern today. An MCP server publishes a large catalog: if your product has 40 operations, it exposes 40 tools, each described so the model can pick it. Its advantages are honest:
- Straightforward to build: it maps 1:1 with your API, no extra layer.
- Explicit: each action has its name and its schema; you see exactly what the agent can do by looking at the list.
- Deterministic and auditable: if something fails, you know which tool it was. Every step is logged.
- Easy to debug: "what the agent did" is a clear sequence of calls.
Most of the MCP servers you'll find in the world work this way, and for many cases it's more than enough.
Position B — "You don't need 30 tools, you need code" (the critique)
The counter says: loading dozens of tools has a hidden cost. Each tool travels to the model with its name, description and schema on every call —that consumes context tokens before the agent does anything— and degrades the selection (with too many similar options, the model chooses worse). Those who argue it, with names and data:
- Anthropic Engineering — in "Code execution with MCP" it showed a case where going from loading the whole catalog to running code that calls the tools on demand lowered usage from ~150,000 → ~2,000 tokens. The idea: the agent writes code that invokes only what it needs, instead of having all 100 tools always present.
- Armin Ronacher summed it up sharply: "your MCP doesn't need 30 tools, it needs code" — giving the model an environment where it programs the orchestration pays off more than inflating the catalog.
- Simon Willison put the number that hurts: the GitHub MCP runs around ~93 tools and can take up ~55,000 tokens in definitions alone — context spent before starting.
- The newest turn (thread from December 2025, "Skills vs dynamic MCP loadouts") adds a third way: Skills and loading tools dynamically (only the ones relevant to the task), instead of all at once.
The trade-off on a scale
| Many tools | Few + code | |
|---|---|---|
| Context tokens | High (all present always) | Low (only what's used) |
| Model selection | Worse if there are many similar ones | Tends to improve |
| Determinism / auditing | High: every step explicit | Lower: the logic lives in a generated script |
| Debugging | Easy: you know which tool failed | Harder |
| Security | Bounded to the tool set | Requires sandbox (executed code) |
Neither position is free. Many tools is more deterministic and debuggable, but expensive in tokens and with worse selection as the catalog grows. Few + code is much more token-efficient and tends to choose better, but opens a security risk (what can that code touch?), is less deterministic and harder to debug.
State of the debate: no winner
It's a genuinely open debate (August → December 2025). Nobody "won", and it would be a mistake for this reading to sell you a side. It's not that one position "is right": it's that they optimize different things —tokens and selection on one side, determinism and auditability on the other— and which one suits you depends on your context. The healthy conclusion is not to pick a team, but to measure your case.
How to decide for YOUR case
Don't follow the trend; ask yourself these questions.
- How many tools do you have? With few (say <15) and clearly distinct, the direct catalog is perfect. The problem appears when the catalog grows and fills with similar tools.
- How much do they weigh in tokens? If your definitions inflate the context and you see the model choosing wrong, that's a sign to move part of it to code or dynamic loading. Measure it before deciding.
- How critical is it to audit every step? In regulated or sensitive environments, the determinism of explicit tools may be worth more than saving tokens.
- Can you run code safely? If you go the code route, the sandbox (isolating what that code can touch) stops being optional.
Practical rule: start simple (explicit tools), measure tokens and selection quality, and move toward code/Skills only when the pain shows up. Evidence-guided optimization, not dogma.
Reflection questions
- How many tools does your server expose? Are they distinct from each other or do they look alike and confuse the model?
- How many tokens do your definitions take up before the agent does anything? Have you ever measured it?
- Do you notice the model choosing wrong as the catalog grows?
- How critical is it in your product to audit every step (regulated environments, sensitive data)?
- If you went the code route, could you run it isolated (sandbox) safely?
- What is your case asking for today: explicit simplicity or context efficiency?
Quick glossary
- Tool: an action that your MCP server exposes for the model to use.
- Context / tokens: the model's "reading space". Each loaded tool consumes it, even unused.
- Tool selection: the model's decision about which tool to call; it gets worse with too many similar options.
- Code execution: the agent writes code that calls the tools on demand, instead of having them all present.
- Skills: packaged capabilities that the agent loads when it needs them.
- Dynamic loadout: loading only the subset of tools relevant to the current task.
- Determinism: that the same input produces the same behavior, easy to audit.
- Sandbox: isolated environment that limits what the executed code can touch (security).
To remember
- No winner yet. It's a trade-off, not a dogma.
- Many tools = deterministic and auditable, but expensive in tokens and worse selection as it grows.
- Few + code / Skills = token-efficient and better selection, but less deterministic, harder to debug and with a security risk (that's why: sandbox).
- Method: start simple → measure tokens and selection → move to code/Skills only when the pain shows up. Evidence, not trend.
Turning Point Academy · MCP Engineering Course · Module 4 · Guided reading of the debate