An LLM without tools can only describe what it would do. Give it tools, and it can actually do it — search the web, query a database, run code, send a message. Tools are what turn an agent's reasoning into real-world action, and designing them well is one of the most consequential parts of building a genuinely useful agent. Here's how they work.
What a Tool Actually Is
A tool is a defined function an agent can call — with a name, a description of what it does, and a specification of what inputs it expects — that performs some real action or retrieves some real information outside the LLM's own generated text. As covered in the JSON output post earlier in this series, this typically works through function calling: the model doesn't generate free-form text describing an action, it selects a tool and produces structured parameters for it, which the surrounding application then actually executes.
{
"name": "search_flights",
"description": "Search for flights between two cities on a given date",
"parameters": {
"origin": "string",
"destination": "string",
"date": "string"
}
}
Given this definition, the agent's LLM can decide, based on the task at hand, to call search_flights with specific parameters — and the application executes the actual search, returning real results back into the agent's context.
Common Categories of Tools
Information retrieval tools. Web search, database queries, document retrieval (connecting directly to the RAG and vector search posts in this series) — giving an agent access to current or specific information beyond what's in its training data.
Computation tools. Code execution, calculators, data analysis functions — letting an agent perform precise operations an LLM alone is unreliable at, like exact arithmetic or statistical analysis.
Action tools. Sending emails, creating calendar events, updating records, making purchases — tools that change something in the real world rather than just retrieving information.
Communication tools. Messaging other systems, APIs, or even other agents (relevant to the multi-agent architecture covered later in this series) — letting an agent coordinate with other parts of a larger system.
Why Tool Design Matters So Much
Clear descriptions drive correct usage. An LLM decides which tool to call, and when, based largely on the tool's name and description — vague or overlapping descriptions lead to the agent picking the wrong tool, or failing to recognize when a tool is actually needed. This connects directly to the prompt engineering principles covered earlier in this series: clarity and specificity matter here just as much as in a written prompt.
Well-scoped tools reduce errors. A tool that does one clear thing is easier for an agent to use correctly than an overly broad, multi-purpose one. Narrow, well-defined tools also make an agent's behavior easier to predict, test, and debug.
Structured outputs make results usable. As covered in the JSON output post, a tool's results should come back in a predictable, structured format the agent can reliably parse and reason about — not a loosely formatted block of text the model has to interpret.
Privilege and Risk: Not Every Tool Should Be Available Every Time
This connects directly to the privilege limitation principle covered in the prompt injection prevention post. Giving an agent broad, standing access to every tool it might conceivably need — email, financial systems, file deletion, code execution — all at once significantly raises the potential damage of a flawed decision or a successful injection attack. Well-designed agent systems scope tool access to exactly what a given task requires, and reserve the most consequential tools (sending money, deleting data, executing irreversible actions) for human-confirmed execution rather than fully autonomous use.
Dynamic vs. Static Tool Provisioning
Some agent frameworks give an agent access to a fixed, predefined set of tools for the entire task. More advanced designs support dynamic tool provisioning — selectively exposing only the tools relevant to the current step or sub-task, rather than the agent's full available toolkit at all times. This reduces the chance of the model selecting an irrelevant or inappropriate tool, and keeps the decision space at each step more manageable, particularly as an agent's total tool library grows large.
Testing Tool Use Like Any Other Agent Behavior
As covered in the prompt testing strategies post, agent tool use benefits from the same systematic evaluation as any other AI behavior: does the agent select the correct tool for a given task? Does it supply correct parameters? Does it handle a tool's failure or unexpected output gracefully, rather than getting stuck or hallucinating a plausible-sounding but fabricated result? Testing across a representative, deliberately messy range of tasks — not just clean, ideal cases — is what actually reveals where tool-use logic breaks down.
The Bottom Line
Tools are what let an AI agent move from generating plausible-sounding text to taking real, verifiable action — searching, computing, communicating, and changing real systems. Designing them with clear descriptions, narrow scope, structured outputs, and deliberately limited privilege isn't a peripheral detail — it's central to whether an agent behaves reliably and safely, and it deserves the same care and testing discipline as prompt design itself.