Function Calling and Tool Use
Understand how to safely convert AI model outputs into executable tool actions by enforcing strict validation of tool calls and arguments. Learn to implement tool contracts, enforce router constraints like allowlists and error handling, and manage retrieval tools with deterministic, bounded outputs. This lesson helps you build secure and predictable agent frameworks by focusing on validation, versioning, and audit trail management for safe AI tool integration.
When a model output crosses the API boundary and becomes executable action, the risky part is not generation. The risky part is accepting a tool call payload that our system cannot validate deterministically before it touches retrieval, files, or networks.
This lesson stays at that boundary, where assistant_message turns into tool_name plus arguments, and only then turns into tool execution.
The diagram below shows a typical tool definition.
The key machine-checkable pieces are simple and strict. The tool call must name an allowlisted tool, and its arguments must satisfy a schema that rejects missing fields, wrong types, and unexpected keys. If our validator cannot reject bad payloads without interpretation, then the payload is not a safe tool contract.
Rule
If the tool payload cannot be validated deterministically, do not execute the tool.
Tool contracts that survive production
Once the boundary is explicit, the next step is making the boundary enforceable by code. A tool contract pairs an argument schema with behavioral constraints that keep the integration predictable under load and under failure.
The schema defines what the router can validate up front, but production behavior also depends on constraints our code must enforce around the call. Common constraints include idempotency expectations, timeouts, maximum result sizes, and an explicit error shape. The tool can still fail, but it should fail in a way the router can recognize and stop on.
The table below contrasts a structured JSON response with a tool call, since both can look similar in logs while having very different execution risk.
Comparison axis | Structured JSON output | Tool call |
Execution risk | Low | High |
Preconditions and validation | Validate schema only | Validate schema plus state |
Observability and traces | Minimal trace needs | Audit logs required |
Failure mode | Parse or schema error | Unsafe action or timeout |
Production contract | Loose output contract | Versioned API contract |