Map/AI Engineering and Systems/LLM Application Engineering/LLM Interfaces/Tools and Actions
Concept lesson

Tool Calling

How models propose typed actions while applications retain execution authority and validation.

lessonpublicFreshness: current15 min

Learning outcomes

  • Design tool contracts
  • Validate arguments and authority
  • Close the tool result loop

Mental model

The model proposes a typed action; the application decides whether it is allowed, validates arguments, executes it, and returns a bounded result.

User intent
Model proposes call
Validate and authorize
Execute tool
Return result
Model responds

Theory

A tool contract needs a narrow name, clear semantics, a strict schema, authorization context, idempotency expectations, timeouts, and error behavior. The control loop is request, proposed call, policy check, execution, tool result, and final response. The model never becomes the authorization system.

Alternatives and trade-offs

Use deterministic application code when the mapping is known, retrieval when only information is needed, and a human approval step for consequential or irreversible actions.

Failure modes and misconceptions

Do not expose broad shell or database tools, trust model-supplied identity, hide tool failures, or retry non-idempotent actions without a key.

Knowledge check

Reflect before revealing the guide

Where should authorization occur in a tool-calling workflow?

Decision scenario

A refund assistant can draft a refund request, but account lookup, limit checks, audit logging, and final approval remain enforced by application services.

Relationships

prerequisite

Structured Outputs

Tool calls are schema constrained outputs requiring application validation.

risk-mitigated-by

Security and Privacy for LLM Systems

Tool authority introduces risks controlled through validation and least privilege.

Primary sources