What a tool call really is

The model never runs your code. It writes a request, and your program decides whether to honour it.

Part of the Agents track on lAItest.

The model never runs your code. It writes an order slip and waits at the counter.

A tool is three things

A name, a description written for the model to read, and a schema saying which arguments are valid. That is the whole interface. The model cannot see the source code or the database behind the tool, only the description — which is why a vague description reliably produces a badly-called tool.

Who does what

The model emits a structured call: tool name plus arguments. Your program receives it, validates it, runs the real function, and appends the result to the transcript as a tool result. Then the model runs again with that result visible. Every one of those steps is your program acting, including the step where it refuses.

A common misconception

Commonly believed: Getting valid arguments out of a model means asking politely for JSON and retrying until something parses.

Actually: On models that support it, the arguments are constrained while they are generated: a compiled grammar limits which tokens are even possible, enforced at the token level rather than checked afterwards. Anthropic caches those grammar artefacts for 24 hours. Where that is available, retry-until-it-parses is obsolete.

A tool call arrives with arguments that would drop a production table. Who decides whether it runs?

Answer: Your program, which receives the call and chooses whether to execute it. A tool call is a request made of text. Execution happens in your code, which is where validation, permission checks and human approval belong. A schema constrains the shape of the arguments, never the intent behind them.

In one sentence

A tool call is a message asking your program to do something, and your program is still the thing that does it.