What I Actually Check Before I Trust an Agent's Tool Call

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/)*