On its own the model can do one thing — generate text. It can't look in a database, run code, find up-to-date information, or change a file. Tool calling (function calling) is the mechanism that removes this limit: the model gains the ability to request actions in the outside world. It's exactly what turns a "smart conversationalist" into an "executor".
How it works
The idea is simple. The model is described, in advance, a set of available tools — what each does and what parameters it takes (for example: "get_order(id) — return the order by number"). Then the loop:
- You give a task: "show the status of order 4521".
- The model realizes it can't answer itself, and instead of text outputs a structured call request:
get_order(id=4521). - Your program (not the model!) executes this call — goes to the database, gets the data.
- The result is returned to the model's context, and it formulates an answer based on real data.
The key point: the model doesn't execute the tool itself — it only asks for it to be called, and your system runs it. The model decides "what and when to call", the code decides "how, and whether it's allowed".
Why it matters
Tool calling closes the main weaknesses of a bare model:
- Freshness. The model doesn't know recent data or your private context. A tool (search, a database query, reading a file) gives it real data instead of made-up data.
- Action, not just advice. With tools the model doesn't merely advise "do X" — it can create a record, send an email, change a file, run a test.
- Saving context. Instead of pouring the whole repository into the model, you give it a "search the code" tool — it fetches what's needed on demand, saving tokens.
In essence tools are grounding in reality: the model stops relying only on "memory from training" and works with the real world.
Standardization: MCP
Tools used to be connected to the model each in its own way. Now standards are emerging — in particular MCP (Model Context Protocol): a single way to describe tools and data sources so the model can connect to them uniformly. For a product engineer this means equipping an agent with access to your systems becomes simpler and portable. More on this in the article on MCP.
On caution
Tools give the model the power to act — and therefore the power to do harm. Reasonable boundaries are mandatory:
- Reading is safer than changing. Letting the model read the database is one thing; letting it delete from it is quite another.
- Dangerous actions go through confirmation. The irreversible (deletion, payment, sending outward) is best done through explicit human approval.
- Permissions are minimal. A tool should be able to do exactly what the task needs, no more.
What this means in practice
Tool calling is what turns the model from a "chatterbox" into a working executor inside your systems. A product engineer designs which tools to give the model and with what boundaries: what it can read, what it can change, and what it may only propose to a human. A well-chosen set of tools is often more important than the model's own "smartness".
What's next
When the model, in a loop, decides for itself which tools to call and in what order to reach a goal — that's agents. On the single protocol for connecting tools — MCP.