Tool Call
The model asking for a specific function with specific arguments.
A structured output in which the model names a tool and supplies arguments, typically as JSON. The harness executes it and returns the result.
Tool descriptions are prompts. Name, description and parameter schema are all the model has to decide when and how to call it — vague descriptions are the most common cause of a tool being used wrongly.
The key property is that the model does not execute anything. It emits a structured request, and your code decides whether to honour it. That is the whole reason permissions, approvals and sandboxing are possible at all — the seam between intent and execution is where you put every control.
Intercepting the destructive call
An agent decides a clean reinstall is the fastest way to fix a dependency problem.
The tool call is a proposal. A permission rule that matches the command and requires human approval turns a one-way door into a two-way conversation, and costs nothing in the ninety-nine percent of calls that are routine.
- docsFunction calling ↗
The application-managed tool cycle spelled out: define the function with a JSON Schema, receive the call, execute it yourself, return the output.
- docsTool use with Claude ↗
The tool_use / tool_result round trip, client-executed versus server-executed tools, tool choice and parallel calls.
- docsFunction calling ↗
The model selects a declared function and supplies arguments. Useful as a cross-vendor reference showing the pattern is not one provider’s design.
Tool
A function the model is allowed to call to affect the world.
Tool Result
What came back from the call, appended to context.
Function Calling · Tool use
The model-provider feature that makes structured tool calls reliable.
Structured Output · JSON mode
Making the model return data your code can parse.