When an AI client is about to call a tool, it has a decision to make: run it, or stop and ask the human first. Getting this right is what separates an assistant that feels fluid from one that nags — and it depends entirely on the tool declaring what it does.
The declarations that matter
Four hints do most of the work. Whether the tool only reads. Whether it can destroy something. Whether calling it twice has the same effect as calling it once. And whether it touches systems beyond the server.
A tool that reads a gamma profile is read-only, non-destructive, idempotent and closed. A client can call that freely. A tool that creates a standing alert is none of the first three, and a client should confirm.
Why the mislabel is dangerous
An honestly labelled dangerous tool gets a confirmation prompt. A dangerous tool mislabelled as safe gets executed silently, and the user finds out afterwards.
This is not theoretical. When we added our first tools that create and cancel things, the annotations were being generated for the whole set rather than per tool, and both write tools inherited the read-only flag. Every test passed, because the tools worked. What was wrong was the promise attached to them, and no functional test can catch a false promise.
What to look for in a vendor
Ask whether their tools carry annotations, and then check a write tool. If everything in the catalogue claims to be read-only and some of it plainly is not, the annotations are decorative, and your client is making safety decisions on bad information.
The corollary: a data vendor whose tools are genuinely all read-only has an easy job here, and should still say so explicitly rather than leaving it implied.