Scout7 logo

Scout7

Back

how_to_playbook

MCP Tool Optimization: Stop Counting Your Agent's Tools. Start Reading Them In Pairs.

September 2, 2026 · 10 min read · Scout7

Most tool-calling errors come from overlapping MCP definitions. Learn how to audit, merge, and prune tools to improve agent selection.

MCP Tool Optimization: Stop Counting Your Agent's Tools. Start Reading Them In Pairs.

Introduction

Your agent calls the wrong tool for a simple reason. Two of your tools look valid at the same time, so it has to guess. The fix is not only shrinking the context. In practice, MCP tool optimization means finding the overlapping pair, merging it, and rewriting the description so there is nothing left to guess about.

Key takeaways:

  • Wrong-tool calls often come from overlapping descriptions, not just tool count
  • Pruning and retrieval help first, but still leave routing residue
  • Merging the right pair can beat broad tool-count reduction
  • Test ambiguous prompts to measure real selection accuracy

Picture the servers you have connected. One team wrote the publishing tools. Another wrote the scheduling tools. A third added search. Your agent sees them all at once, and picks the one whose description sounds close enough.

That failure is easy to miss, because the output still looks plausible. There is no error. The agent calls the wrong function, gets a valid-looking answer back, and carries on.

This piece explains why tool selection breaks, and how to find the problem by reading your tools in pairs instead of counting them.

The overlap trap: why your agent is confused

The overlap trap: why your agent is confused

And once you look at the failure this way, the problem gets narrower. Your agent is often not drowning in tools; it is hesitating between two tools that promise almost the same thing.

A tool description is the short text that tells the model what a tool does. Tool selection is the step where the model decides which function to call for the task in front of it.

  • Separate MCP servers create overlap naturally because different teams name similar actions differently
  • Surface-level similarity is enough to trigger confusion before context length becomes the main issue
  • One new sibling tool can degrade routing even if total tool count barely changes
  • Wrong calls look normal because the run continues with a plausible output

Adaline Labs showed this clearly: adding one file-search function whose description partly overlapped with bash hurt selection immediately. One tool was added, and no context-pressure story was needed.

This is not a sign of a careless setup, and it is worth being clear about that. The toolsets ToolScope merged were standard public benchmarks, not somebody's private config, and merging still found pairs to remove.

The mechanism is ordinary. Every MCP server is written by a different team. Each one describes its own tools sensibly, on its own terms. Nobody is holding the combined list. So when you connect the fifth server, you end up with two tools that describe themselves almost identically, and no person wrote that pair. It appeared.

So the next question is fair: if overlap is the hidden trap, what do standard fixes already solve?

What cutting and searching already fix

What cutting and searching already fix

The standard advice is still right. Start by cutting tools and adding retrieval, because both improve performance before you touch descriptions.

Anthropic's own measurements of its Tool Search Tool showed a five-server MCP setup at about 55,000 tokens, with Jira adding another 17,000. After tool search, definitions fell from about 77,000 to 8,700 tokens, an 85% reduction.

  • Opus 4 accuracy rose from 49% to 74%, according to Anthropic
  • Opus 4.5 accuracy rose from 79.5% to 88.1%, in the same Anthropic measurement, published 24 November 2025. This is a vendor measuring its own feature, and worth reading as such
  • GitHub Copilot cut built-in tools from 40 to 13, gaining 2 to 5 points and lowering latency by about 400 ms in GitHub's report, published 19 November 2025
  • RAG-MCP improved selection from 13.62% to 43.13% in Gan and Sun's paper

GitHub's own list of symptoms is worth repeating: the agent can ignore explicit instructions, use tools incorrectly, and call tools that are unnecessary. That is free performance territory. Do it first.

But even the best published numbers leave a residue. If one call in eight is still wrong after search, you need something more specific than "fewer tools".

Step 1: MCP tool optimization starts with a registry audit

Step 1: MCP tool optimization starts with a registry audit

That residue usually appears fast once you inspect the registry the right way. The bottleneck is not exporting tools; it is noticing when two plain-English descriptions collapse into the same promise.

Start with a full list from all connected servers. Then regroup tools by user intent, not by server ownership.

  • Export all tools from every connected MCP server
  • Group by intent like create, update, search, publish, schedule, fetch, run
  • Read descriptions side by side instead of one tool at a time
  • Flag any pair where you cannot say in one sentence which one a given task should use
  • Mark competing prompts that could plausibly fit both tools

The protocol is moving in this direction too. The MCP specification revision from 2026-07-28 added server/discover, plus ttlMs and cacheScope, making on-demand capability discovery part of the protocol itself.

That helps with loading, but it does nothing about ambiguity. Fetching a tool on demand does not make it easier to tell apart from its twin. Discovery is a delivery mechanism, not a disambiguation one.

Once you see the competing pairs, the next move is not broad deletion. It is a targeted merge.

Step 2: The merge-and-parameterize playbook

Step 2: The merge-and-parameterize playbook

This is the shift most teams miss. After pruning and retrieval, the biggest gain often comes from merging one overlapping pair, not from chasing a lower total tool count.

A common pattern is sibling tools like create_post and schedule_post. Ask for "a LinkedIn post prepared for next Tuesday". If both descriptions sound valid for that, the model has to guess.

  • Merge sibling tools into one higher-fidelity tool
  • Use parameters like mode=create or mode=schedule
  • Rewrite the description to say when to use it
  • Add a "do not use" line to separate nearby alternatives
  • Optimize for distinction, not minimalism by itself

This is where the central evidence lands. ToolScope found that on GPT-4o, retrieval alone reached 69.4% on Seal-Tools, but merging overlapping tools first and then applying the same retrieval raised accuracy to 91.2%. In the fuller ToolScope HTML version, Seal-Tools removed only 2.1% of tools yet gained 21.8 points.

The twist is the whole argument: it was not how many tools disappeared, but which overlapping pair got merged.

That is the narrow claim most retrieval guides skip. Guo, Dong, Gao, and Das reinforce it by showing that ambiguity, overlap, and underspecification can be fixed directly in the descriptions themselves.

So after basic pruning is in place, the highest-leverage work is often one text edit and one merge.

Step 3: Measuring retrieval precision

Step 3: Measuring retrieval precision

And then you have to prove it. If you do not test tool routing directly, wrong-tool calls stay invisible because the workflow still returns something that looks usable.

Build a compact test set around the overlapping pairs you flagged. Do not test only happy-path tasks.

  • Write ambiguous prompts that could plausibly trigger either tool
  • Record chosen tool and expected tool for each prompt
  • Note plausible-but-wrong outputs that would slip past casual review
  • Compare precision before and after each merge
  • Judge by task accuracy, not token count alone

If you want the whole method in one sentence: prune the visible list, add retrieval, then test routing on ambiguous prompts and merge any two tools that still compete for the same task.

Be honest about the ceiling while you do this. Anthropic's own table shows 88.1% on Opus 4.5 with tool search switched on. That is roughly one call in eight still going somewhere wrong, with the strongest model and the best tooling from the company that wrote the protocol. There is no number that reaches 100, so do not wait for one. The win you can actually see is a smaller set of pairs that compete.

And because overlap reappears over time, the last step is not a one-off cleanup.

Step 4: Continuous pruning

Step 4: Continuous pruning

The overlap comes back the same way it arrived: one sensible new server at a time. Nobody intends to create twins, but connected systems create them anyway.

That is why pruning should stay light, regular, and specific. Treat every newly added tool as a candidate overlap, not as a harmless addition.

  • Review each new tool against existing descriptions before registry inclusion
  • Ask one question: what task would make these two tools compete?
  • Merge early when two tools answer the same intent
  • Rename or rewrite if a full merge is too expensive
  • Retest ambiguous prompts after every new server connection

The ToolScope benchmark analysis makes this point stronger, not weaker. These were standard public benchmarks, not sloppy private configs, yet merging still removed 25.3% of UltraTool and 14.0% of BFCL.

In other words, overlap is normal. The discipline is not preventing every duplicate forever; it is catching the competing pair before it degrades selection.

The real fix is distinction

The real fix is distinction

Key takeaways:

  • Start with pruning and search because they produce free performance gains
  • Fix the residue by merging overlap instead of just lowering total tool count
  • Measure ambiguous routing directly because plausible outputs can hide wrong calls

Most wrong-tool calls are not dramatic failures caused by a huge context window. They are small routing mistakes. They happen when two separately built MCP servers bring in descriptions that sound alike at the moment of choice.

So the playbook is narrow. First, reduce the visible list and add retrieval. The evidence from Anthropic, GitHub and RAG-MCP shows that works, and it should be your default. But if your agent still routes badly, do not reach for more pruning. Read the descriptions in pairs. Group them by what a user is actually trying to do. Merge the twins. Then write one description that says what it does, when to use it, and when not to.

The job is small. Open your connected tool list and find the two tools a stranger could not tell apart. That is an afternoon of work, and on the evidence it is worth more than another round of deleting.

The forward path is not perfection. It is making two descriptions tell each other apart.

Or there is another way, and Scout7 runs the whole marketing loop from one command, so the agent never has to pick.

Frequently asked questions

Is the main problem too many tools, or overlapping tools?

This article argues that overlap is often the more immediate problem. An agent is frequently not drowning in tools; it is hesitating between two tools that sound valid for the same task.

Should I prune tools before I start merging them?

Yes. The article recommends starting with pruning and retrieval because both can improve performance quickly. But if wrong-tool calls remain, the next highest-leverage step is often merging one overlapping pair.

How do I spot a pair that should be merged?

Read tool descriptions side by side and group them by user intent, not server ownership. If you cannot say in one sentence which tool a given task should use, that pair is a candidate for a merge or rewrite.

How should I test whether a merge actually helped?

Build a small test set of ambiguous prompts that could plausibly trigger either tool. Then compare the chosen tool and task accuracy before and after the merge, because plausible outputs can hide wrong calls.

References