Tool-calling reliability plateaus at your tool descriptions, not your model.
An agent that calls the wrong tool too often looks like a model problem, so teams reach for a bigger model or a fine-tune. The wrong calls cluster where two tools look near-identical to the model — and rewriting or de-duplicating the ambiguous descriptions recovers double-digit accuracy a bigger model does not. The tool interface is a primary ceiling on tool-calling reliability, and the model's own choice margin is a usable pre-execution alarm.
A team’s agent calls the wrong tool too often. Not catastrophically — the agent works, it demos well, it shipped — but a stubborn fraction of runs reach for a tool that does not fit the request, and the fraction does not go down. The team does the thing the symptom suggests. The model is not choosing well, so give it a better model: they upgrade to the strongest one available, and the wrong-tool rate moves a little. They fine-tune the agent on traces of correct tool use, and it moves a little more. But the rate is sticky in a way a capability problem should not be — each smarter model keeps not fixing it, and the curve flattens well above zero.
The stickiness is the clue. A genuine reasoning deficit would ease as the model improved. This does not, because the wrong calls are not spread evenly across the toolset. They concentrate — on a few pairs of tools that, to the model, look almost the same. And how similar two tools look to the model is not a fact about the model. It is a fact about the names, the descriptions, and the schemas the team wrote.
“A smarter model” and “a clearer set of tools” fix different bottlenecks, and the team has been buying the first to fix the second. The gap between them is the subject of this post.
This post is about why tool-calling reliability plateaus at the quality of the tool interface rather than the capability of the model, why rewriting ambiguous tool descriptions recovers accuracy a bigger model does not, why the model’s own choice margin is a usable pre-execution alarm, and where this stops being true.
The model is choosing between your descriptions
Start with what actually happens when an agent selects a tool, because the mental model most teams carry is slightly wrong and the slight wrongness is the whole problem.
The intuitive picture is that the model understands what each tool does and picks the one whose function matches the request. That is not the operation. At selection time the model does not have the tool — it has the tool’s description: a name, a sentence or two of prose, a parameter schema. It pattern-matches the request against those strings. The model is not choosing between your tools. It is choosing between your descriptions of them.
That matters because tool descriptions are, almost always, written for human developers, and human developers tolerate an ambiguity that an agent cannot. A human who sees create_record and add_entry in an API does not agonize — they read the surrounding documentation, glance at the source, check which one the rest of the codebase uses, or ask the person at the next desk. The model has none of that. It has the two strings, in the prompt, and nothing else. If create_record and add_entry have overlapping descriptions, then to the model they are not two tools with a subtle distinction. They are, functionally, one tool with two names, and which one the model picks is close to a coin toss it has no way to win.
Learning to Rewrite Tool Descriptions for Reliable LLM-Agent Tool Use (arXiv 2602.20426) states the premise without softening it: agent performance “increasingly plateaus due to the quality of the tool interfaces these agents consume,” and “tool descriptions are often written for human developers and tolerate ambiguity that agents cannot resolve, particularly as the number of candidate tools grows.” The interface is the model’s entire view of the tool — the same point this blog has made about tools as model-facing prompt surface, where the schema is the prompt. A description written as developer documentation is a prompt written for the wrong reader.
Rewriting the descriptions recovers what a bigger model cannot
If the bottleneck is the interface, then editing the interface — without touching the model — should recover the accuracy that a bigger model did not. It does, and the size of the recovery is the argument.
The same paper’s method, Trace-Free+, rewrites tool descriptions, and the gains are not marginal. From 0 to 150 additional tools on StableToolBench, it reduces the performance degradation of the baseline by 29.23% and improves over the baseline by 60.89% on average. Two properties of that result make it diagnostic. First, it is model-agnostic: the rewritten descriptions improve GPT-4.1, Claude Sonnet 4.5, and Gemini-3-pro alike, with no modification to any agent — the same edit to the interface helps every model, which is exactly what you would expect if the interface, not the model, were the binding constraint. Second, it dominates the model-side fix the team in the opening tried: on RestBench, fine-tuning the agent alone moved the baseline by about a single point, while rewriting the descriptions alone moved it by nearly fifteen. The team spent its effort on the lever with the one-point gain.
ToolScope (arXiv 2510.20036) attacks the same defect from the other side — not rewriting individual descriptions but merging the tools whose descriptions overlap. Its premise is the explicit version of the opening’s clue: “real-world toolsets often contain redundant tools with overlapping names and descriptions, introducing ambiguity and degrading tool selection performance.” Merging the redundant tools and filtering the candidate set by context lifts tool-selection accuracy by 34.6% on Seal-Tools, 38.6% on UltraTool, and 8.8% on BFCL. Double-digit accuracy, recovered by editing the toolset rather than the model.
Wrong calls cluster at the ties
If wrong calls concentrate where two tools look alike, there should be a measurable signal, inside the model, that says “this one is a near-tie.” There is, and it is usable.
Tool Calling is Linearly Readable and Steerable in Language Models (arXiv 2605.07990) examines the margin between the model’s top two tool candidates — how far ahead its first choice is over its second. The finding is that the margin tracks the errors. On Gemma 3 12B, the quartile of queries with the smallest top-1-to-top-2 gap has a 14% error rate, while the quartile with the largest gap has a 0% error rate; flagging every query whose gap is below the median catches 92% of the wrong calls. On Gemma 3 27B the same pattern holds, with the lowest-confidence quartile at a 17% error rate against 1% for the highest — the paper summarizes it as the narrow-margin queries producing 14 to 21 times more wrong calls than the wide-margin ones.
That is two things at once. It confirms the diagnosis: wrong tool calls really do cluster at the ties, where two tools are near-indistinguishable to the model. And it hands you an instrument. The margin is computed before the tool runs, so a narrow margin is a pre-execution alarm — a place to insert a confirmation step, a disambiguating question, or a human check, exactly where the model is about to guess. The interface defect tells you what to fix; the margin tells you, in the moment, where the fix has not landed yet.
The defect is everywhere, and it gets worse with scale
Two more results fix the scale of the problem, because a team might reasonably ask whether its own toolset is really this bad.
MCP Tool Descriptions Are Smelly! (arXiv 2602.14878) audits 856 tools across 103 Model Context Protocol servers and finds that 97.1% of the tool descriptions contain at least one “smell,” with 56% failing to state their purpose clearly. The ambiguous tool description is not a corner case a careful team avoids. It is the overwhelming default of the tools an agent will actually be handed. Augmenting those descriptions, the paper reports, improves task success by a median of 5.85 percentage points.
RAG-MCP (arXiv 2505.03275) shows how the defect scales. As the catalog of available tools grows, selection accuracy collapses — and the fix is to shrink what the model sees, retrieving a small relevant subset of tools rather than presenting the whole registry. Retrieval lifts tool-selection accuracy from 13.62% to 43.13% and cuts prompt tokens by more than half; the paper also notes that selection quality starts degrading once the model is choosing from beyond roughly 100 tools. The interface ceiling is not fixed — it drops as you add tools, because every new tool is another chance for an overlapping description, and the model is choosing from a longer list of strings that were never written for it.
What the numbers do not say
Three honest qualifications, because the version of this argument that overstates loses the reader who knows the field.
First, the interface is a primary ceiling, not the only one. Fine-tuning the agent still added a real, if small, gain on top of the description rewrite — the two are complementary, not substitutes — and there are tool-calling costs that have nothing to do with descriptions, such as the protocol and formatting overhead of the call itself. The claim is that the interface is a dominant, fixable bottleneck that teams systematically under-invest in, not that the model never matters.
Second, the selection-margin alarm is not universal. The paper that establishes it is explicit that the effect is weaker on smaller models and on some model families — it depends on how cleanly a given model separates its tools internally — and that its results are from single-turn, fixed-menu settings, with multi-turn agentic transfer noted as “more fragile.” Treat the margin as a strong signal to validate on your own model and your own loop, not as a guaranteed instrument.
Third, rewriting cannot rescue tools that are genuinely the same. The same paper finds steering breaks down entirely when tools are near-synonymous — 0% on a set of ten highly similar APIs. If two tools really do overlap in function, no description edit disambiguates them, because there is no distinction to express. That case is not a writing problem; it is a toolset-design problem, and the fix is to merge or remove, not to reword.
And one practical cost: description augmentation is not free. The MCP audit found that augmenting descriptions also increased the number of execution steps by 67.46% and regressed performance in 16.67% of cases. More description is more context, and more context has its own price. The rewrite is a change to measure, not a change to assume.
Engineering the tool interface
The model is choosing between the strings you wrote. Treat those strings as the engineering surface they are.
Audit the toolset for ambiguity before you touch the model. Read your tool names, descriptions, and schemas as the model sees them — with no access to your docs, your source, or your intent. Look for overlapping descriptions, names that do not state purpose, and pairs a stranger could not tell apart. That audit, not the model upgrade, is the first move when tool selection is unreliable.
De-duplicate and merge near-synonymous tools. Where two tools genuinely do the same job, no rewrite will separate them — the model is right to be unsure. Merge them, or remove one. A smaller, sharper toolset is a better interface than a large one full of near-duplicates.
Rewrite descriptions for the model, not for a human developer. A human tolerates ambiguity because they have context the model does not. Write each description to be self-sufficient: what the tool does, when to use it, and explicitly how it differs from the tool it is most likely to be confused with. This is prompt engineering, because the schema is the prompt.
Retrieve a small relevant tool subset instead of exposing the whole registry. Selection accuracy falls as the catalog grows, and degrades badly past about a hundred tools. Put a retrieval step in front of selection so the model chooses from a short, relevant list — fewer strings to confuse, and a cheaper prompt. This is the same scaling discomfort that drives the gaps in running MCP in production.
Use the selection margin as a pre-execution alarm, where your model supports it. Where the model exposes it and you have validated the signal, treat a narrow top-1-to-top-2 margin as a flag — to ask a disambiguating question, to require confirmation, or to escalate — before the tool runs. Validate it on your own model and loop first; it is weaker on small models and outside single-turn settings.
Measure interface changes, including their cost. Rewriting and augmenting descriptions can raise accuracy and also raise token count, step count, and the regression rate. Treat a description change as a change to evaluate on the cost-quality frontier, not a free improvement.
The checklist
Before you blame an agent’s wrong-tool rate on the model:
The toolset has been audited for ambiguity exactly as the model sees it — names, descriptions, schemas, no external context.
Genuinely near-synonymous tools have been merged or removed, not reworded.
Tool descriptions are written for the model: self-sufficient, stating purpose, and explicitly distinguishing each tool from its nearest neighbor.
When the registry is large, a retrieval step narrows the candidate set so the model never selects from more than a few dozen tools at once.
The selection margin is evaluated as a pre-execution alarm and validated on the actual model and agent loop before being relied on.
Interface changes are measured on accuracy and on cost — token count, step count, regression rate — not assumed to be free improvements.
A model upgrade or fine-tune is pursued only after the interface has been fixed, since the two address different bottlenecks.
Reading list
Learning to Rewrite Tool Descriptions for Reliable LLM-Agent Tool Use (arXiv 2602.20426) — rewriting tool descriptions improves over the baseline by 60.89% on average as the toolset grows, helps GPT-4.1, Claude Sonnet 4.5, and Gemini-3-pro identically with no agent change, and beats fine-tuning the agent (about +15 points versus about +1).
Tool Calling is Linearly Readable and Steerable in Language Models (arXiv 2605.07990) — wrong tool calls concentrate where the top-1-to-top-2 margin is smallest (a 14% error rate versus 0% on Gemma 3 12B; 14–21x concentration), and flagging below-median-margin queries catches 92% of errors — though the effect is weaker on small models and outside single-turn settings.
MCP Tool Descriptions Are Smelly! (arXiv 2602.14878) — 97.1% of 856 audited Model Context Protocol tool descriptions contain at least one defect and 56% fail to state their purpose; augmenting them adds a 5.85-point median task-success gain, at a real cost in execution steps.
The team’s wrong-tool rate flattened above zero because each model upgrade was the wrong purchase for the problem. The agent was never confused about how to reason — it was confused because two of the team’s tools, read as the bare strings the model actually sees, were not distinguishable, and a sharper mind cannot tell apart two things that are described the same way. The fix is not a smarter reader. It is a clearer page: names that state their purpose, descriptions written for the model and not the developer, near-duplicate tools merged out of existence, and a short candidate list instead of a sprawling registry. Edit the interface the model is choosing between, and the plateau the bigger model could not break moves on its own.
