Name the tool the model called

The model was supposed to do something, not only say something. Do not treat the action as done, and do not let another one start, until you can name the tool, show the arguments that were sent, and show whether the tool ran and what it returned — or until you write that you cannot see the call. Do not ask the model which tool it used. The model is the party that chose. Its recollection is not the log. If the log does not exist, the honest sentence is that you cannot see the call. A fluent paragraph that names a function is not that sentence.

This is the call record. It is not the hour after a wrong row is already in the system of record. When the agent already wrote the row starts from a write you can point at, and it tells you to keep the tool and the arguments while you reverse the row. If you cannot name the tool because the call was never recorded, you are not in that reversal yet. You are here. It is not a user sentence that told the model to ignore the instruction. When the user rewrote the rule is that override. An override can be the reason a tool ran. It is not a substitute for the name of the tool. It is not an error treated as a yes. When the guard fails open is the branch where a timeout becomes permission. A guard that failed open may have let a tool run. The permission and the call are different lines in the log. It is not the same action landing twice. Stop the retry that landed twice is the duplicate. A duplicate still has a tool name, twice. And it is not a role on a human account, or a ref in a workflow file. Name the role that account holds is the person's binding. Name the action the workflow runs is a uses line. A tool the model calls is neither.

None of what follows is a finding that your agent called the wrong function, and none of it is legal advice. A benchmark accuracy is not the share of your customers' calls that were right. A vulnerability description is not a log. If you cannot see the call, say so, and stop the next one that would change a record.

The vulnerability is three causes, and a wrong sentence is not automatically all three. OWASP's Top 10 for LLM Applications, version 2025, LLM06, Excessive Agency, is the entry for a system "granted a degree of agency" — the ability to call functions or to interface with other systems "via extensions (sometimes referred to as tools, skills or plugins by different vendors)." The decision of which extension to invoke "may also be delegated to an LLM agent." Excessive agency is "damaging actions" performed "in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." The triggers they name are hallucination from a benign prompt or a weak model, and direct or indirect prompt injection, including from a previous tool or from another agent. A trigger is not a root cause. The root cause "is typically one or more of" excessive functionality, excessive permissions, and excessive autonomy. Three causes. "One or more" means a system can have one. Do not require all three before you stop a call. The entry says this differs from insecure output handling, "which is concerned with insufficient scrutiny of LLM outputs." A sentence you should have checked is not the same defect as a tool you should not have offered. Functionality, in their examples, is a plugin that can delete when you needed read, a plugin you meant to retire and left connected, or a shell that was supposed to run one command and does not filter the others. Permissions are a database login that can update when it only needed select, or a shared privileged identity used for a single user's files. Autonomy is a delete that does not ask a person. Prevention that belongs on this page: offer only the extensions the system needs, cut the functions inside an extension, avoid an open-ended shell or URL fetch when a single-purpose tool will do, run the call with the user's own authorization and the minimum scope, and require a person to approve a high-impact action. Complete mediation is the line that matches this article's refusal to ask the model: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." Logging and rate limits, the entry says, "will not prevent" excessive agency. They limit the damage. A log you can read is the proof on this page. It is not, by their sentence, the prevention. Their mailbox scenario is shape, not a study of your product: a plugin that can send as well as read, an indirect injection in an incoming mail, and three ways out — a read-only extension, an OAuth scope that is read-only, or a person who hits send. Read-only OAuth is not a log, and a person who hits send is not a benchmark score (OWASP, Top 10 for LLM Applications v2025, LLM06:2025 Excessive Agency).

The benchmark that measured whether a call was the right call is a different object from that list, and its numbers do not travel one into another. Li, Zhao, Yu, Song, Li, Yu, Li, Huang, and Li, API-Bank, EMNLP 2023, pages 3102–3116, 6–10 December 2023. Alibaba, the Hong Kong University of Science and Technology, Peking University, and Shenzhen Intelligent Strong Technology. The evaluation system implements 73 APIs. They annotated 400 dialogues, discarded 21.5%, and retained 314 dialogues with 753 API calls. 21.5% is the discard rate of the 400. It is not a call accuracy, and 314 is not 753. Each evaluation instance was reviewed by four annotators. The manual annotation cost they print is $8 a dialogue. $8 is a cost. It is not a score. The training set is separate: 1,888 dialogues, 2,138 APIs, 1,000 domains, 4,149 API calls, generated by their multi-agent method rather than written by those annotators. 1,888 is not 314. 2,138 is not 73. 4,149 is not 753. 1,000 is not the evaluation set. The statistics sentence for the whole benchmark prints 1,008 domains, 2,211 APIs, 2,202 dialogues, and 6,135 turns. 1,008 is not 1,000. 2,211 is not 2,138. 2,202 is not 1,888. The table's two columns are the training figures and an evaluation column of 8 domains, 73 APIs, and 314 dialogues. 8 is not 73 is not 314. A reader who adds the two columns gets 1,008, 2,211, and 2,202, the statistics sentence's three totals. The addition holds. It does not make 1,000 into 1,008, and it does not make the training set into the test. Ability counts across the benchmark: 934 Call, 769 Retrieve+Call, 499 Plan+Retrieve+Call. Those three add to 2,202, the benchmark-wide dialogue count. They do not add to 314, and they are not the 753 calls. Training dialogues average 2.76 turns and test dialogues 2.91. 2.76 is not 2.91, and neither is a correctness. They interviewed 500 users before defining the abilities. 500 is not 314 and not 400 (Li and colleagues, API-Bank).

A correctness cell is not the cell next to it, and a prose gloss is not the cell. Accuracy is correct predictions divided by predictions. A call is correct when it performs the same database query or modification as the annotation and returns the same result. ROUGE-L is the other column. It scores the words of the reply, not the call. Table 3, zero-shot unless noted. Alpaca-7B: Call 24.06% (ROUGE 0.0204), Retrieve+Call 5.19% (0.0019), Plan+Retrieve+Call 0.00% (0.086), total 15.19% (0.0318). ChatGLM-6B: 23.62% (0.2451), 13.33% (0.2173), 0.00% (0.1522), total 16.42% (0.2191). GPT-3 Davinci: 0.50% (0.1035), 1.48% (0.091), 0.00% (0.0156), total 0.57% (0.0814). GPT-3.5-turbo, checkpoint gpt-3.5-turbo-0613: 59.40% (0.4598), 38.52% (0.3758), 22.00% (0.3809), total 47.16% (0.4267). GPT-4, checkpoint gpt-4-0613: 63.66% (0.3691), 37.04% (0.351), 70.00% (0.4808), total 60.24% (0.3910). Lynx-7B, the fine-tune: 49.87% (0.4332), 30.37% (0.2503), 20.00% (0.3425), total 39.58% (0.3794). 59.40 is not 0.4598. 47.16 is not 59.40. 60.24 is not 63.66. 0.00 on three Plan cells is not 22.00 and not 70.00. The two 0.00 Plan cells for Alpaca and ChatGLM are not the same model. The prose says both the 7B and the 6B "achieve about 20% accuracy in API call." About 20 is their phrase. The cells are 24.06 and 23.62. Do not replace either cell with 20, and do not treat the two cells as one. They say GPT-3.5 surpasses Alpaca "by 35 points" on call correctness and by 0.44 on ROUGE. 35 and 0.44 are their phrases, not cells. They say GPT-3.5 "decreases by 21%" from Call to Retrieve+Call, and "a further 17%" into Plan. 21 and 17 are those sentences. They are not 59.40, 38.52, or 22.00, and a percent in that sentence is not an invitation to recompute the cells. GPT-4 "shows a 4 points improvement" on calls against GPT-3.5, is "similar" on Retrieve+Call, and "achieves a nearly 50% improvement" on Plan. 4 points is not 63.66, similar is not a printed equality of 37.04 and 38.52, and nearly 50% is their phrase for the Plan comparison, not 70.00 itself. The prose also says performance "gradually decreases" as the ability gets harder. GPT-3.5's three cells do go 59.40, 38.52, 22.00. GPT-4's Plan cell is 70.00, which is higher than its Call cell of 63.66. The gradual-decrease sentence is not that pair. Do not cite the sentence and the pair as if they agreed. Lynx "outperforms Alpaca-7B by 26 points" on call correctness and 0.41 on ROUGE. 26 and 0.41 are their phrases. 49.87 is not 24.06. They say GPT-3.5 reaches 80% to 90% API accuracy on APIBench and on ToolAlpaca. That range is those other sets. It is not 59.40, and it is not 63.66.

The error tables are shares of errors, not shares of calls, and they are not one table. Alpaca, Table 4: No API Call 36.77%, API Hallucination 15.93%, Invalid Input Parameters 7.96%, False API Call Format 23.65%, Miss Input Parameters 1.17%. Those five do not add to 100. The prose says problematic input parameters — an exception, an invalid value, a call that does not parse — "collectively contribute to 32% of the overall errors." 32 is that sentence. It is not 7.96 and it is not 1.17. Do not add cells until they look like 32. Lynx, Table 5: API Hallucination 61.38%, Has Exception 16.40%, Invalid Input Parameters 8.47%, False API Call Format 6.88%, No API Call 5.29%, Miss Input Parameters 1.59%. 61.38 is not Alpaca's 15.93. 5.29 is not 36.77. A reduction they describe is not a disappearance. GPT-4, Table 6: Failed API Retrieval 67.86%, False API Call Format 17.86%, Invalid Input Parameters 7.14%, Miss Input Parameters 7.14%. The two 7.14 figures are different error types. The prose says inability to use API search "accounts for 68% of the overall problems." 68 is their phrase. 67.86 is the cell. Do not replace one with the other. Failed retrieval is "which API," not "what arguments." A wrong argument and a missing tool are both on this page, and they are not the same row. Alpaca's instruction data is described as 52K in one section and 52,000 in another. Those two phrases are Alpaca's training set, not API-Bank's 1,888 dialogues. Lynx's fine-tune is three epochs, batch size 256, learning rate 2e-5. 256 is a batch size. It is not 314 dialogues and not a correctness. On training-data quality they drew 100 samples, found a 94% available rate, an 89% improvement over single-agent generation, and that 78% of what the tester filtered "does not adhere" to their principles. Single-agent generation itself was 5% available with ChatGPT and 25% with GPT-4. 94 is not 89 is not 78 is not 5 is not 25. 100 samples is not 1,888 dialogues. None of these percentages is the share of your production calls that named the right tool.

Read a call against that discipline without importing the table. The record you need is the tool name as the product registered it, the arguments as they were sent, and the result or the error the tool returned. A sentence in the chat that says "I looked up order 14" is the model's claim. The log either contains a call named for that lookup, with those arguments, or it does not. If the arguments are empty, or are a different customer's identifier, write that down. Empty is not success. The wrong identifier is not a retrieval score from a paper. If two tools could have answered and the log shows one, name that one. Do not ask the model whether it would have picked the other. OWASP's complete-mediation line is the authorization check in the system the tool calls, not a second prompt that says "did you behave." Their note that logging does not prevent the vulnerability is why the log is the proof and not the fix. You still write the log down before you change the tool list. A team that waits for a perfect schema before it records the call will spend the night with no record.

What a call you can name looks like, when a product already has more than one action, is ordinary. An AI support agent for a DTC ecommerce brand looks up an order, starts a return, or changes an address, and those actions sit behind permission guardrails, with a person receiving the conversation when confidence is low. Nothing in that description is a headcount, a duration, or a result figure. The shape is the point: three actions have names, so a log can say which of the three ran, with which arguments, and a person can still refuse the one that changes a record. That case is not a tool-call study, and it is not a score on a benchmark. A product whose only action is "the model replies" has nothing to name. A product whose only action is a shell has a name that is too wide, which is the open-ended extension the OWASP entry tells you not to offer. Neither is fixed by asking the model what it meant.

There is a version of this night where hiring a production engagement is the wrong purchase. Nothing is in production. The model wrote a draft and called no tool, because no tool exists. A missing log of a call that cannot happen is theatre. The user sent two questions, not a second instruction and not a function. A customer has already seen another customer's data. The first hour is the tenant boundary, not a tool name. The wrong value is already a write in the system of record, and you can point at the row. That is the reversal article, and staying here to debate the schema will not put the row back. Or no metric was ever named, so you cannot say what the tool was supposed to move, and a stricter log will not invent the metric.

Where a tool is already live and the call is the thing you cannot see, the work is the record, the stop on the next unlogged action, and only then the evaluation of whether the calls you can see are the right ones. That sequence is what an AI pilot failed to reach production engagement owes you when the pilot's agency was a prompt: an audit in weeks one and two, then a path that cannot act without a call you can name, measured against a number you agreed, inside an engagement that runs eight to twelve weeks and is scoped after the audit. If the agreed metric does not move, you do not pay for the build. Rollout, when it happens, sits behind a human-review gate. The findings of a two-week AI readiness assessment are yours whether or not that build happens. AI evaluation and observability is how you learn, afterwards, whether the calls you recorded were the right calls — the question API-Bank measured, which you do not answer by asking the model.

On the night the answer says an action happened, open the log before you open the prompt. Name the tool. Name the arguments. Say whether it ran, or say you cannot see the call. Do not ask the model to confess a function name. A tool you cannot name is not a tool you control. It is a rumor, and a rumor is what the customer has already been given. The payload that call returned, as opposed to the tool name, is which tool result did the model see?. A name is not the block.