What I Actually Check Before I Trust an Agent's Tool Call
The hands-on companion: the specific checks I run before I let an agent's tool call through, the naming discipline that keeps a permission gate honest, and the failure I hit when I trusted a tool's name instead of its actual behavior.
What do I actually look at before approving a tool call, not just the name?
The habit that took me too long to build: I stopped trusting a tool's name as a description of its blast radius. A call named update_record and a call named delete_and_reset get reviewed identically by a permission system that only checks a declared danger tier -- so I check the tool's actual declared parameters, not just its label, before deciding whether a class of call runs freely or needs a human eyes-on step. Concretely, when I wire up a new tool for an agent, I write down what it actually does to the real system -- reads only, writes reversibly, writes irreversibly -- and set the permission tier from that answer, not from what the name implies.
How do I catch an agent calling the right tool with subtly wrong arguments?
Schema validation catches a malformed argument. It does nothing for a syntactically valid argument that points at the wrong thing -- a file path that parses fine but is the wrong file, a correctly-typed ID that's the wrong record. The check I actually run for anything expensive to get wrong: I have the agent state, in plain language, what the argument resolves to before the call executes -- "this will modify the file at this exact path, which these consumers depend on" -- and I read that statement, not just the raw argument, before it goes through. If the plain-language statement doesn't match what I expected, I stop the call there, before execution, not after.
What's the actual failure I hit from a tool I hadn't declared?
I had a capability exist on the underlying system that was never wired into the agent's declared tool menu -- a script that did exactly what I needed, sitting right there in the repo. Because it wasn't declared, the agent couldn't call it, so it improvised a longer, riskier multi-step workaround using tools that were declared, to get the same effect. Nothing about that failed loudly; the workaround technically worked. But it took a slower, less-reviewable path than the one purpose-built script would have taken, because the gate could only see what I'd told it about. The fix: whenever I add a real capability to a system an agent works in, wiring the matching tool definition is part of shipping it, not a follow-up task.
How do I keep a confirmation prompt from becoming a rubber stamp?
I stopped writing confirmation prompts that just ask "confirm this action?" Under time pressure, that trains a human (including me) to click through without reading. What I write instead states the actual consequence in plain language every time: not "confirm delete," but "this permanently removes the file at this path, which three other files reference." If I can't state the real consequence in one plain sentence, I treat that as a sign the tool's danger tier needs re-evaluating, not a sign the prompt needs better copy.
What do I check after a tool call fails, before letting the agent retry?
I read the actual error, not the agent's paraphrase of the error. An agent retrying a failed tool call will often summarize what went wrong in a way that sounds plausible and isn't quite right -- "the file didn't exist" when the real error was a permission denial. Before I let a retry proceed on riskier action, I pull the raw tool result myself once and confirm the actual failure mode matches what the agent is about to fix. It's a small extra step. It's the difference between a retry that fixes the real problem and one that patches the wrong thing based on a plausible-sounding guess.
*Read the underlying mechanism -- how a model requests an action, why the gate sits between intent and execution, and where that gate actually fails -- in the companion piece on danstolts.com: [What Is Tool Calling and How Does It Let an AI Take Real Actions?](https://danstolts.com/writing/i-am-tool-calling/)*
Frequently asked
How do I decide if an AI agent's tool call needs a human approval step or can run automatically?
Don't trust a tool's name as a description of what it can do. Write down what the tool actually does to the real system -- reads only, writes reversibly, writes irreversibly -- and set the permission tier from that answer, not from what the name implies.
How do I catch an AI agent calling the right tool with the wrong argument?
Schema validation only catches a malformed argument, not a valid one pointing at the wrong thing. Have the agent state in plain language what the argument resolves to before the call executes, and read that statement -- if it doesn't match what you expected, stop the call before execution.
What happens if a capability exists on my system but isn't declared as a tool an AI agent can call?
The agent can't call it, so it improvises a longer, riskier multi-step workaround using tools that are declared -- often silently, since the workaround technically works. Wire the matching tool definition in as part of shipping any new capability, not as a follow-up task.
How do I write a confirmation prompt an AI agent shows before a risky action, so people don't just click through it?
State the actual consequence in plain language every time, not a generic 'confirm this action?' -- for example, 'this permanently removes the file at this path, which three other files reference.' If you can't state the real consequence in one sentence, the tool's danger tier needs re-evaluating, not better prompt copy.
Should I let an AI agent retry a failed tool call based on its own summary of what went wrong?
No -- read the actual error yourself first. An agent's paraphrase of a failure can sound plausible and be wrong (for example, reporting 'the file didn't exist' when the real error was a permission denial). Pull the raw tool result once and confirm the real failure mode before letting a risky retry proceed.