Tool Use

Tool use — also called function calling — is the mechanism by which a language model requests that a specific function be executed with specific arguments, by emitting a structured call that the surrounding application (not the model itself) actually executes, feeding the result back into the model's context.

A language model on its own can only produce text from what it already knows. Tool use is what turns it into something that can look up a fact, run a calculation, query a database, or take an action in the world — the model decides what needs doing and describes the call; your code is the one that actually does it. This is the single primitive underneath the entire agent category: without tool use, there is no meaningful difference between a chatbot and an agent.

How it works

Each tool is declared with a name, a description of when to use it, and a schema defining its expected inputs. When the model determines a tool would help, it emits a structured tool-call block naming the tool and its arguments, validated against that schema. The application executes the real function — a database query, an API call, a file read — and returns the result as a tool result, which the model reads before continuing. This can happen once, or loop many times in sequence as an agent works through a multi-step task, with the model reasoning fresh at each step based on what the previous tool call actually returned.

Why it matters

Tool use is what makes grounded answers possible instead of guessed ones: a model with a search tool doesn't have to remember a fact, it can look it up; a model with a calculator doesn't have to do arithmetic in its head, where it's unreliable. It also carries a cost, both in tokens (every tool's schema takes up context space, every call and result adds a round trip) and in design responsibility (a tool with side effects needs the same validation and access controls as any other piece of code a stranger's input can trigger).

A worked example

A single tool-call round trip for a weather lookup costs roughly this in tokens: the tool's schema definition adds about 80 tokens to every request whether or not it gets used; the model's actual call adds about 30 tokens; the tool's result, injected back into context, adds about 150 tokens; the model's final answer using that result adds about 50 more — 310 tokens of overhead for one grounded fact. That's a real cost, but compare it to the alternative: a model guessing at a weather report from stale training data, confidently wrong, and the user acting on it — the 310 tokens are cheap insurance against exactly the failure hallucination describes.

How miatz teaches it

Tool use is the first thing learners build in the agents track, before memory, before guardrails, before anything else — a bare loop with one tool, wired by hand, so the mechanism (call, execute, return, continue) is understood as plumbing before it's wrapped in any framework. Every later agent pattern in the curriculum — ReAct, planner-executor, multi-agent orchestration — is built as a variation on this same primitive, and learners are expected to be able to say which part of a more complex system is still, underneath, just tool use.