Glossary
Tool calling
Tool calling is the mechanism by which a model asks for something to be run outside itself, such as a search or a calculation, and then uses whatever comes back in its answer.
In plain terms
A model can do exactly one thing, which is produce text. What this arrangement adds is an agreed way for it to produce a particular sort of text meaning please look up the order with this number. Your software recognises that, decides whether to act on it, does the lookup and hands the answer back. The model never touches the system. It asks, and something else decides.
Why it matters
This is the mechanism behind everything an assistant does rather than says, so it is worth understanding before you evaluate anything described as capable of taking action. It also relocates the safety question. People worry about a model deciding to do something rash, and the model cannot do anything at all: what can act is your own software, which chose to honour a request. That means the controls you need are ordinary ones, in a place you already know how to secure.
How it works
You supply a list of what is available, and the descriptions matter more than anything else in the arrangement. Each tool has a name, an explanation of what it is for and what it needs, all written in language the model reads. That description is what the model chooses from, so a vaguely described tool gets reached for in the wrong situations and a well-described one is picked correctly without any further instruction.
When the model decides one applies, it produces a structured request rather than an action. Your code receives a name and some arguments and nothing has happened yet. This is the step people picture wrongly, and getting it right removes most of the anxiety in the subject: at this moment the model has expressed an intention and has no means of carrying it out.
Your software then decides. Check the arguments are sensible, check this user is allowed this operation, check the amount is within a limit, and run it or refuse. That gate is entirely on your side of the line, which is why the same model can be perfectly safe in one product and reckless in another. The difference is not the model.
The result is handed back into the conversation and the model carries on with it in front of it. Each round of this costs a further request, so an answer needing three lookups takes noticeably longer and costs more than one that needed none. Products that feel slow when they act are usually doing several of these rounds rather than thinking hard.
The arguments deserve the same suspicion as any other input arriving from outside. A model can produce a plausible-looking value that is wrong, and material it has read can influence what it asks for, including material that arrived in a document from somebody else. Validating arguments before acting on them is not paranoia here; it is the same discipline any web form gets.
Who asks, who decides, and who actually does anything
Seen in the wild
Watch a coding assistant read a file, then run the tests, which is a sequence of these requests being granted one at a time by the software around it.
Claude CodeGive an assistant step a short list of tools in an automation and see which one it reaches for on a given message, which shows the descriptions doing the selecting.
n8nAsk a research assistant something current and watch it decide to search, which is the same mechanism concluding that its own recall is not enough.
Perplexity
Common misconceptions
People assume
The model runs the code.
In fact
It produces a request. Everything that actually runs does so because your software received that request and chose to honour it. Nothing about the model changes what it is permitted to do, and nothing about a model upgrade widens its reach, because the reach was never the model's.
People assume
This is the same thing as an agent.
In fact
This is one round of asking and answering. An agent is a loop that keeps doing it, deciding after each result what to ask for next, until it judges a goal met. The mechanism is shared and the difference is repetition and autonomy, which is where the risk lives.
People assume
The arguments it produces will be sensible.
In fact
Usually, and not dependably. A model can supply a well-formed value that is simply wrong, and text it has read can steer what it asks for, including text that arrived inside a document from outside your organisation. Treat arguments as untrusted input and validate them before acting, exactly as you would from any form.
Telling them apart
Tool calling vs AI agent
Tool calling
The mechanism. One request, one result, then the answer. Bounded by construction, because the conversation moves on.
A loop built on that mechanism, deciding what to ask for next each time until a goal is met or a limit stops it.
Every agent uses this. Not everything using it is an agent, and a product doing one lookup before answering is doing something considerably simpler than the word agent suggests.
Tool calling vs MCP
Tool calling
How a model asks for something and receives a result, which is a capability of the model and the software around it.
An agreed standard for describing what is available, so the same set of tools can be offered to several assistants.
The first happens whether or not anybody adopted a standard. The second is about not rebuilding the tool list for every assistant you want to offer it to.
Questions
- Can the model do something we did not allow?
- It can ask for it. Whether anything happens is decided entirely by your software, which receives the request and applies whatever checks you wrote. If an assistant did something it should not have, the fault is in the code that honoured the request, and that is genuinely better news than the alternative.
- How does it know which tool to use?
- From the descriptions you wrote. It reads what each one is for and picks the one that fits the request in front of it, with no separate training or configuration. That makes writing those descriptions a real task, and rewriting a vague one usually fixes a tool being ignored or reached for wrongly.
- Does it make things slower and dearer?
- Yes, and predictably. Each round trip is another request with the growing conversation attached, so an answer needing three lookups costs and takes noticeably more than one needing none. When a product feels sluggish while acting, it is usually the round trips rather than the thinking.
- What is the thing most likely to go wrong?
- Acting on an argument nobody checked. The model produces something well-formed and wrong, or is steered by text it read in a document, and software that runs requests without validating them does exactly as asked. Put the checks where you would put them for any input arriving from outside, and require a person for anything irreversible.
Key takeaways
- The model asks; it never acts. Everything that runs was honoured by your own software.
- Tool descriptions are what the model selects from, which makes writing them a real task.
- The gate, and therefore the safety, sits entirely on your side of the line.
- Each round trip adds time and cost, which is why acting feels slower than answering.
- Arguments are untrusted input, including where a document the model read influenced them.
Tools that use this
- Claude Code
Requests to read a file or run tests, granted one at a time.
- n8n
A short tool list where you can watch the descriptions do the choosing.
- Perplexity
Deciding to search rather than answer from recall.
Last checked July 2026