Tools and actions: let the model act

Target audience: technical + non-technical readers who want to go deeper | Prerequisites: 3.2 Context management

What you'll learn

After this document you will be able to:

• explain what function calling / tool use is (the capability by which the model can ask the system to perform an external action) and who actually performs the action;
• write down a tool description (name + description + parameters) — the thing the model bases its decision on for when to use the tool;
• follow the flow from question to answer step by step and see where the model works and where your system does;
• decide when tool calling earns its keep and when a pre-written workflow step (an automated sequence of steps, 2.3) is enough.

From 1.5 we know the system's three forms. In a workflow the whole path is pre-written — here we open the door that changes something essential: the AI model decides itself when to call a tool. But as we'll see right away, the actor is still your system.

In plain terms

Tool calling is like a secretary in an office with a list of internal phone extensions. A visitor asks: “What is the status of order no. 8812?” The secretary (the AI model) doesn't run to the archive themselves — they fill out a note “bring me folder order no. 8812” and hand it to the storeroom keeper (the system). The storeroom keeper fetches the folder, the secretary reads it and phrases the answer to the visitor. The secretary can't open a single door themselves — and before the folder arrives they don't know what it says.

What tool calling exactly is (and who actually does it)

The model knows language and makes inferences from text, but it has no eyes into your data and no hands in the outside world: it doesn't know whether invoice no. 2026-47 has been paid, and it can't send an email itself. Tool calling is the agreement that fills this gap. Three things are written into this agreement:

1. You describe the tool. Before the first conversation, you register the tool's description in the system: a name, a one-sentence description, and the parameters (the data the action needs).
2. The model decides whether and when to call. On every user request, the model reads both the question and the descriptions of all the available tools and decides: whether answering requires using a tool, which one, and with what data.
3. The call goes to your system, not the model. The model doesn't perform the action itself — it gives back a structured output (an answer in a predictable form, see 2.2): “call the tool named X with data Y”. Your system (your program, which performs the action) reads this call, sets the actual action in motion — searches the database, computes, sends — and gives the result back to the model. Only then does the model phrase the human-readable answer.

The third point is critical from a safety standpoint: the model does nothing on its own — the system does. The model can only suggest; every door opened and every data search is performed by the program, which behaves only the way you have allowed. How to set this up is the topic of 3.1 API integrations; what happens when a part of the system fails, 3.4 Errors and error handling covers.

How to describe a tool

The tool description has three parts:

• Name — short and precise: invoice_status, order_search, email_draft. The model distinguishes tools by their name, so two tools must not get the same name.
• Description — one sentence that says two things: what the tool does and when to use it. It's exactly on the description's basis that the model chooses — a tool with a vague description gets called at the wrong moment or not called at all, even if the system's side is flawless.
• Parameters — a structure in the style of a JSON schema (a data description that says which data are needed and in what form): each parameter's name, type (text, number), and whether it's required. Take only what the action really needs — not a copy of the whole conversation.

Sample: a tool that looks up an invoice's status.

{
  "name": "invoice_status",
  "description": "Returns the invoice's payment status from the accounting program. Use it when the user asks, by a specific invoice's number, whether it has been paid.",
  "parameters": {
    "invoice_number": {
      "type": "text",
      "required": "yes",
      "description": "The invoice's full number, for example “2026-47”"
    }
  }
}

In plain terms: a tool description is like a menu entry in a good café: the name says what the dish is, the description says when it's worth ordering, and the parameters are the question “how would you like it?” — a vague description brings something other than what was asked.

The flow: from question to answer

The whole flow passes through five steps:

   1. THE HUMAN asks
      “Has invoice no. 2026-47 been paid?”
                │
                ▼
   2. THE MODEL reads the question and the tools' descriptions
      decision: call invoice_status (invoice_number = “2026-47”)
      → a structured call to the SYSTEM
                │
                ▼
   3. THE SYSTEM performs the action
      a request to the accounting program
      → the program answers: “paid 2026-09-30”
                │
                ▼
   4. THE RESULT GOES BACK TO THE MODEL
      the system adds the result to the conversation
                │
                ▼
   5. THE MODEL PHRASES for the human
      “Yes — invoice no. 2026-47 was paid on September 30, 2026.”

Note who works at each step: the human asks, the model decides and phrases, the system searches and executes — points 1, 3, and 4 are your responsibility; 2 and 5 remain with the model.

Good and bad use cases

Tool calling pays off when the model needs access to facts or actions it doesn't have itself. Three good types:

The third row is also the most safety-sensitive: a tool that touches the outside world needs a confirmation chain built into the system — not the hope that the model “won't make a mistake by itself”. How to draw the line, 3.5 Safety shows.

When not to use it? If the same work can be done by a pre-written workflow step (2.3), prefer the step. The difference in both directions:

• A workflow step always runs — every time, in a fixed place, the same way. It's predictable, checkable, and cheaper.
• Tool calling is more flexible — the model decides in the course of the conversation when and how to use it — but exactly for that reason less predictable: similar conversations can take different paths.

So: questions known in advance and always the same path — build a workflow; free-form questions and a path that depends on the question — tool calling. The simplicity rule stays the same: agent-like behavior — where the model decides several steps ahead in a row — is the last, not the first choice (see 4.1).

In plain terms: a workflow is a bus line — a fixed route, fixed stops; tool calling is a taxi — it goes where the passenger asks, but not always by the same route. If every ride goes to one place, run the bus.

Step-by-step example: the Number Bureau's invoice_status tool

The fictional Number Bureau (1.6) — a small accounting office: owner Anu, five accountants, and Jaak, who builds the systems. In 2.1 the letters got uniform summaries; now the next recurring nuisance: accountants and clients keep asking “has invoice no. 2026-47 been paid?” and someone has to dig the answer up. Jaak builds the invoice_status tool.

First the tool description — exactly the JSON we saw above: the name invoice_status, a one-sentence description, and one parameter invoice_number. Then the flow step by step:

   1. THE ACCOUNTANT asks in the chat window:
      “Has invoice no. 2026-47 been paid yet?”
                │
                ▼
   2. THE MODEL: from the invoice base I know nothing,
      but from the descriptions I find the invoice_status tool —
      I call it with the parameter invoice_number = “2026-47”
      → the call goes to JAAK'S SYSTEM
                │
                ▼
   3. THE SYSTEM: reads the call, sends the request
      to the accounting program
      → the program answers: “paid 2026-09-30”
                │
                ▼
   4. THE SYSTEM GIVES THE RESULT BACK TO THE MODEL:
      “invoice_status result: paid 2026-09-30”
                │
                ▼
   5. THE MODEL PHRASES:
      “Yes — invoice no. 2026-47 was paid on September 30, 2026.”

Why this is good:

• The fact didn't come out of the model's head. The date 2026-09-30 came from the accounting program — nothing had to be guessed, so there's nowhere for a hallucination to sneak in.
• The model did only the two things it's good at: picked the right tool and put the number in the right place, and phrased the answer readably. The searching was done by the system.
• There are exactly as many parameters as needed. One number is all the required information — every extra field (customer name, date) would only give the model more ways to go wrong. What happens when a wrong number is asked for and the program finds nothing — 3.4 covers how that's handled.
• Sending, deleting, and paying wouldn't be tools here. This tool only reads; if Jaak later wants the system to also send reminders to clients, that can only be done with a confirmation chain — 3.5 Safety shows how to bound it.

In plain terms: Jaak didn't teach the model to recognize invoices — he gave the model a note to write the number on and a program that fetches the note. The model can never “find” a paid invoice, because it doesn't search — the system searches.

Summary

• Tool calling means the model asks, the system does: the model decides in the course of the conversation whether and when to use a tool, but your program always performs the action and the result goes back to the model for phrasing.
• The tool description has three parts: a name, a one-sentence description (what it does and when to use it), and the parameters — the data the action needs. The description's quality determines how well the model chooses.
• The model does nothing on its own — this is the critical safety point; everything touching the outside world goes through the system and, when needed, a human's approval (3.5).
• Good tools: data lookup, exact calculation, and action outside the system — the last only with a confirmation chain.
• When a pre-written workflow step is enough, use the step: tool calling is more flexible but less predictable; agent-like behavior is the last choice (4.1).

What's next?

• previous → 3.2 Context management
• next → 3.4 Errors and error handling — what happens when a tool call falls through
• Safety before acting → 3.5 Safety
• back → handbook index