Tool calling is the mechanism that lets a language model request actions from external systems, such as searching a database, calling an API or running code. The model does not execute anything itself: it emits a structured request naming a tool and its arguments, your application runs it, and the result is returned to the model. Tool calling is what turns a text generator into an agent that can affect the world.
Key takeaways
- The model chooses which tool and what arguments; your code does the execution.
- Tools are described with names, descriptions and a JSON schema for parameters.
- Tool descriptions are prompt engineering: vague descriptions cause wrong calls.
- Models can call several tools, sometimes in parallel, across multiple turns.
- Tools are a security boundary, and untrusted results can carry prompt injection.
Tool calling explained in simple terms
A consultant who cannot access your systems can only advise. Give them a phone and system logins and they can check the actual order, update the record and email the customer. Tool calling is handing the model those capabilities, while you keep control of what it may touch.
How it works
- You send the model a list of available tools, each with a description and parameter schema.
- The model decides a tool is needed and returns a structured call, for example `get_order(order_id: “INV-2041”)`.
- Your application validates the arguments and executes the function.
- The result is appended to the conversation as a tool result.
- The model uses it to answer or to call another tool.
Steps 2 to 5 repeat, forming the agent loop.
A worked example
User: “Is order 4471 delayed, and if so tell me the new date.”
- Model calls `get_order(order_id: “4471”)`.
- Result: status “in transit”, carrier “BlueDart”, tracking “BD983…”.
- Model calls `track_shipment(carrier: “BlueDart”, tracking_id: “BD983…”)`.
- Result: expected delivery 14 October, two days later than promised.
- Model answers: the order is delayed by two days, with the new date.
Two tools, chosen by the model, executed by your code.
Designing good tools
| Principle | Why |
|---|---|
| Clear names and descriptions | The model chooses tools by reading them |
| Narrow, single-purpose tools | Easier for the model to use correctly |
| Strict parameter schemas | Prevents malformed calls |
| Useful error messages | Lets the model retry sensibly |
| Return only what is needed | Large outputs waste context |
| Idempotent where possible | Safe to retry after a failure |
Treat tool descriptions like documentation written for a capable but literal new colleague.
Standards and ecosystems
Providers expose tool calling through their APIs, and the Model Context Protocol (MCP), introduced by Anthropic in late 2024, standardises how applications connect models to external tools and data sources. A shared protocol means one connector can serve many applications instead of writing bespoke integrations for each.
Security considerations
- Permissions: give each tool the minimum access it needs.
- Validation: never trust model-supplied arguments; validate and sanitise them.
- Prompt injection: content returned by a tool, such as a web page, may contain instructions. Treat tool results as data, not commands.
- Approval gates: require human confirmation for payments, deletions and outbound messages.
- Audit logs: record every call, argument and result.
Limitations
- Models sometimes call the wrong tool or invent arguments.
- Too many tools confuse selection; keep the list focused.
- Each call adds latency and tokens.
- Tool failures need explicit handling, or the agent stalls.