What is Tool Use?
Tool Use is the system pattern in which a model selects or proposes an external capability, trusted runtime code validates and executes the request, and a bounded result is returned for the next model turn or application outcome. A model-generated call is a proposal, not proof of permission, execution, success, or truth.
Quick Facts
| Full Name | LLM and AI Agent Tool Use |
|---|---|
| Specification | Official Specification |
How It Works
Tool Use extends an LLM workflow with capabilities such as retrieval, calculation, code execution, database reads, ticket updates, or browser control. A typical client-tool loop has five boundaries: expose a reviewed tool catalog; receive a model proposal naming a tool and arguments; validate and authorize it against trusted identity and current resource state; execute through a bounded adapter; then normalize the result before it re-enters model context. The loop may continue, stop, ask for input, or escalate.
Function Calling is one model-facing representation for proposals. Providers use different request fields, call identifiers, parallel-call rules, result messages, strict-schema behavior, built-in tools, and server-executed tools. MCP standardizes discovery and invocation between Clients and Servers, including schemas and structured results, but it does not replace provider adapters or application authorization. Computer Use is another tool family that acts through a user interface rather than a narrow business API and therefore has a different reliability and containment profile.
Schema-valid arguments establish shape, not authority or business validity. Resolve actor, tenant, role, resource ownership, policy version, approval, prices, quotas, and current state from trusted systems rather than model fields. Minimize the exposed catalog and downstream credentials. Prefer narrow operations such as create_refund_proposal over open-ended shell, SQL, URL-fetch, or administrative tools. Consequential calls need a preview or approval bound to the exact tool version, resource, argument digest, policy, approver, and expiry.
Writes need stable operation keys and an effect journal. A timeout after dispatch can mean the effect committed even though the runtime did not receive a response; mark it outcome_unknown, reconcile against the downstream system, and never blindly retry. Parallel calls are safe only when they are independent or idempotent. Cancellation, step, wall-clock, token, cost, result-size, and repetition budgets should terminate loops deterministically.
Tool definitions and results are untrusted context. A third-party description can poison tool selection, while a result can contain indirect prompt injection, secrets, oversized content, malformed structured data, or instructions that try to change policy. Pin reviewed definitions, validate output schemas, redact and size-limit results, separate data from instructions, and never let returned text expand privileges or approve another effect.
Evaluate the full trajectory, not only the final answer. Test correct tool selection, unnecessary calls, argument validity, authorization denial, no-op and abstention cases, output handling, dependency failure, duplicate delivery, post-dispatch timeout, cancellation, budget exhaustion, and final source-system outcome. Record model proposal, policy decision, operation key, effect status, sanitized result digest, latency, cost, and release identity without storing hidden chain-of-thought or unnecessary private payloads.
Key Characteristics
- Proposal-execution separation: the model requests; trusted code authorizes and executes
- Provider and protocol diversity: Function Calling, built-in tools, server tools, MCP, and Computer Use have distinct contracts
- Complete mediation: identity, tenant, resource, policy, approval, and business state are checked for every call
- Effect safety: operation keys, idempotency, outcome-unknown reconciliation, cancellation, and budgets bound side effects
- Untrusted context in both directions: definitions and results require provenance, validation, redaction, and size limits
- Trajectory evaluation: selection, arguments, policy, effects, results, stopping, cost, and user outcome are tested together
Common Use Cases
- Retrieving current or private information through authorized read-only APIs
- Running deterministic calculation, validation, compilation, or test tools
- Preparing a consequential action for human review without committing it
- Executing bounded business operations with user-context authorization and idempotency
- Discovering and invoking approved MCP tools through a controlled host
- Using isolated browser, desktop, shell, or code environments when no narrower interface exists
Example
Loading code...Frequently Asked Questions
Does an LLM execute a tool when it returns a tool call?
Not necessarily. For client tools, the model returns a proposal that application code must parse, authorize, execute, and report back. Some providers also offer server-executed built-in tools, but their execution, permissions, data flow, and result contract remain provider-specific.
How does Tool Use differ from Function Calling?
Tool Use is the complete capability and control loop. Function Calling is one structured model interface for proposing a call. Tool Use also covers discovery, runtime execution, authorization, results, repeated steps, state, side effects, observation, and evaluation.
Does a JSON Schema make a tool call safe?
No. A schema can constrain syntax and types, but cannot prove identity, ownership, consent, current business state, or permission. Trusted runtime and downstream services must independently validate and authorize every call.
Can failed tool calls be retried automatically?
Only when the failure is known to be retryable and the operation is read-only or safely idempotent. A timeout after dispatch may hide a committed write; mark the result unknown, reconcile it, and reuse the same operation key before considering another attempt.
How should Tool Use be evaluated?
Use representative and adversarial trajectories that score selection, unnecessary calls, arguments, authorization, side effects, result handling, stopping, latency, cost, and the final environment outcome. A fluent final answer cannot compensate for an unauthorized or duplicate action.