Key insight

A model alone can only produce text — it can't look things up, do reliable arithmetic, or take actions. Tool calling fixes that: you give the model a menu of functions it's allowed to request; when one would help, it asks, your code actually runs it, and the result flows back for the model to answer from. The golden rule: the model proposes, your code disposes — which is what keeps it both powerful and safe.

Everything a model does with words alone has a hard ceiling: it can't actually do anything in the world. Tool calling — also called function calling — is the mechanism that breaks through that ceiling, and it's the step that turns a chatbot into something that can genuinely act on your behalf. This guide starts from nothing and builds up exactly how it works, and how to use it safely.

1 · A brilliant mind with no hands

A language model can reason and explain beautifully, but on its own it can't check today's weather, look up your order status, query a database, do reliable arithmetic on big numbers, or send an email. It only produces text. Picture a brilliant mind locked in a room with no hands and no windows: it can think and talk, but it can't reach out and touch anything, and it can't see what's happening right now. For many useful applications that's a dealbreaker — you don't want the model to talk about your order, you want it to look up your actual order and tell you where it is. Tool calling is what gives that brilliant mind a set of hands.

A model alone can talk but not act The model knows a lot and says a lot, but can't look things up or take actions. knows a lot, says a lotbut only produces text can't look upcan't act a mind with no hands and no windows
Figure 1. The gap tools fill: without them, even the smartest model can only describe the world, never touch it.

It starts with a menu. When you set up the model, you also give it a list of tools it's allowed to use. Each tool is just a function in your own code — something like get_weather or lookup_order — and for each you provide a short description: its name, what it does in plain language, and what inputs it needs (get_weather “returns the current weather; needs a city name”). The model reads this menu like a list of buttons on a control panel. Crucially, handing over the menu doesn't let the model run your code — it just tells the model what's available and how to ask for it. You stay in control of what tools exist and what they touch. The menu is a contract: these are the actions this assistant may request, and nothing else.

3 · It asks, your code runs

Here's the key move, and it's the one people get backwards. When the model decides a tool would help, it does not run the tool — it can't. Instead it produces a special, structured piece of text meaning: “please call lookup_order with id 1234.” Your application code sees that request, actually runs the real function — hitting your real database — and gets back a real result like “order 1234 ships tomorrow.” Then you hand that result back to the model as more input. So the flow is: the model asks, your code executes, the answer flows back. The model is the decision-maker choosing which button to press and with what inputs; your code is the hands that press it. This separation is what keeps things safe — the model can only ever request the tools you exposed, never reach past that menu into the rest of your system.

The tool-calling loop The model requests a tool, your code runs it, the real result flows back, and the model answers. model asks your code runs it result flows back the model never runs code — it requests, you execute
Figure 2. The safe loop at the heart of tool calling: proposal by the model, execution by your code, result back to the model.

4 · Then it answers in plain words

Once the model receives the tool's result, it does what it's best at: turning raw data into a natural, helpful reply. The database might return something terse like status: shipped, eta: Friday; the model takes that and says, “Good news! Your order has shipped and should arrive Friday.” So the user experiences one smooth conversation, while behind the scenes the model quietly reached out through a tool to fetch live, accurate information and wrapped it in friendly language. This is the whole magic of tool calling: it combines the model's language ability with your systems' real data and real actions. The user asks in plain English, the model figures out it needs a tool, requests it, your code runs it, and the model answers in plain English — grounded in a true, current fact rather than a guess. The seam is invisible, which is exactly the point.

5 · Chaining several tools together

Tool calling isn't limited to one call. The model can chain several tools to handle a request that needs multiple steps. Ask “what should I wear in my hometown today?” and it might first call a tool to find your hometown, then call the weather tool for that city, then reason and give advice — all before writing a word to you. It runs a little loop: think, request a tool, read the result, decide whether another is needed, and eventually produce the final answer. This ability to string tools together is exactly what starts to make a model feel like an agent rather than a chatbot — it's not just answering, it's taking a sequence of actions to accomplish a goal. Later topics go deeper into that agentic behaviour; for now, the point is that one user request can quietly set off a whole chain of tool calls behind the scenes.

6 · Why this beats stuffing the prompt

Why not just cram all the needed information into the prompt instead? Sometimes you can — that's what retrieval does for documents. But tools solve problems retrieval can't. Freshness: a tool fetches data current this second — today's price, right-now inventory — which no pre-loaded text can guarantee. Action: tools don't just read, they do — book the appointment, send the message, update the record. Precision: for exact operations like arithmetic or a database lookup, calling real code is reliable, whereas asking the model to compute or recall invites mistakes. And scale: you can't fit your entire database in a prompt, but a tool can query exactly the row you need on demand. So tools connect the model to live data and real actions in your systems — a fundamentally bigger capability than anything you can freeze into a prompt.

7 · With hands comes responsibility

Giving a model hands means thinking about safety, and it connects straight back to earlier topics. The model decides which tool to call, but your code decides whether to actually run it — that's your safety checkpoint. Remember prompt injection: if a tool reads outside text, that text might try to trick the model into calling a dangerous tool. So the rules are: expose only the tools an assistant genuinely needs, and make read-only tools the default. For anything that changes data or costs money — sending, deleting, purchasing — require a real confirmation step or a human's approval before your code executes it. Always enforce the user's actual permissions in your code, never trusting the model to self-police: if this user can't see that record, the tool refuses regardless of what the model asked. The model proposes; your code disposes. With hands comes responsibility, and that responsibility lives firmly in your code.

The one sentence to remember

Tools turn a text generator into something that can act — because the model only ever proposes a tool call, and your code decides what actually runs.

8 · A simple test you can run this week

Design one tool on paper

1. Pick a task an assistant could help with that needs live data or an action.
2. Write the tool's menu entry: its name, what it does, and the inputs it needs.
3. Trace the loop: what would the model ask, what would your code run, what comes back?
4. Mark whether it only reads or also changes things — and where you'd add a confirmation.

The lesson: the model proposes; your code decides what's allowed.

9 · Glossary — every term, spelled out

Tool / function calling
The mechanism by which a model requests that one of your functions be run, so it can use live data or take actions.
Tool
A function in your code that you've described to the model and allowed it to request.
Tool menu
The list of available tools — names, descriptions, and inputs — you give the model up front.
Tool call request
The structured text the model produces to say “please run this tool with these inputs.”
Chaining
Using several tool calls in sequence to accomplish a multi-step task — the seed of agent behaviour.
Confirmation step
A human check required before your code runs a tool that changes data or costs money.
Key takeaways

A model alone only produces text — tools give it hands to fetch data and take actions.
You hand the model a menu of tools; it asks, your code runs them, and the result flows back.
It can chain several tools for multi-step tasks — the beginning of agent behaviour.
Your code enforces what's allowed: least privilege, permissions, and confirmation for risky actions.

References

  1. OpenAI, Function calling guide — how models request tools and receive results. platform.openai.com
  2. Anthropic, Tool use overview — giving a model tools and handling its requests safely. docs.anthropic.com
  3. This guide’s MCP, Explained From Zero — a standard way to expose and share tools.
  4. This guide’s Context Engineering, Explained From Zero — deciding what goes into the window, including tool results.