Function Calling and Tool Use
Explore how to safely handle function calls and tool integrations in AI systems by enforcing strict validation, schema contracts, and runtime constraints. Understand how to validate tool arguments, enforce allowlists, and manage retries to maintain predictable and secure tool usage in production environments.
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 ...