Tool calling is an application pattern in which a model selects or proposes a named capability and supplies structured arguments, after which the host application decides whether and how to execute it. A tool may retrieve data, perform a calculation, create a draft or change an external system. The model’s output is a request, not proof that the operation is authorized, valid or complete. The application must validate the schema, authenticate the user and service, enforce policy, manage state, execute through a trusted integration and return an observed result to the model or user.
A prototype can make tool use look like a simple loop: describe functions, parse a call and send back the result. Production introduces identity, permissions, stale state, duplicate execution, partial failure, adversarial instructions and irreversible consequences. A syntactically valid argument can refer to the wrong customer or amount. A timeout can hide a successful payment, and a retry can repeat it. Tool output can contain untrusted content that redirects the model. If the model also decides authorization and interprets success, one probabilistic component controls the entire transaction.
Design tools as narrow, typed application contracts around business capabilities. Keep identity, authorization, limits and high-consequence approvals outside the model. Split read, draft, preview and commit operations where that makes effects legible. Use idempotency and current-state checks for mutations, minimize credentials, and return structured outcome evidence. The model may help choose and explain a tool, but deterministic services decide whether an exact effect may occur. Test the whole path, including denial, cancellation, timeout, retry, compensation and malicious tool output.
Call lifecycle
Selection, authorization, execution and observation are separate states
A model can select a tool because its name, description and schema appear relevant, then construct arguments from the conversation. The host should parse and validate that proposal before execution. Authentication establishes an identity; authorization decides whether it may act; business validation checks current conditions. Only the integration performs the operation. A final observation then reports success, failure, created identifiers or changed state. Conflating these stages produces false completion and weak auditability.
The Model Context Protocol specification defines tools with identifiers, descriptions and input schemas and provides a call request and result shape. A protocol can standardize discovery and messages, but it cannot decide an organization’s permission model or risk appetite. Treat server annotations and descriptive metadata as information that must come from a trusted source. Apply the same security review whether tools arrive through MCP, a provider-specific function interface or internal code.
| State | Responsible layer | Evidence |
|---|---|---|
| Proposed | Model and host parser | Tool name and arguments |
| Authorized | Identity and policy service | Decision and scope |
| Validated | Business application | Current state and invariants |
| Executed | Trusted integration | Provider response or transaction |
| Observed | Application and user interface | Verified outcome |
Effect safety
Design the API so a plausible model mistake is containable
Narrow tools reduce ambiguity. A read tool should not mutate as a side effect. A draft tool can prepare content without sending it. A preview can resolve current price, recipient and impact immediately before approval. A commit tool can require an immutable preview token and an idempotency key. These boundaries improve both human understanding and automated testing. They also make denial a normal result rather than a conversational failure the model tries to work around.
Risk management should cover foreseeable misuse and operational change across the system lifecycle, consistent with the NIST AI RMF approach. Build an evaluation set that includes prompt injection, unauthorized records, malformed arguments, stale previews, provider timeouts and contradictory tool results. Redact secrets, minimize retained payloads and alert on abnormal patterns. For irreversible or regulated effects, use qualified domain and security review rather than relying on general model behavior.
- Keep tools narrow and typed.
- Authorize every effect against current identity.
- Separate preview from consequential commit.
- Make retries idempotent where possible.
- Report observed outcome, not model intention.
What good looks like
Useful outcomes from AI tool calling
- Each tool has a bounded purpose, explicit input schema and defined result.
- User and service permissions are checked at execution time.
- High-consequence actions expose preview and approval where appropriate.
- Retries cannot silently duplicate a protected business effect.
- The system distinguishes requested, accepted, completed and failed states.
- Logs support investigation without exposing secrets or unnecessary private content.
Operating model
How to run the work
- 01
Model the business capability
Name the actor, object, allowed operation, preconditions, effect and failure consequences. Decide whether the capability should be read-only, draft-producing, reversible or commit-level before defining model-facing wording.
- 02
Specify the typed contract
Create concise tool names, descriptions, constrained input schemas and structured outputs. Make identifiers explicit, reject unknown fields and distinguish business validation errors from transport or provider failures.
- 03
Enforce execution controls
Authenticate current identity, authorize the exact object and action, validate state, apply rate and value limits, request approval where needed and use idempotency for retried mutations. Keep credentials scoped to the service.
- 04
Observe and evaluate effects
Return the actual result, not an optimistic assumption. Record correlation, decision and outcome states. Test normal, denied, ambiguous, adversarial and partial-failure cases and verify compensation or escalation.
Evaluation
Questions that change the decision
- Should the model retrieve, draft, preview or commit this operation?
- Which identity and policy authorize the exact object and action?
- What must be validated deterministically beyond the input schema?
- Which effect requires explicit human confirmation at current state?
- How will retries, timeouts and duplicate requests be resolved?
- What structured evidence tells the caller what actually happened?
Failure modes
Where teams lose control
A broad tool allows more action than its description suggests.
The model invents an identifier that passes syntax but targets the wrong record.
Untrusted tool output injects instructions into the next model step.
A timeout is retried after the external effect already succeeded.
Approval is collected before a material state or amount changes.
The assistant claims completion from the request rather than the observed result.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- tool requests accepted, denied, clarified and abandoned by reason
- schema, authorization and business-rule validation failures
- duplicate effects prevented through idempotency
- requested operations with verified completion evidence
- human approval and cancellation rate by consequence tier
- time to detect, contain and resolve partial execution
Questions
Common questions
What is tool calling in an AI application?
It is a pattern where a model proposes a named operation with structured arguments and the host application validates, authorizes and executes it. Tools can retrieve information or create external effects.
Is LLM function calling the same as executing a function?
No. The model normally produces a structured request. Application code decides whether it is valid and permitted, performs the operation and returns the observed result. Model output alone should not create authority.
How can tool calls be made safer?
Use narrow schemas, least-privilege credentials, current-state authorization, deterministic business checks, preview and approval for high consequences, idempotency, structured results, monitoring and tested recovery.
Does MCP make tool calling secure automatically?
No. MCP can standardize tool discovery and calls, but the application still owns trust, authentication, authorization, validation, approvals, secret handling, execution and audit controls.
Sources
Primary references
- Model Context Protocol: Tools Model Context Protocol
- Artificial Intelligence Risk Management Framework 1.0 National Institute of Standards and Technology
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zeke
AI product engineering for moving a software brief into a reliable production product.
Product leaders, founders and engineering teams. Start with the workflow, constraints and evidence you already have.
See Zeke→