Tool use is the umbrella term for an LLM's ability to call external functions, APIs or services to extend its capabilities beyond pure text generation. It is the broader concept that includes function calling (the API mechanism), browser automation (a specific kind of tool), code execution, retrieval and any other action the model can take. By 2026 tool use is core to every serious LLM application.
The categories of tools that matter in production:
- Read tools — search the web, query a database, fetch a URL, read a file, look up a record. Information in.
- Write tools — send email, create calendar event, update database row, post to API. Action out.
- Compute tools — run code, do math, parse a date, validate a schema. Determinism on tap.
- Communication tools — Slack messages, SMS, voice calls, in-app notifications. Reach the user.
- Meta tools — call another agent, list available tools, ask the user a clarifying question.
The architecture pattern that has stabilised:
- Define tools with clear names, descriptions and JSON schemas.
- Pass them to the LLM API alongside the conversation.
- The LLM decides whether to call a tool or respond directly.
- Your code executes the tool and returns the result.
- The LLM continues, possibly calling more tools.
- Eventually the LLM produces a final response.
What separates good tool use from bad in production:
- Clear, focused tool descriptions — vague descriptions lead to wrong calls. "Searches the company knowledge base" beats "search".
- Minimal argument schemas — fewer required arguments mean fewer ways for the model to mess up.
- Idempotency — tools should be safe to call twice with the same arguments; retries happen.
- Error handling — when a tool fails, return a useful error message to the model so it can recover or escalate.
- Permission boundaries — a tool that can read should not also be able to write; separate read and write tools.
- Observability — log every tool call, every result, every retry. When agents misbehave, this is your only debugging surface.
The 2026 mature pattern is to treat tools as a security boundary. The LLM is fundamentally untrusted code generating untrusted requests; your tools are the place where trust is enforced. Any consequential action (sending money, sending email externally, deleting data) should require explicit approval, validation against business rules, or both. Done well, tool use turns LLMs from impressive demos into production systems that real businesses run on. Done badly, tool use turns an LLM into a confused intern with admin credentials.
