Tool use, often called function calling, is the mechanism by which a language model invokes an external function instead of only producing text. The model emits a structured request — a tool name and a set of arguments — which the surrounding system executes, returning the result for the model to read and act on.
Why tool use matters
A model on its own can only generate text from its training data. It cannot look up a live order status, query a database, run a calculation precisely, or send an email. Tool use is what closes that gap: it gives the model a controlled way to reach systems and data outside its own weights, turning a text generator into something that can observe and affect the world.
This is the capability that makes an agent more than a chatbot. Without tools, a model can describe how to do a task; with tools, it can actually do it. That power also introduces risk, because the model is now triggering real actions, which is why tool definitions, argument validation, and approval checks become part of running tools safely in production.
How it works
Tool use follows a consistent request-and-response cycle:
- Each tool is registered with the model as a schema — a name, a natural-language description, and a typed parameter definition, commonly JSON Schema.
- Given the goal and the conversation so far, the model decides whether to call a tool and, if so, emits the tool name and a structured set of arguments.
- The runtime — not the model — executes the function with those arguments.
- The function’s return value is appended to the context as a tool result, and the model reasons over it to choose its next step or produce a final answer.
The model never runs code itself; it only proposes calls. The execution layer is responsible for actually invoking the function, enforcing timeouts, and recording the result, which is what keeps the behavior inspectable and controllable.
Tool use vs. plain text generation
Plain text generation maps a prompt to a completion in a single pass. Tool use inserts a structured detour: the model pauses generation, requests an action, waits for a real result, and then continues with that result in context. The difference is not just format — it is that the model’s output becomes grounded in something that happened outside the model, rather than being a prediction from training data alone.
In practice
A durable runtime treats every tool call as a recorded step: the arguments the model produced, the result returned, and how long it took are all persisted, so a tool invocation survives a crash and can be replayed or audited later. Tools can be plain functions, hosted API endpoints, or remote servers reached through the Model Context Protocol, and high-risk calls can be wrapped in guardrails or an approval check. This cycle of calling a tool and reasoning over the result is the heartbeat of the reasoning loop that drives an AI agent. For the API surface, see defining tools.