Tool Selection Errors in Agents With Large Tool Sets

Tool Selection Errors in Agents With Large Tool Sets.

Scale of available tools and its effect on agent tool selection difficulty

Tool selection, not tool connection, is the operational bottleneck in agent engineering right now, and the reason is scale. Public MCP tools grew from roughly 4,900 in early 2025 to more than 177,000 by February 2026 tianpan.co AI Agents 2026: The Tool Selection Crisis.

Model providers didn't wait for engineering teams to solve this alone. OpenAI and Google enforce hard caps of 128 tools per request, and while Anthropic's API supports up to 10,000 deferred tools per request via tool search, performance degrades past 30–50 tools.

What this produces is a structural fact, not a design preference: production systems accumulate tool catalogs that outstrip what any single reasoning call can hold, which makes some selection mechanism, whether crude or sophisticated, unavoidable. The rest of this piece is about what actually breaks when that selection mechanism fails, and it turns out the answer isn't where most engineers look first.

What happens to selection accuracy as tool count grows

The RAG-MCP paper found that baseline tool selection accuracy fell to 13.62% once the tool set grew large, a collapse rather than mere underperformance tianpan.co. It's a number that shows an approach has stopped working rather than merely underperforming.

It also isn't an outlier. The WildToolBench evaluation ran 57 different LLMs and found that most couldn't clear 15% session accuracy on variable, real-world tasks openlayer.com AI Agents 2026: The Tool Selection Crisis. Two independent measurements landing in the same range say something about the shape of the underlying problem beyond one benchmark's quirks.

In practice, teams that pay attention to this treat roughly 10 to 20 tools per reasoning context as the safe zone tianpan.co AI Agents 2026: The Tool Selection Crisis. The trouble is that the cliff edge doesn't announce itself. Agents don't throw an exception when they grab the wrong tool. They return a plausible-looking result from the wrong operation entirely, and that result often passes whatever surface-level quality check sits downstream. The failure hides until someone notices the output doesn't match reality.

Token overhead adds a second layer of cost on top of the accuracy shortfall. Some production benchmarks report more than 130,000 tokens consumed on tool definitions alone tianpan.co AI Agents 2026: The Tool Selection Crisis. So the model pays a real cost in context space just to hold the option set in view, before it does any reasoning about which option is correct. Given that combination, the obvious next question is whether these are visibility failures or reasoning failures.

The failure taxonomy: what breaks and at which layer

ToolScan, presented at an ICLR 2025 workshop, catalogs seven recurring error types in tool-calling agents: insufficient API calls, incorrect argument values, incorrect argument names, incorrect argument types, repeated or redundant API calls, incorrect (hallucinated) function names, and invalid output formatting. The grouping matters because it gives engineers a way to attribute a given failure to a layer, rather than lumping every bad tool call into one undifferentiated bucket labeled "the model messed up."

A synthesis out of Oxford, drawing on 27 benchmark and audit papers spanning 19 distinct benchmarks, arrived at six failure clusters, with tool invocation and parameter-level errors sitting first Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents. It also found that failure compounds non-linearly as tasks get longer: a small selection error early in a trajectory doesn't just cost one step, it multiplies Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents.

One class deserves its own name: functional hallucination, where an action is structurally plausible (correct schema, correct argument types, correct call shape) but semantically wrong, distinct from the kind of textual confabulation people usually mean when they say a model "hallucinated" tianpan.co. This is what makes tool misselection so hard to catch downstream. The call looks right. It just does the wrong thing.

Confusable tools make this worse. Compound this with workflow loops, where an agent calls the same tool with the same arguments repeatedly and burns tokens and latency without resolving anything. One documented case involved a logistics company's agent spending 23 minutes re-verifying a customer's identity across three separate systems, spawning recursive sub-tasks the entire time, never throwing an error, just never actually finishing. It didn't fail loudly. It got lost quietly, which is worse.

Depending on model size and task complexity, tool calling fails somewhere between 3% and 15% of the time in production, and some full agent workflows fail closer to 41% of the time openlayer.com AI Agents 2026: The Tool Selection Crisis. Those numbers should stop anyone from treating tool selection as a minor implementation detail. The Parallel REST API taxonomy (arXiv:2504.15546, 2025) groups these into tool invocation errors, input specification errors, execution errors, and output-interpretation errors, a framing useful for attribution tianpan.co TU Munich survey. Selection confusion can arise from confusable tools such as "notify-user" versus "notify-channel," both of which look plausible, and Anthropic explicitly flags this failure mode for multitool stacks.

The obvious explanation, the model didn't see the right tool, is mostly wrong

The instinct, when an agent grabs the wrong tool out of a crowded set, is to assume the model simply failed to notice the right one. Too many options, too little attention to go around, so the correct tool got buried and the model reached for whatever it could actually see. It's a reasonable guess. It's also mostly wrong.

A paper released in June 2026, "Looking Is Not Picking," tested this directly against 198 real failures pulled from the Berkeley Function-Calling Leaderboard. The researchers measured where the model's attention actually landed, and found that the model attended most heavily to the correct tool 80% of the time, well above the 21% chance baseline you'd expect if attention were scattered randomly across the option set Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents. More telling still: the gold, correct tool was the under-attended segment in only 10% of the failures examined Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents tianpan.co. In other words, the model was looking right at the correct tool in the overwhelming majority of cases where it still picked wrong.

That's a genuine dissociation between looking and picking, and the paper backs it with three separate lines of evidence. Prompt repairs on the input side, reordering the tool list or duplicating the gold tool so it's harder to miss, recovered at most 23% of failures Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents openlayer.com. Interventions on the readout side, changing how the model converts its internal state into a final selection, recovered between 59% and 91% of failures Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents. An attention-logit bias and a completely separate residual steering vector recovered largely the same set of failures, with a per-task Jaccard overlap of 0.87, which pins the bottleneck to the decision readout regardless of which internal representation you intervene on Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents.

A companion body of work established that the correct tool is linearly readable inside the model's internal representations well before the final output: the information needed to pick correctly is present and available. It's the conversion from that internal knowledge into an actual selection that breaks. A concurrent paper offering similar corroboration has since been withdrawn by its own authors, leaving the attention-segment account from Chen et al. as the standing explanation tianpan.co. Separate work on the knowing-doing gap backs this up from another angle: models can correctly identify that a tool is needed and still fail to invoke it properly, even in the absence of any explicit reasoning step that might have introduced the error tianpan.co. And the Berkeley leaderboard itself shows single-turn function selection holding up reasonably well, while performance falls apart across multi-turn state maintenance and long call sequences, exactly where readout errors have more opportunities to compound tianpan.co.

The implication for engineering teams is blunt: swapping in a better base model does not fix a readout bottleneck. If the model already sees the right tool most of the time and still picks wrong, a marginally smarter model looking at the same crowded tool list will likely make the same mistake, just with more confidence. The fix has to target how the harness structures and narrows what gets surfaced before the model ever has to make that readout decision.

The four harness-layer failure patterns that drive tool misselection

Schema drift is the first, and it looks like a routine version bump until it isn't. OpenAI rejected the malformed calls with an error about the schema needing to be of type object, Anthropic rejected them with a "field required" error, and enterprise workflows simply stopped running. Rollback was the only fix available. No conventional API test caught this ahead of time, because the schema output changed silently as a side effect of an unrelated upgrade. Any change to a tool's name, description, or schema is a potential breaking change, and the blast radius of that change is rarely obvious in advance.

Prompt ambiguity is the second pattern. Overlapping tool names and descriptions create ambiguity that the model resolves poorly once the option count climbs; Anthropic recommends adversarial routing tests, deliberately confusing prompts designed to surface these collisions before a customer does.

Error signal quality is the third. When a tool returns a vague or inconsistent error message, the agent doesn't know how to correct course, so it retries the same call, picks a wrong fallback tool, or fabricates an answer to move past the block. Anthropic's own guidance frames tool error responses as a steering mechanism: a poor error steers the model poorly, on purpose or not.

The fourth pattern is closer to a design failure than a technical bug: cognitive overload from flat tool presentation. When tools with similar descriptions sit side by side in an unstructured list, they blur together inside the attention mechanism, and semantic distinctions that felt obvious to whoever wrote the tool descriptions get lost. Schema noise then occupies working context that should be devoted to understanding what the user actually wants. Patterns two and four together are a large part of what produces functional hallucination at scale, where the model invokes a tool that doesn't exist or stitches together parameters from two different schemas into something that looks like a valid call but isn't one.

In multi-agent systems, a single bad tool call becomes a foundation problem. A flawed result passed downstream as fact gets treated as ground truth by every subsequent agent in the chain. Three specialized subagents can each receive the same hallucinated tool output and produce three separate, internally coherent, entirely wrong answers, with no exception raised anywhere along the way. A survey out of TU Munich, covering 55 papers, makes the diagnostic challenge explicit: agent failures live inside long, language-heavy execution trajectories that obscure their own root causes, which makes repair genuinely difficult, not just tedious tianpan.co TU Munich survey.

Harness engineering's structural approach to tool selection

That's a fuller job description than most people assign to "the harness" when they use the word casually. It's the entire operational envelope the model runs inside, before, during, and after any given reasoning step, and the right question to ask of it is what system needs to exist so the model doesn't fail the same way twice.

Frontier models are powerful, but they're also inconsistent, and production outcomes depend on turning occasional good performance into repeatable, controlled action rather than switching to a slightly better base model tianpan.co. The SIA paper backs this with a concrete result: across three separate cases, combining harness updates (new tools, tighter parsers, better retry policies, restructured prompts) with model weight updates outperformed harness iteration alone, and the gains came from both, not from the scaffold in isolation Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents. A related paper, "Better Harnesses, Smaller Models," goes further and argues harness improvements can substitute for a larger, more expensive model outright tianpan.co.

The FAMA framework, published in April 2026, operationalizes this idea in two stages: analyze failure trajectories from a baseline agent to find its most common errors, then dynamically activate a minimal subset of specialized agents to inject targeted context before the decision-making step actually happens FAMA: Failure-Aware Meta-Agentic Framework for Open-Source LLMs in Interactive Tool Use Environments Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents tianpan.co. Across open-source LLMs, this produced performance gains of up to 27% over standard baselines FAMA: Failure-Aware Meta-Agentic Framework for Open-Source LLMs in Interactive Tool Use Environments Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents tianpan.co. The mental model beneath all of this is straightforward: treating the base model as a stochastic planner and actor produces the need for the harness to act as the deterministic executive layer responsible for absorbing the variance the model itself can't control. A separate 2026 paper, "Adapting the Interface, Not the Model," makes the same point from a different angle, showing that runtime interface changes alone can eliminate entire classes of failure without anyone touching the model's weights tianpan.co. Lilian Weng, in "Harness Engineering for Self-Improvement," defines the harness concretely as the runtime environment managing execution, state, security, and lifecycle, encompassing sandboxed execution, state and memory management, tool execution and control, context engineering, and feedback loops tianpan.co.

Tool filtering and routing: reducing what the model sees before it reasons

The core move is decoupling how many tools a system supports from how many tools any single call actually sees. A catalog can hold thousands of tools; a given reasoning step should only ever be shown a small, relevant slice of it.

RAG-MCP is the clearest demonstration of what this buys. Retrieval-based tool selection raised accuracy from 13.62% to 43.13%, more than tripling it, while cutting prompt tokens by more than half on the same benchmark tasks tianpan.co openlayer.com. Nothing about the tools changed and nothing about the model changed. Only the visible subset changed tianpan.co openlayer.com.

Three implementation patterns appear repeatedly in practice. Semantic retrieval embeds tool descriptions in an external index and pulls the top matches for each incoming request, which is the mechanism behind RAG-MCP itself. Rule-based routing assigns tool subsets by explicit logic tied to domain, user role, or request type, trading some flexibility for predictability and easier auditing. LLM-based routing puts a lightweight, fast model in front of the main reasoning model, classifying the request and routing it to the right tool domain before the heavier model ever runs, so the router itself only ever sees a small context.

None of this works if the tools themselves are unreliable at a structural level; the five-part reliability contract addresses this: a tool should be discoverable, schema-backed, bounded, observable, and governable tianpan.co. Fail any one of those and the tool becomes a loosely documented capability, which produces silent failures downstream tianpan.co. The hierarchical tool architecture framework pushes this a step further, encapsulating frequently co-used tools into specialist agents, each holding a tightly focused set, with an orchestrator routing to specialists instead of exposing one flat list to everything. That structure addresses a problem routing alone can't solve once a system keeps scaling tianpan.co.

Bounded execution deserves its own mention as a guard specifically against the workflow-loop failure described earlier. Every execution path needs a real ceiling, made up of a step limit, a token budget, and a wall-clock timeout. Without one, a single ambiguous task can consume unbounded compute, and the failure mode isn't a crash, it's an agent that never stops working and never gets anywhere.

That's a meaningful reliability gain purchased for a small compute tax, and it targets the readout bottleneck directly rather than working around it. The training-free selector from Chen et al. (2026) uses per-segment attention to lift function-selection accuracy by +11.9 points on BFCL and +14.9 on Seal-Tools, with every model positive, at approximately 1.2× decoding cost, a harness-level intervention requiring no retraining Looking Is Not Picking: An Attention-Segment Account of Tool-Selection Failures in LLM Agents tianpan.co.

How teams diagnose tool selection failures from production traces

Output-level evaluation tells you whether a call succeeded or failed. It does not tell you how the model's internal attention over the available tools related to the choice it made. Success rate alone can't locate a root cause, only confirm that one exists somewhere upstream tianpan.co. The TU Munich survey puts the diagnostic challenge in plain terms: traditional software defects live at the code level, where a stack trace points you to a line number, but agent failures live at the reasoning level, embedded in long, language-heavy trajectories that don't offer anything as clean as a stack trace. The diagnostic method has to match that difference, or it will keep missing the actual point of failure.

Root cause attribution, in this framing, means finding the decisive error: the earliest mistake in a trajectory whose correction could have reversed the eventual outcome, a concept formalized in the Who&When work presented at ICML 2025 tianpan.co. That's a meaningfully different target than "the step where things visibly went wrong," because by the time a failure is visible, several compounding errors may already have occurred. A follow-up effort, Who&When Pro, expanded this evaluation base to more than 12,000 labeled trajectories spanning multiple agent frameworks, domains, and modalities, giving teams a far larger reference set for locating where trajectories actually go off course.

Put together, the diagnostic posture that emerges from this body of work is consistent: treat tool misselection as a readout and harness problem first, verify against attention and trajectory evidence rather than surface outcomes alone, and reserve model swaps for the cases where the evidence actually points there. Given how rarely it does, that's a narrower set of cases than most teams currently assume.