Tool Calling
Tools are the only reason an agent can do anything beyond talk. A tool is a plain function with a name, a one-line description, and an input. The model never runs code: it writes down which tool it wants, your program runs it, and the result comes back as text the model can read.
The contract, in four lines
| Name | calculator. The model writes this exactly. Anything else is rejected. |
|---|---|
| Description | One line telling the model when to reach for it. This is the whole user manual the model gets, so it is worth more care than the code. |
| Input | Usually a string or a small JSON object. Keep it simple: small models get complicated schemas wrong. |
| Output | Text going back into the prompt. Errors are output too, and a good agent reads them and tries again. |
The seven tools on this page really run
Try one directly first. This is what the agent gets back, with no model involved at all.
Optional: load a real model
The tool bench
Give the agent a job, and decide which tools it is allowed to use. Take a tool away and watch the behavior change: an agent with no calculator has to guess at arithmetic, which is exactly how wrong numbers get shipped.
The four ways tool calling goes wrong
Wrong tool
It reaches for search when it needed arithmetic. Fix the descriptions before you touch the model.
Bad arguments
The right tool with junk input. Return a clear error, not an empty string, so the model can correct itself. Try unit_convert with "some distance" above.
Invented tool
It calls something that does not exist. The allowlist blocks it and tells it so, which you can see in the trace.
Ignoring the result
It calls the calculator, gets 1442, then writes a different number anyway. Small models do this constantly. The trace on these pages checks the answer against the observations and flags the mismatch, which is exactly what your code should do.
Free from AI School - no signup, everything runs in your browser.