In brief
- A tool connects the model to external data or functionality through a clearly defined interface.
- Function calling is a common form of tool use in which a function name and parameters are passed in a structured format.
- The model proposes a call; permission checks, execution and error handling remain the responsibility of the software.
- Write operations and irreversible actions require limited permissions, validation and often explicit human confirmation.
How does a tool call work?
The application provides the model with a list of permitted tools. Each tool has a name, a description and a schema for its expected parameters. Based on the user request and this context, the model decides whether a tool would help and produces a structured call.
That call is initially only a proposal. The application validates the parameters, checks identity and permission, and executes the tool. Its result is then returned to the model so it can continue the response or propose the next controlled step.
- Step 1
Describe the tool
Define its name, purpose and permitted parameters in a machine-readable format.
- Step 2
Propose a call
The model selects a tool and returns structured arguments.
- Step 3
Validate and execute
The application checks input, permissions and business rules.
- Step 4
Return the result
The tool returns data or an execution status to the application.
- Step 5
Create the response
The model explains the result or proposes another permitted step.
What can tools do?
Tools can provide very different capabilities. Each one should be narrowly described and technically constrained. A tool should receive only the data and actions required for its specific purpose.
- Read: retrieve order status, product data or approved documents
- Calculate: determine prices, deadlines or metrics using reliable logic
- Create: prepare a draft record in a business system
- Change: update a record or trigger a process step
- Communicate: prepare a message or send it after approval
Does tool use automatically make an application an agent?
No. Tool use is first of all a technical mechanism. A fixed workflow can also call exactly one tool: classify a request, retrieve customer data and create a draft response. The sequence and decision points remain predefined in software.
An agent has more freedom to decide which tools to use and in which order to reach a goal. This flexibility also increases the need for constraints, observability and testing.
- Function calling describes the structured hand-off of a requested call.
- A workflow defines most steps and transitions in advance.
- An agent may select the next step within explicit boundaries.
- MCP can describe tools in a standard way and expose them to compatible applications.
Which controls does tool use need in a company?
A syntactically valid tool call is neither necessarily correct nor automatically authorised. The executing application must not rely on the model to correctly state a person's identity, role or intent.
Tool results can also contain incorrect or manipulated content. External text should be treated as untrusted input and must never silently create new permissions or instructions.
| Action type | Typical effect | Required control |
|---|---|---|
| Read | Retrieve status, master data or approved documents. | Derive rights from the signed-in identity, minimise fields and log access to sensitive results. |
| Calculate | Determine a price, deadline or metric with deterministic logic. | Validate parameters and ranges, expose the calculation version and never replace error codes with estimates. |
| Create a draft | Prepare a record or message without making it effective. | Label it as a draft, validate required fields and show a preview before adoption. |
| Change or trigger | Update a record, create an order or start a process step. | Authorise a separate write tool, enforce business rules on the server, require confirmation and make execution idempotent. |
| Communicate externally | Send an email, ticket or message to another party. | Confirm recipient and content visibly, apply volume limits and log delivery with the accountable identity. |
How should a company start with tools?
Begin with a bounded task whose input, result and ownership are understood. A read-only tool with a traceable data source is often a better first step than a broadly privileged agent that can change several systems.
- Step 1
Bound the value
Which specific information or action improves the workflow?
- Step 2
Reduce the interface
Expose only the parameters, data fields and operations that are needed.
- Step 3
Define permissions
Decide on whose behalf the tool acts and which approval is required.
- Step 4
Test failure cases
Cover invalid input, missing data, ambiguity and system outages.
- Step 5
Observe operation
Track tool selection, success rate, corrections, latency and unexpected calls.
Example: explain order status and prepare a change
An internal service application has two separate tools. After successful authentication, the first can read an order status. The second can only prepare an address change as a draft. The model recognises the intent, supplies the required parameters and explains missing information. Before execution, the application displays the old and new address and asks for explicit confirmation. Permission checking and the actual update occur in the business system, not in the language model.
What to remember
Treat the model as the proposer and the application as the control layer. Good tools are narrowly scoped, enforce real user permissions and make sensitive actions visible before execution.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed