TL;DR: Tool use lets a language model do things instead of just describing them. You tell the model what functions exist; when one would help, the model replies with the function's name and arguments as structured data. Your code runs the function and returns the result, and the model continues with real information it could not have generated itself.
How it works
The mechanism is a contract between your code and the model. With each request you send a list of tool definitions - each one a name, a plain-English description, and a JSON Schema describing the parameters. The model reads those definitions as part of its context. When it decides a tool would help answer the user, it stops generating prose and instead emits a structured call: get_weather with {"city": "Chicago"}. Crucially, the model never executes anything - it only asks. Your application receives the call, runs whatever real code implements it, and sends the result back as a new message. The model then resumes, now grounded in the answer.
Walk through one round trip. A user asks "what did we bill Acme last month?" The model sees a query_invoices tool in its definitions and emits a call with customer and date-range arguments. Your code validates the arguments, runs the database query, and returns the rows. The model reads them and writes the answer with the actual figure. Without the tool, the model would either refuse or - worse - invent a number, because billing data was never in its training set.
Reliability hinges on two things. First, the call must be well-formed, which is why providers constrain tool output to match the schema - the same machinery as structured output. Second, the model must pick the right tool with the right arguments, and that is steered by your descriptions: a tool described as "search the product catalog by keyword" gets used correctly far more often than one described as "search". Tool definitions are prompts, and they deserve the same editing care.
Tool use is the atom that larger structures are built from. Run it in a loop and you have an AI agent; standardize how tools are discovered and served across applications and you have MCP. It is also the natural enforcement point for safety: because every action passes through your code, you can validate, log, rate-limit, or require approval before anything runs.
Where it sits in the AI stack
Tool use is the boundary where model output becomes program input and back again:
Every tool definition and every result consumes context-window space, so agents with large tool inventories spend real effort deciding which definitions to expose per request rather than sending all of them every time.
Key tools and implementations
-
Provider function-calling APIs
Every major model API accepts tool definitions and returns structured calls natively.
-
JSON Schema
The lingua franca for describing tool parameters, shared across providers and frameworks.
-
MCP
An open protocol that packages tools into reusable servers any compatible client can call.
-
Framework tool decorators
Agent libraries that turn an annotated function into a tool definition automatically.
Related entries
- MCP (Model Context Protocol) An open protocol that lets AI applications connect to external tools and data through a standard client-server interface.
- AI agent A system where a language model plans, calls tools, and loops on results to finish a task with minimal supervision.
- Structured output Forcing a model's reply to match a schema, such as valid JSON, so software can parse it reliably.
- Guardrails Programmatic checks on an AI system's inputs, outputs, and actions that block or correct behavior outside defined limits.