Validation checks data against stated requirements before an agent acts on it. For tool calls, those requirements belong in the tool schema: which arguments are required, what types and formats they accept, and which values are allowed. The application should check inputs before making requests and return clear errors when a call is invalid. section 3.2.3 section 3.3.4
Make invalid calls easy to identify and handle:
- State required arguments explicitly. A reservation needs a restaurant identifier, date and time, and party size; notes are optional. section 3.2.3
- Constrain values where possible. The reservation schema specifies a date-time format and limits party size to integers from 1 to 20. section 3.2.3
- Remove contradictory choices. Replace separate on and off Booleans with one required state whose allowed values are on or off. section 3.2.3
- Keep known identifiers in application context rather than asking the model to regenerate them. A refund call can request only the reason while code supplies the existing order ID. section 3.2.3
Listing 3.7 Improved: Explicit tool definition
{
"name": "reserve_table",
"description": "Create a restaurant table reservation.",
"parameters": {
"type": "object",
"properties": {
"restaurant_id": {
"type": "string",
"description": "Internal ID, e.g., rst_123"
},
"datetime": {
"type": "string",
"format": "date-time",
"description": "ISO-8601 in the user's local time"
},
"party_size": {
"type": "integer",
"minimum": 1,
"maximum": 20
},
"notes": {
"type": "string",
"description": "Allergies, occasion, etc. Optional."
}
},
"required": ["restaurant_id", "datetime", "party_size"],
}
}
The reservation tool definition puts required fields, a date-time format, and a numeric range in one inspectable schema. section 3.2.3
Schema design is not a substitute for runtime checks. A production tool must validate inputs before calling an external service and provide meaningful errors; timeouts, rate limits, and outages need separate handling. Validation also applies after an agent responds: code-based evaluators can check a JSON schema, required fields, length limits, or other precise constraints. Such checks are reproducible, but they cannot reliably judge every quality of natural-language output. section 3.3.4 section 10.3
