A tool is a function the agent can call: a piece of code that does one thing well, has a clear input/output contract, and is the agent's interface to the outside world.
Tools are the agent's hands. The agent reasons about what to do, and the tool does the thing. Without tools, the agent is just a text generator; with tools, the agent can search the web, edit files, query databases, send messages, and do anything else the operator wires up.
The anatomy of a tool
A tool typically has:
1. A name. A short identifier that the agent uses to reference the tool. The name is the API surface.
2. A description. A short explanation of what the tool does and when it should be used. The description is what the model reads to decide whether to invoke the tool.
3. A schema. A JSON schema that defines the tool's inputs and their types. The schema is what the model uses to construct the arguments.
4. An implementation. The code that runs when the tool is called. The implementation is the actual work.
5. An error mode. A specification of what happens when the tool fails. The error mode is what the agent sees when something goes wrong.
Why tools are the right abstraction
Tools are the right abstraction for the agent's interface to the outside world because tools are deterministic, tools are reviewable, and tools are reusable. The agent is non-deterministic (the model may produce different outputs for the same input), but the tool is deterministic (the tool's output is determined by the tool's input and the tool's implementation). The agent's reasoning is hard to review, but the tool's behavior is easy to review. The agent's procedures are hard to share, but the tool's procedure is easy to share.
The tool failure modes
The most common operator issues with tools are: the tool is misused (the agent calls the tool in the wrong situation), the tool is overused (the agent calls the tool when it should reason), the tool is silent (the tool fails without producing an error), the tool is slow (the tool times out before returning), and the tool is unsafe (the tool has access to resources it should not have). The tool is the right place to look when an operator is debugging an agent that is behaving erratically.
Related terms
A tool is what an agent loop invokes during the tool execution step. A tool is often exposed to the agent through MCP for cross-platform reuse. A tool's evolution is tracked through observability. A tool's use is one of the inputs to the algorithm that decides when the agent should stop.
For the full primer, see First Steps: Sessions and Memory.
Tools vs. APIs
The tool is not an API. An API is a contract between a consumer and a producer; a tool is a function the agent can call. The tool is the right abstraction for the agent's interface because the tool is one-way (the agent calls the tool, the tool does not call the agent), the tool is synchronous (the agent waits for the tool to return), and the tool is bounded (the tool does a specific thing and the tool returns).
The API is the wrong abstraction for the agent's interface because the API is bidirectional, the API is asynchronous, and the API is open-ended. The right pattern for the agent's interface is the tool: the tool is one-way, the tool is synchronous, the tool is bounded, and the tool is the right shape for the agent's agent loop.