Tool Use in one minute
The model can request a calculator operation instead of guessing a total, or ask a connected system for a product's current stock. The tool performs the operation and returns evidence. Saying 'I checked the stock' is not equivalent to making that request and receiving a valid response.
Tool Use connects a request with an execution
A tool normally has a name, a description and defined inputs. A stock lookup might accept a product identifier and warehouse code. The model selects the tool and proposes arguments. The application checks that the request is valid and authorised, runs the operation and supplies the returned data to the model. Further tool calls may follow when the task requires them.
- Request
The model proposes a specific tool and inputs.
- Execute
The application validates the request and calls the authorised system.
- Interpret
The returned result informs an answer or the next permitted step.
Suppose a shop needs boxes for 145 items, with 12 items per box. A calculator can compute the division, but the application still needs the correct business rule: only whole boxes can be ordered, so the result must be rounded up. A correct arithmetic operation does not repair a mistaken assumption about packaging or whether partly filled boxes are allowed.
Structured inputs reduce ambiguity. A product identifier should not be confused with a free-text product name, and a date range needs a clear interpretation. Schema validation can reject a missing field or the wrong data type. It cannot establish that the model selected the correct customer, price basis or reporting period. Those require additional checks.
Implementations differ. Anthropic's documentation, for example, distinguishes tools executed by the client application from tools executed on its servers. This is a concrete product arrangement, not a rule that all AI systems share. In either case, someone must provide the execution environment, enforce the relevant access boundaries and handle failures.
What kinds of tools can an assistant use?
| Tool | Possible operation | Important boundary |
|---|---|---|
| Search | Find pages or internal documents. | Source quality, access rights and freshness. |
| Calculator | Compute totals or compare figures. | Correct inputs, units and business rules. |
| Code | Process a dataset or create a chart. | Execution environment, files and network access. |
| Files | Read a document or save a report. | Allowed folders and the actual saved output. |
| APIs | Read or update an application record. | Account, operation and target identifier. |
| Find messages or prepare and send a draft. | Recipients, attachments and authority to send. | |
| Calendar | Inspect availability or create an event. | Time zones, participants and invitations. |
| Databases | Query records or apply a change. | Filters, permissions and write scope. |
These possibilities are examples, not a list of capabilities every assistant possesses. A chat product may provide search but no email integration. An installed connector may support reading without writing. Even when an account allows an operation technically, the current task may not authorise it. Capability, permission and the assignment are separate questions.
Connectors connect an application to an external service. MCP can standardise how tools and context are exposed. RAG describes retrieving information and supplying it to a generator. These concepts can work together, but they name different layers. A connected file source is not by itself a complete retrieval-and-answering workflow.
When an application has no suitable API, Computer Use can provide an alternative through buttons and forms. It still needs an execution environment and permissions, and introduces additional uncertainty about focus, interface state and what an action actually changed. A structured API is often easier to validate when an appropriate one is available.
Tool Use can support an isolated request or a longer process. An assistant may call one calculator and finish. AI Agents may repeatedly choose tools as new results arrive. The number of available tools does not itself establish that a system behaves as an agent or completes a task reliably.
Permissions, evidence and controlled recovery
Authentication establishes which account is being used. Authorisation determines what that account or integration may do. The user's instruction defines what should be done for this task. A mailbox connection with broad rights does not turn a request to analyse messages into permission to email every contact. The application must enforce that distinction.
A sandbox limits the execution environment. Code or interface actions can run in an environment with restricted files, credentials and network access. This limits possible consequences but is not a guarantee of safety. The actual boundary depends on its configuration and on which services and data remain reachable.
Retrieved pages, emails and documents are data sources. They may contain misleading instructions, including requests to reveal credentials or ignore the user's task. Treating such text as a new authorisation creates a prompt-injection risk. Access controls should be enforced outside the model; a convincing paragraph in a document must not expand its permissions.
Retries also need care. A failed read can often be attempted again within a sensible limit. After a write times out, however, the operation may already have succeeded. Repeating it blindly can create duplicate records or messages. Check the target state, use an operation identifier where supported and stop when the outcome remains ambiguous.
- Expose only the tools needed for the task.
- Validate important inputs and target identifiers.
- Keep secrets out of prompts and unnecessary logs.
- Check the actual outcome, including partial failures.
- Use a concrete review step before actions that require approval.
Human-in-the-loop supplies that review where it matters. An Agentic Workflow organises conditions, limits and recovery around tool calls. Together, they turn a set of technical capabilities into a process that can be checked: what was requested, which operation ran and whether the result meets the original goal.