Tool calling, also called function calling, is the mechanism by which a language model emits a structured request to run an external function instead of, or before, answering in plain text. The application executes the requested tool, returns the result to the model, and the model uses that result to continue the task.
For AI agents in artificial intelligence, tool calling is the bridge between reasoning and action. It lets a model query databases, call APIs, run code or send messages, while the surrounding application keeps control over what is actually executed. Without it, an agent can only describe actions; with it, the agent can perform them.
How tool calling works in a model loop
Tool calling follows a request, execute, observe loop. The application sends the model a conversation together with tool definitions, each consisting of a name, a natural-language description and a JSON Schema for the parameters. The model decides whether a tool is needed and, if so, returns a tool call object with the tool name and arguments.
The model never executes anything itself. The host application validates the arguments, runs the function, and appends the result to the conversation as a tool result message linked to the call identifier. The model then reads that result and either calls another tool or produces the final answer. An agent may repeat this loop from one to dozens of times for a single task.
| Step | Performed by | Content |
|---|---|---|
| Declare tools | Application | Names, descriptions, parameter schemas |
| Select and fill | Model | Tool name with JSON arguments |
| Validate | Application | Schema check, permission check |
| Execute | Application or service | API call, query, code run |
| Return result | Application | Output or error linked to call ID |
| Continue | Model | Next call or final answer |
Tool definitions and calling modes
The tool description is effectively a prompt: the model chooses tools based on how they are named and described. Clear descriptions state what the tool does, when to use it, what each parameter means and what the tool returns. Enumerations, required fields and formats in the schema reduce argument errors considerably.
Most model interfaces expose a tool choice setting that constrains the model’s behavior. Selecting the right mode is a practical design decision.
| Mode | Model behavior | Typical use |
|---|---|---|
| Auto | Model decides whether to call | General assistants and agents |
| Required | Model must call some tool | Pipelines that always need an action |
| Specific tool | Model must call the named tool | Structured extraction into a schema |
| None | Tools visible but not callable | Final summarizing turn |
| Parallel calls | Several calls in one turn | Independent lookups at once |
Many providers also support strict or constrained decoding, which guarantees that arguments match the declared schema. This removes malformed JSON but does not guarantee that the values themselves are correct or appropriate.
Tool calling compared with related agent concepts
Tool calling is a model capability, while terms such as AI agent, MCP and multi-agent system describe the architectures built around it. The table separates these neighbors.
| Concept | What it is | Relation to tool calling |
|---|---|---|
| Tool calling | Structured action requests by a model | The basic primitive |
| AI agent | System that loops model and tools toward a goal | Built on repeated tool calls |
| MCP | Open protocol for exposing tools and data | Standardizes how tools are offered |
| Structured output | Model reply constrained to a schema | Same mechanism, no execution |
| Multi-agent system | Several agents coordinating | Agents may call each other as tools |
| Agent memory | Persistent state across steps or sessions | Often read and written through tools |
An older alternative is prompt-based parsing, where the model writes an action in free text that the application extracts with patterns. Native tool calling is more reliable because the model was trained to produce the structured format and the call is separated from ordinary text.
Designing reliable and safe tools
Reliable tool calling depends more on tool design and guardrails than on the model alone. Each tool should do one clear thing, return concise and structured results, and produce informative error messages that the model can act on, such as which parameter was invalid and why.
| Situation | Recommended practice | Reason |
|---|---|---|
| Action changes data or spends money | Human confirmation step | Prevents costly mistaken actions |
| Large tool catalog | Load a relevant subset | Too many tools reduce selection accuracy |
| Large tool results | Truncate or paginate output | Protects the context window |
| Untrusted content in results | Treat results as data only | Limits prompt injection |
| Repeated failures | Retry limit and fallback | Avoids endless loops |
Permissions should follow the principle of least privilege: credentials stay in the application, never in the prompt, and each tool receives only the access it needs. Logging every call with its arguments and result provides the audit trail needed for debugging and governance.
Typical failure modes
Tool calling errors fall into a few recurring patterns that evaluation sets should cover explicitly.
- Wrong tool selection: overlapping descriptions lead the model to choose a similar but incorrect tool.
- Hallucinated arguments: the model invents an identifier or date that the user never provided instead of asking.
- Unnecessary calls: the model calls a tool for information already present in the conversation, adding latency and cost.
- Prompt injection through results: text returned by a web page or email tries to instruct the model to take other actions.
- Ignored errors: the model reports success even though the tool returned a failure.
Stripped to the essentials
A language model on its own can only write text. Tool calling gives it a way to ask for help from other programs, such as a calendar, a calculator or a database.
Think of the model as a manager who fills out a request form and hands it to an assistant. The assistant does the actual work and brings back the result, and the manager then decides what to do next. The model asks, the software acts, and people stay in control of which actions are allowed.
Where it is applied
A travel company builds a customer service assistant with four tools: look up a booking, check seat availability, change a booking and issue a refund. The lookup and availability tools run automatically, while change and refund require the customer to confirm the exact details first.
When a customer writes that they need to move their flight from Friday to Sunday, the model calls the lookup tool with the booking reference, then checks availability for Sunday, presents two options and, after confirmation, calls the change tool. Each call and its result are logged.
The assistant now resolves routine rebooking requests without a human agent, while refunds above a set amount are routed to staff. Weekly review of failed calls shows where tool descriptions need sharper wording.