The open debate: many tools vs fewer + code?

The open debate: many tools or few + code? (and their risks)

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 up about whether that reflex is the best way to work. It's not a minor detail: it touches how much it costs (in tokens and money), how well the model chooses, and how secure and debuggable your system is. It's a debate still without a winner, and knowing how to stand in the middle with judgment is what separates an MCP engineer from someone who just copies the trendy pattern.

What you'll learn

• The two positions in the debate and who defends each one (with names and data).
• Why "one tool per endpoint" burns context and why sometimes it doesn't matter.
• The real trade-offs: determinism and debugging vs. token efficiency; and the security of running code.
• A simple method to decide in your case — without dogmas.

Position A — "Many tools, one per endpoint" (the ecosystem default)

It's the dominant pattern today. An MCP server publishes a large catalog of tools: if your product has 40 operations, it exposes 40 tools, each described so the model can choose it. Honest advantages: it's straightforward to build (maps 1

with your API), it's explicit (each action has its name and schema), and it's easy to reason about — you see exactly what the agent can do by looking at the list. 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 counterargument 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 selection (with too many similar options, the model chooses worse). Who argues it:

• Anthropic Engineering — in "Code execution with MCP" showed a case where going from loading the whole catalog to executing code that calls the tools on demand cut 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 you start.
• The newest turn (a December 2025 thread, "Skills vs dynamic MCP loadouts") adds a third path: Skills and loading tools dynamically (only the ones relevant to the task) instead of all of them at once.

The trade-off, with no winner

No position is free. Weigh it up:

• Many tools → more deterministic and debuggable: each action is explicit and auditable; if something fails, you know which tool it was. Price: more tokens and worse selection when the catalog grows.
• Few + code → much more token-efficient and usually chooses better. Price: running code the model wrote opens a security risk (what can that code touch?), it's less deterministic and harder to debug (the "what it did" is inside a generated script, not in a list of calls).

That's why the debate is genuinely open (August → December 2025). It's not that one side "is right" — it's that they optimize different things, and which one suits you depends on your context.

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 just fine. The problem shows up 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 choose wrong, that's a sign to move part of it to code or dynamic loading.
• 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.

Quick glossary

• Tool: an action 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 the agent loads when it needs them.
• Dynamic loadout: loading only the subset of tools relevant to the current task.
• Determinism: the same input producing the same behavior, easy to audit.
• Sandbox: an isolated environment that limits what the executed code can touch (security).

To download

• 📄 Guided reading — Many tools vs code (PDF: a position-by-position comparison of who argues what, reflection questions, and a "To remember").

Before moving on

If you keep one idea: in MCP there's no single right way yet. The ecosystem default (many tools) and the critique (few + code/Skills) optimize different things — tokens and selection on one side, determinism and auditability on the other. Your job as an engineer isn't to pick a side, but to measure your case and decide with judgment. That is, precisely, the capstone level.