Tool Use
Tool use is the pattern where the model expresses an intention to call an external function or API, and the application runtime executes that call on the model's behalf. The model decides what needs to be queried or executed. The runtime keeps control over side effects.
βΆArchitecture Diagram
π ProcessDashed line animations indicate the flow direction of data or requests
A model does not know live internal state unless the system fetches it, and it cannot safely perform actions like ticket creation or payments by itself. If those limits are ignored, the model either invents answers or stops at vague instructions instead of completing real work.
As LLMs moved from text generation to product workflows, connecting them to search and action systems became essential. The important design shift was not making the model omnipotent. It was allowing the model to request tools while keeping runtime authority and verification outside the model.
The application defines tool schemas with names, descriptions, parameters, and allowed behaviors. The model sees those schemas and emits a tool call when it decides one is needed. Runtime code validates the arguments, performs the actual operation, and returns the result as an observation, a summary of what happened, that the model can use in the next step.
The model sees a tool contract
{
"name": "get_order_status",
"description": "Fetch the current order status",
"input_schema": {
"type": "object",
"properties": {
"order_id": { "type": "string" }
},
"required": ["order_id"]
}
}The model is not given direct database access. It is given a named tool with an explicit argument contract.
Separate intent from execution
{
"tool_call": {
"name": "get_order_status",
"arguments": { "order_id": "A123" }
},
"tool_result": {
"order_id": "A123",
"status": "shipped"
}
}The model emits the call intent, the runtime performs the action, and only the result is fed back. That separation is the core of tool use.
Structured output, tool use, and agent workflow all connect model output to system behavior, but they operate at different layers. If you only need a validated object, structured output is enough. If you need one external lookup or action, use tool use. If the next action depends on the previous observation, move up to agent workflow. Not every tool call needs to become an agent loop.
Teams use this for search, database access, CRM updates, scheduling, calculation, and policy checks. The common operational failure is letting models call broad write tools too freely or repeat the same action. That is why read and write tools are often separated, and write actions are guarded with confirmation or idempotency controls that prevent the same request from causing duplicate side effects.