Mental model
The model proposes a typed action; the application decides whether it is allowed, validates arguments, executes it, and returns a bounded result.
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
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.
Learning outcomes
- Explain Tool Calling as a system mechanism rather than a slogan.
- Compare its alternatives, trade-offs, and production failure modes.
- Apply the concept to a decision and identify evidence that would validate it.
Trade-offs
Using Tool Calling can improve capability or control, but it also introduces cost, latency, complexity, and failure modes that must be measured against an explicit objective.