A preprint posted to arXiv on September 16, "Closed-World Resolution Against Tool Hallucination in LLM Agents" (2609.19425, by Laxmipriya Ganesh Iyer), studies a failure mode every agent team eventually hits: the model calls a tool that does not exist and passes arguments no schema declares. The core argument is sharp — existing defenses (selecting the right tool, or gating what an agent may do with real tools) both presuppose that the emitted call refers to a real tool; a hallucinated call is by construction not a decision any gate made, so no gate can
[1]reject it. This is a structural blind spot.
Start with the measurement. Across ten hosted models and two invocation surfaces, the paper measures 322 genuine tool hallucinations; fabricated-tool calls concentrate on the unconstrained raw-JSON surface (34 versus 3). More critically, model scale does not help: a 675B model performs on par with 7-8B models. That directly refutes the intuition that bigger models hallucinate less — tool hallucination is not a capability problem, it is a structural property of the invocation surface.
The paper offers a five-class taxonomy of tool hallucination (H1-H5) and, as a reference implementation, the Resolution Rung: a training-free, closed-world resolver (registry membership plus a signature check). It proves that hallucination defense must precede any causal gate, and characterizes the one irreducible residue — borrowed arguments that are schema-indistinguishable from a valid call. In engineering terms: you can intercept "calling a tool that does not exist" at the registry layer, but "calling the wrong tool with valid arguments" has no clean closed-world solution.
The most aggressive part is the Model Context Protocol extension. Merging several MCP servers into one namespace creates hallucination surfaces a single registry cannot express (a second taxonomy, M1-M5): collisions and shadowing are structural to the merge, not implementation bugs. On a live MCP surface the paper measures 154 hallucinations, including from frontier models that were clean on the single-registry surface. The implication: the more the MCP ecosystem grows, the more prevalent this merge-introduced vulnerability becomes.
Limitations deserve stating. This is a measurement and benchmark study; the 322 and 154 counts depend on the test sets and surface designs; the Resolution Rung is a reference point rather than a production defense — the paper's interest is where it must sit, not what it computes; the irreducible borrowed-arguments residue means the route has an explicit ceiling. The paper releases a versioned Hallucinated-Tools Benchmark (HTB) so any resolver is comparable across submissions.
For teams building agent infrastructure, the practical value is threefold. First, stop treating tool hallucination as "the model is not smart enough" — switching to a larger model will most likely do nothing. Second, put a closed-world registry check at the tool-call entry point: low cost, certain benefit. Third, if you merge multiple MCP servers, audit it as a new security surface, not as a configuration detail.
A final observation on why this matters right now. Tool hallucination sits at the intersection of two trends: agents calling more tools across more surfaces, and protocols like MCP merging those surfaces into shared namespaces. Each trend independently raises the odds of hitting a hallucinated call; together they make the problem structural rather than incidental. The paper's contribution is measuring the problem precisely enough that defenses can finally be compared — which is what the released benchmark is for.
[1]