An agent has been given exactly one tool, `send_email`, whose schema requires a `to` field (a string) and a `subject` field (a string). During a run, the model's output requests a tool named `send_email_and_delete_drafts` with an argument object containing only `recipient`. Neither the tool name nor the argument name matches anything the calling application defined. What should the calling application do?
- Execute the request against the closest matching real tool it can guess, since refusing to act on an almost-matching request would make the agent unusably rigid
- Treat the mismatch as a formatting preference and silently rename the fields to match the defined schema before running the real `send_email` tool
- Assume the user must have wanted drafts deleted as well, and extend the real `send_email` tool's behavior at runtime to also delete drafts
- Reject the request without executing anything, since it does not match any tool name or argument schema the application actually defined, and return an error observation to the model so it can retry with a request that matches an available tool
Why D? And why not the others?
Correct answer: D. Reject the request without executing anything, since it does not match any tool name or argument schema the application actually defined, and return an error observation to the model so it can retry with a request that matches an available tool
Because a model's tool-use request is generated text and not a guaranteed-correct reference to what was actually defined, it can name a tool that does not exist or supply arguments that do not match the declared schema -- this is a real failure mode, which is exactly why some tool-use implementations offer a strict mode specifically to make requests conform to the declared schema, implying that conformance is not otherwise guaranteed. The safe response to an unrecognized tool name or a schema mismatch is for the calling application to refuse to execute anything against real systems and instead return an error back to the model as an observation, letting the model correct itself and retry with a valid request. The option of executing against the closest-matching real tool is wrong because guessing at a destructive or unintended action (here, one that also deletes drafts) from a malformed request is far riskier than simply refusing and asking the model to retry. The option of silently renaming fields to match the schema is wrong for the same reason -- silently reinterpreting a request assumes an intent that was never actually validated. The option of extending the real tool's behavior at runtime to match the hallucinated request is wrong because it lets an unverified, possibly hallucinated capability (deleting drafts) actually happen, which is the opposite of containing the mismatch safely.
Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview) -- 'Handle tool calls' entry: 'Parse tool_use blocks, format tool_result responses, and handle errors'; and 'Strict tool use' feature description noting schema conformance is not otherwise guaranteed