On this page
Read
The useful mental model
Tool calling is a contract. You describe each tool with a name, a description, and an input schema. The model decides when a tool fits and returns a call. Your code, never the model, performs the action and returns a result, and the model continues from it. The model acts less like a text generator and more like a caller of typed functions.
In plain English
The model cannot press buttons. It fills in a form that says run this, with these values, hands it to your code, and waits for the answer.
Where builders use it
- 01Looking up fresh or private data
- 02Taking actions such as sending an email or updating a record
- 03Returning output in a guaranteed shape
Why it matters
Tool calling is the bridge between a language model and your systems. It is also where side effects happen, so validation, permissions, and retries are decided in your code, not by the model.
Why now
Tool calling is available across major model providers and sits under agents and shared tool protocols. Details differ by provider and change often, so check the current documentation before relying on a specific behavior.
A common misconception
“The model runs the tool.”
The model only emits a structured request. Your application, or the provider's servers for hosted tools, executes it and returns the result.
“A strict schema makes a tool call safe.”
A strict schema makes the arguments match the expected shape. Whether the action is allowed, valid, and safe to repeat is decided by your own code.
See
See the mental model
The visual is generated from the same structured knowledge as the written explanation.
A five-step sequence: define the tools, the model requests a call, your application checks and runs it, the result goes back to the model, and the model answers or asks for another tool.
Builder example
Let the model request an action without letting it act
An assistant should issue refunds when a customer's request meets the policy.
Failure
The model replies that the refund is on its way when nothing has happened, or a retried tool call issues the refund twice.
Intervention
Define a refund tool with a schema and let the model request it. The application checks permission and policy, runs the refund with an idempotency key, and returns the real result to the model.
Observable result
The reply states only what the system confirmed, and a retried call resolves to a single refund.
Sources
Go deeper
Last researched 12 October 2026