# Tool use

> **What you will learn**
> Exactly how tool use is structured, and why it resolves most of the limits
> from the previous chapters.

## The limits, restated

We listed four things [a language model](/guide/ai-language-model) cannot do:

```
exact arithmetic · current facts · your company's information · repeatable accuracy
```

All four share one root. **The model only knows what it has seen.** It has no
way to reach outside.

**Tool use builds that passage.**

## The structure

You tell the model, alongside the question, **a list of functions it may call.**

```
Available tools:
  - check_stock(product_code)  : returns the current stock quantity
  - check_order(order_number)  : returns order status and shipping info
  - calculate(expression)      : evaluates an expression and returns the result
```

Now the model can **ask to call a tool instead of writing an answer.**

```mermaid
graph TD
  A["Person: how much A-1023 is left?"] --> B["Model"]
  B -->|"check_stock('A-1023')"| C["The real system"]
  C -->|"result: 47"| B
  B --> D["Answer: there are 47 in stock"]
```

### The flow in detail

1. A person asks
2. The model judges — "this is a value I don't have; I should use check_stock"
3. The model emits a **tool call request**: `check_stock("A-1023")`
4. **The system performs the actual execution** (not the model)
5. The result goes back to the model
6. The model produces an answer incorporating the result

> **Remember step 4.** The model only asks "please call this"; it does not
> execute. That is why **you can insert human approval before execution.** This
> is the point at which guardrails become possible.

## What changes

| | Without tools | With tools |
|---|---|---|
| "How much stock is left?" | doesn't know (or invents) | the real value |
| "What's 237 × 481?" | a plausible number | the exact calculation |
| "What's today's exchange rate?" | doesn't know | a search result |
| "When will this order arrive?" | doesn't know | a lookup in the order system |
| Basis for the answer | none | **you can see which tool it came from** |

That last row matters most in practice. **Once an answer has a basis, you can
verify it.** It is also why [hallucination](/guide/ai-hallucination) drops
sharply — there is nothing to invent.

## Tools do not only read

This is where their character diverges.

| Kind | Example | Risk |
|---|---|---|
| **Read** | stock lookup, document search, calculation | low. Nothing to undo if wrong |
| **Write** | send email, create an order, save a file | **high. Hard to undo** |
| **Delete / pay** | delete data, issue a refund | **very high** |

Attaching read tools and attaching write tools are **completely different
decisions.** Read can generally be started safely; from write onwards, approval
design has to go with it.

> **Start with read tools.** They alone cut hallucination sharply and raise
> answer quality. Write comes after.

## Deciding which tools you need

Write out the workflow and mark **what has to be looked at in each step**, and
the tool list falls out.

```
Invoice processing:
  1. get the attachment from email   → email tool (read)
  2. read the invoice contents       → document reading (read)
  3. verify supplier details         → ERP lookup (read)
  4. decide the account code         → (the model judges)
  5. enter it into accounting        → ERP write (write) ← approval point
```

Only step 4 is the model; the rest are tools. **Most AI projects are one piece
of judgement and a lot of plumbing.**

## Common misconceptions

### "Once you attach tools, does AI handle everything?"

Tools only make things **reachable.** What to call and when is still the model's
judgement, and that judgement can be wrong. It may call the wrong tool, or fail
to call one it should have.

This gets worse as tools multiply, which is covered in
[tools and MCP](/guide/mcp-why-standard).

### "So more tools is better?"

No — often the opposite. With 200 tools the model **struggles to pick the right
one.** People too pick the wrong tool more often from a bench holding 200 of
them.

### "Write tools are risky — better not to use them?"

Without write there is no automation. You attach them **with approval points
designed in.** Put a human only in front of **things that are hard to undo** —
"over the threshold needs approval," "external sends need approval."

---

## Check yourself

**1. Who performs the actual execution in a tool call? Why does it matter?**

<details>
<summary>Answer</summary>

**The system executes.** The model only requests "please call this." That is why
**human approval can be inserted before execution**, and it is the point at
which guardrails become possible.
</details>

**2. Why separate read tools from write tools?**

<details>
<summary>Answer</summary>

**Because reversibility differs.** Read has nothing to undo when wrong, so it
can be started safely; write (sending email, creating orders) and delete or
payment are hard to undo, so approval design has to accompany them.
</details>

**3. Why is attaching more tools not better?**

<details>
<summary>Answer</summary>

As tools multiply the model **struggles to pick the right one.** With several
similar tools available, the chance of calling the wrong one goes up.
</details>

---

With tools in hand, it can go and find material →
[Finding and attaching sources](/guide/ai-grounding)