Blog / How to optimise your MCP tools by knowing how agents call them
Fewer, bigger tools or many small ones? What a 4-tool vs 99-tool test shows
“Should I merge my MCP tools or split them?” is usually asked as if tool count decided whether agents succeed. In our test it didn't. What decided it was whether the agent knew where to start, and how heavy each tool was.
The test
A stand-in server with a production server's 99 tools, and a 4-tool version: a get_instructions start-here tool plus the 3 tools the jobs' first step needs. Both had the same “call get_instructions first” recipe. Claude Code and Codex, the same job requests.
“Right first steps” means: called the start-here tool first, chose the right job, and followed step 1. What moved the score was the recipe, not the count. More: make agents read your instructions first.
Find out whether your tool count is the problem.
We run your users' jobs through the agent apps they use and show whether failures come from count, size, naming or overlap.
What tool count changed
| Tokens before first call (median) | 4 tools | 99 tools |
|---|---|---|
| Claude Code | 4.5k | 6.3k |
| Codex | 40.0k | 43.8k |
A saving, not a fix. In apps with tool search the 95 extra tools cost little up front. In apps that preload, they cost every request: OpenCode 1 added 73,415 tokens per request for the 99-tool list. See how many MCP tools is too many.
Weight, not count
- On the 99-tool list (68,730 tokens), two tools were 15,131 and 9,168 tokens: 35% of the list.
- Check your own heaviest tools with the token calculator or the scorecard.
When to merge
- Lookalikes. Two tools that both seem to answer the question split the agent's choice. See why agents call the wrong tool.
- Steps always done together. If every job calls A then B, one tool that does both saves a round trip, and every round trip resends the context.
- Preview + start of the same action: one tool, two phases. See the two-step confirm pattern.
When to split
- Heavy overview tools. Asked for a few numbers, Codex read a project overview in 4 of 5 runs; it returned 14,517 tokens for two projects. Offer a small summary or count tool, and say “for counts use X” in the overview's first line.
- Giant schemas. A tool whose definition is thousands of tokens is often several jobs in one.
Go deeper: Reduce tool response size, Name tools the way users talk, MCP context window usage.
Back to how to optimise your MCP tools.
How we measured
- 4 vs 99: mock servers, Claude Code 2.1.302 and Codex CLI, 232 runs in the full trial on 18 Oct 2026; runs stopped at the first step-1 call. 95% Wilson ranges.
- Tool weights and preload: the live tool list of a 99-tool production server and first-request controls, 16 Oct 2026.
- Overview tool: 5 live Codex status runs through a read-only proxy.
- Limits: one job family; we didn't test a single mega-tool or middle sizes like 20 tools.
FAQ
Should I merge MCP tools or split them?
Merge tools that look alike to an agent, so there's one obvious tool per job. Split or slim tools whose definitions or default results are heavy. Count alone didn't change success in our test once the agent knew where to start.
Does the number of MCP tools affect agent accuracy?
In our test, not by itself: agents scored 12/12 on a 4-tool server and 24/24 on a 99-tool one with the same start-here tool. Without that guidance, results on the 99-tool server were much lower: Claude 1/24, Codex 9/24 followed the intended first step.
When does tool count matter?
In agent apps that load every definition up front (OpenCode 1 in our tests), each tool adds tokens to every request. With tool search, count costs little; names and first lines matter more.
Is one giant tool with an action parameter a good idea?
It cuts count but hides choices in a schema, and its one description must cover everything. We didn't test it; keep tools task-shaped and the obvious one per job.
Find out whether your tool count is the problem.
We run your users' jobs through the agent apps they use and show whether failures come from count, size, naming or overlap.