Learn AI /AI Agents and Automation /Tool use

Tool use

Also called: tools, tool calling.

Detail

In five seconds

What it is

A system uses external software or devices during a task to look up information, calculate, carry out actions or control equipment beyond its own processing.

In plain words

It means the system can reach out to other software or devices during a task, instead of only writing text from what it has already seen.

An everyday example

A water utility worker sees an unusual reading from a pump sensor in a rural station. Instead of guessing, she checks the live sensor dashboard, looks up the normal range in the maintenance manual, and then opens a repair ticket if the reading is still abnormal. She uses different tools for each step because no single screen contains everything. The final action depends on what those tools return.

Where the story stops working

A person can apply broad real-world judgement, notice context that was never written down, and take responsibility for the outcome. An AI system using tools does not have that kind of independent judgement. It follows patterns, instructions and permissions in its setup, and it can misuse a tool if the inputs, rules or tool outputs are misleading.

Remember thisTool use lets a model request information or actions from external systems and continue from the response. Access controls, validation and human confirmation therefore matter as much as the model's output.

Understand it

Why it matters

For a non-specialist, tool use is the point where an AI system can move from sounding helpful to actually affecting work. It can fetch current information, update records and trigger actions in other systems. That can improve speed and consistency, but it also changes the risk. A wrong answer in a chat window may be inconvenient; a wrong tool action can create a false alert, change a database or send a message to the wrong place. When you hear that a system can use tools, the practical questions are: What tools? With what permissions? What checks exist? Who reviews important actions? What logs are kept? Those questions matter more than marketing labels.

How tool use changes a task

After viewing this, a reader should be able to describe how a system moves from a request to one or more tool calls and then to a checked result or action.

01
1. Request arrives
The starting point is a question, instruction or system event, such as an unusual sensor reading.
Draw a rounded rectangle labelled 'Request or event' with smaller examples underneath: 'Ask for data', 'Check a reading', 'Create a ticket'.
02
2. Check whether a tool is needed
The system first tries to determine whether text alone is enough or whether it needs fresh data, calculation or an external action.
Draw a decision-style box labelled 'Need a tool?' with two small tags below: 'No → answer directly' and 'Yes → choose tool'.
03
3. Send a structured tool request
If a tool is needed, the system prepares the input in a defined format, such as a location, date range or sensor ID.
Draw a box labelled 'Call tool' with three icon labels beneath: 'database', 'calculator', 'sensor/API'. Add a caption: 'structured input'.
04
4. Tool returns a result
The tool sends back data or confirms that an action was attempted. The system then uses that result in the next step.
Draw a box labelled 'Tool result' with example snippets like 'pressure=9.8 bar' and 'ticket created: MT-2041'.
05
5. Output or action
The system produces a reply, a record or a next step. In higher-risk cases, a person should review before anything important happens.
Draw a final box labelled 'Answer, alert, or action' with a small side badge: 'human review for important cases'.

A left-to-right step diagram with five boxes connected by arrows. Read from the user request to the final output. Each box shows one stage: request, decide, call tool, receive result, produce answer or action. Small labels under the tool stage show examples such as calculator, database and sensor feed.

Hovering or tapping each step reveals one example input and output for that stage; keyboard focus moves through the steps in order.

Describe this without the diagram

This diagram explains tool use as a five-step process. First, a request or event arrives, such as a user question or a sensor alert. Second, the system checks whether it can answer from its current context or whether it needs an external tool. Third, if needed, it sends a structured request to a tool such as a database, calculator or sensor feed. Fourth, the tool returns data or confirms an action. Fifth, the system uses that result to produce an answer, raise an alert or trigger a further action, ideally with human review for important or risky cases.

With reduced motion: A static five-step horizontal diagram with arrows between the boxes. Each box includes a short example, and the final box includes a note that sensitive or high-impact actions may require human approval.

Some AI systems do more than reply with words. They can call tools such as a calculator, calendar, database, map, sensor feed or ticketing system. A tool can return information, perform a calculation or carry out an action.

What goes in can be a user request, a signal from another system, or both. Based on its instructions and setup, the system selects whether a tool is needed, which tool fits, and what input to send. A tool here means connected software or hardware with a defined job, such as checking stock levels or reading a temperature sensor.

What happens next is usually a loop. The system sends a request to the tool, gets a result back, and uses that result to continue the task. It may call one tool or several tools in sequence. For example, it might read a sensor, compare the reading with a safety threshold, and then open a maintenance ticket.

What comes out depends on the setup. The result might be a written answer, a structured record, an alert, or a real action in another system. Once a system can act beyond its own processing, errors can have practical effects, so permissions, logging and human oversight become important.

Tool use is often confused with function calling, APIs, connectors and computer use. Function calling can return a structured tool request. An API is a standard interface for requests and responses, while a connector links systems. Computer use specifically operates app interfaces through screen actions. Tool use is the broader behaviour of relying on an external capability during a task.

How “A maintenance desk handling a pump alert” maps onto the real thing

In the story	In the AI system
live sensor dashboard	an external tool that provides fresh data
maintenance manual	a reference tool used to compare the data with rules or thresholds
repair ticket system	an action tool that changes another system
worker choosing the next step after each check	the system using tool results to decide the next action

A worked example

With the Friday clearance deadline approaching, a duty officer asks an approved assistant to bring a draft terms of reference into the current format and prepare it for routing.

Starting from: Find the current cleared template, compare it with this draft, show me the proposed changes and do not submit anything without my confirmation.

The model issues a structured request to search the approved document repository for the current template.
The orchestration layer checks the officer's access and returns the template and its repository metadata.
The assistant calls the document comparison function and receives a list of missing headings, formatting differences and draft text that would be moved.
It presents the proposed revision to the duty officer rather than treating the comparison as clearance.
After the officer confirms the changes, the assistant calls the workflow system to save the revised draft and route it to the designated clearing officer.
The workflow system returns the document link and submission status, which the assistant reports back.

Result: The revised draft is stored in the approved system and routed for clearance. The duty officer retains responsibility for the content and explicitly authorises the action.

In a United Nations workplace

At a regional bureau, the duty officer is preparing consultancy terms of reference for clearance before Friday. An approved internal assistant can search the document repository for the current template, compare it with the draft and, after confirmation, upload the revised version to the clearance workflow.

The assistant is using tools rather than relying only on its model. It sends structured requests to the repository and workflow system, receives their responses and uses those observations to decide what to present or do next.

Before you try thisConsultancy drafts may contain procurement-sensitive information. They must not be pasted into or connected to a tool that is not approved for that material. Repository access must follow the officer's permissions, and upload or routing actions require human review and explicit confirmation.

Where you may hear it

During an enterprise-assistant demonstration for a procurement unit
At an ICT governance board review of proposed system integrations
In a country office session on redesigning clearance workflows
During a front-office discussion on permissions for automated actions

Avoid confusion

Often confused with

Common misconceptions

Common misconception: If a system can use tools, it is automatically an autonomous agent.
Correction: Not necessarily. Tool use only means the system can access external functions or services. It may still operate in a tightly limited workflow with fixed steps and strong human approval. Autonomy depends on how much freedom it has to choose goals, steps and actions.
Common misconception: Tool use guarantees accurate answers because the system is connected to real systems.
Correction: Connected tools can improve freshness and precision, but they do not guarantee correctness. The system can choose the wrong tool, send the wrong input, misread the result or act on outdated or poor-quality data. The tool itself can also fail or return incomplete information.
Common misconception: Tool use and function calling mean exactly the same thing.
Correction: Function calling is usually a technical method for packaging a request in a structured form that software can execute. Tool use is the broader behaviour of using external capabilities during a task. A system can use tools through function calling, but the ideas are not identical.
Common misconception: If a tool is available, the system will use it safely.
Correction: Safety depends on permissions, validation, isolation and review. A system may be exposed to misleading instructions from documents or websites, may receive malformed tool outputs, or may have more privileges than it needs. Safe tool use requires design controls, not just access.

Quick check

Which example best shows tool use?

Go deeper

The simple version

It means the system can reach out to other software or devices during a task, instead of only writing text from what it has already seen.

The technical version

Tool use is the pattern where a model-driven system invokes external capabilities during inference or task execution. Those capabilities may include retrieval systems, calculators, databases, enterprise applications, device controls or other services. A common implementation is that the model emits a structured request with a tool name and arguments, an orchestrating layer validates and executes it, and the returned observation is added back into the working context for the next step. This can repeat as an observation-action loop. The important distinction is scope: tool use refers to the behaviour of relying on external operations, while APIs, connectors and function calling are enabling mechanisms. In practice, robust tool use also needs permission scoping, input validation, error handling, logging, rate limits and often sandboxing or human approval for consequential actions.

Reviewed external resources

Primary sourceModel Context Protocol (opens in a new tab)Model Context Protocol
This link gives the official description of the Model Context Protocol and suits technical readers who want to understand one way tools can be connected safely and consistently.
Deeperlink checked 2026-07-31
EncyclopaediaTool use by non-human animals (opens in a new tab)Wikipedia
This link gives a broad background idea of tool use in nature and suits readers who want an intuitive starting point rather than an AI-specific definition.
Intermediatelink checked 2026-07-31
ArticleBuilding effective agents (opens in a new tab)Anthropic
This link gives a practical explanation of agents and how models can use tools, and it suits readers who want a product-oriented overview.
Intermediatelink checked 2026-07-31
VideoVideo explanations: Tool use (opens in a new tab)YouTube search
This search results page gives multiple video explanations of tool use and suits readers who prefer to compare several teaching styles before choosing one.
search results, not one pagelink checked 2026-07-31
DiscussionCommunity discussion: Tool use (opens in a new tab)Reddit search
This search results page gives community discussions and examples about tool use and suits readers who want informal questions, debates and troubleshooting experiences.
search results, not one pagelink checked 2026-07-31

Where this came from

Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.

The one thing to remember

Tool use lets a model request information or actions from external systems and continue from the response. Access controls, validation and human confirmation therefore matter as much as the model's output.