TL;DR
A tool is a function you let the model call by name to do real work — math, a database lookup, a web search, an email send. Without tools the model has only one move: produce text. With a tool it gets a second move: stop, ask for the tool to run, wait for the real result, then keep going. The model orchestrates; the tool acts.
The idea
A raw LLM (Module 1) does exactly one thing: text in, text out. That's enough to describe the world, but not to act on it. Ask it "what's 47362 × 1989?" and it will write down a number that looks like an answer — but it never multiplied anything. It generated text that resembles a multiplication result, token by token. The bigger the numbers, the further off it drifts.
A tool gives the model a way out of that trap. Each tool has three parts:
- A name the model uses to call it (
calculator). - A description in plain English that tells the model what it does and when to use it.
- A typed input list — the arguments the model is allowed to supply.
With a calculator tool available, the model gets a second move: instead of
guessing the digits, it stops generating, emits a call like
calculator({ expression: "47362 * 1989" }), waits for the platform to run the
real function, then continues writing using the exact result.
Analogy
Think of the model as a smart colleague on the phone. They can reason about anything, but they can't reach the filing cabinet, run a spreadsheet, or send the email themselves — they have to ask you to do it and tell them what came back. Tools are the set of things they're allowed to ask for.
Example: the same question, with and without a calculator
The pattern generalizes to anything the model is unreliable at on its own:
| The model is bad at… | The tool that fixes it |
|---|---|
| Exact arithmetic on big numbers | calculator |
| Knowing today's data (prices, weather, your records) | a lookup / search tool |
| Acting in the world (sending, booking, writing) | an action tool (send_email, create_ticket) |
The reason a tool beats "just use a bigger model" is that arithmetic isn't a knowledge problem — it's an execution problem. A bigger model still predicts text; a calculator actually computes. Hand the deterministic work to code and the model only has to decide when to call it.
Try it yourself
Same math question. Same model. The only difference: one column gives the agent a
calculator tool. Watch the answers diverge — and notice the tool column shows the
model choosing to call the tool rather than answering directly.
Common mistake
A tool doesn't make the model "smarter" — it makes it able to act. Giving it ten tools it never needs won't help; giving it the one tool that does the job it's bad at will. The skill is matching the tool to the model's weak spot.
Key takeaways
Key takeaways
- A tool is a named function the model can call to do real work.
- Every tool has a name, a description, and a typed input list.
- Without tools the model can only produce text; with them it can act and use real results.
- Use tools for what the model is bad at: exact math, fresh data, real-world actions.
Go deeper: client tools vs. server tools
Not all tools run in the same place.
- Client tools are your functions. The model asks for them, but your
application actually runs the code and reports the result back. A
calculator, alookup_accountagainst your database, asend_emailthrough your mailer — these all run on your side. You'll build client tools in this lab. - Server tools run inside the model provider's infrastructure. The model asks for something like web search or code execution and the provider runs it, loops internally, and hands you back the finished answer — your app never sees the individual calls.
The mental model is the same either way: the model decides what to call; some code somewhere actually does it. The next lesson is about how the model knows what each tool does in the first place — its schema.