A model can't run code, query a database, or read a file — it only produces text. So how does an agent ever do anything? Through tool use: a simple contract that lets the model ask for an action and get a real answer back.
What a tool actually is
A tool is just two things the model is told about: a name (read_file, search_web) and an input schema — the shape of the arguments, like { path: string }. The model never sees the tool's code. It only knows the name, what the tool is for, and what arguments it expects.
How it works
When the model wants to act, it doesn't write a sentence — it emits a structured tool call: the tool's name plus arguments that fit the schema. The harness intercepts that call, runs the real function, and feeds the result back into the model's next turn. The model reads the result and decides what to do next. Follow the path in the diagram below.
- ModelKnows each tool's name and input schema. It can't run code — it can only ask.
- Tool call (schema)A structured request: the tool's name plus arguments that fit its input schema.
- HarnessIntercepts the call, runs the real function, and feeds the result back into the model.
- ToolThe actual function — read a file, query a database, search the web.
In our stack — Anthropic's Claude model emits the tool calls; Claude Code executes them. Built-in tools edit files and run commands, and MCP servers add more — connecting Claude to databases, issue trackers, or any external system through the same schema-based contract.
The same trick gives you structured output
Tool use isn't only for taking actions. Define a tool whose schema is the shape of data you want — say { name, price, in_stock } — and the model's tool call becomes clean, validated structured output instead of free text you'd have to parse. One mechanism: act in the world, or return reliable data.