Treating an AI model as an untrusted API caller, subject to the same strict input validation any external API client would receive, is the right mental model for schema validation on tool calls. The model's generated tool call functions exactly like a request from a client whose behavior you don't fully control, and validating it accordingly catches malformed or unexpected requests before they reach the tool's actual implementation logic.
Define an explicit schema for every tool parameter
For every tool a model can call, define an explicit schema for its parameters: required fields, data types, format constraints like string length limits, allowed character sets, numeric ranges. This schema should exist as a formal, testable definition, not some implicit understanding buried in the tool's implementation code, since a formal schema can be validated against directly and reviewed independently of the tool's broader implementation logic.
Reject unexpected or extra fields rather than silently ignoring them
Configure schema validation to reject tool calls carrying fields not defined in the expected schema, rather than silently ignoring unexpected fields and processing only the recognized ones. An unexpected field in a generated tool call can mean a model producing output based on manipulated context that included information about fields it shouldn't even know exist, or a bug in how the tool call gets generated, and silently ignoring rather than rejecting it throws away a useful signal that something unexpected happened.
Use strict type checking, not permissive coercion
Validate parameter types strictly, rejecting a string where a number was expected rather than trying to coerce it automatically. Permissive type coercion can mask a model producing subtly incorrect output, and it introduces its own edge cases, a string that coerces to an unexpected numeric value, that strict validation avoids entirely by rejecting the mismatch outright and making the calling code handle the rejection explicitly.
Bound numeric and string values explicitly, not just check their type
Beyond type checking, validate that numeric values fall within an explicitly defined acceptable range for that specific parameter, and string values fall within expected length and character constraints. A transaction amount parameter, say, should have an explicit maximum value defined right in the schema itself, not rely solely on a separate business rule check layered on afterward, since defining the bound at the schema level catches an obviously invalid value earlier and more simply.
Validate enum-like parameters against an explicit allowed list
For parameters representing a category or status value, validate against an explicit list of allowed values instead of accepting any string and trusting downstream logic to handle unexpected values gracefully. That stops a model from generating a category value nobody anticipated, which could otherwise trigger unexpected code paths in logic that assumed only the documented set of values would ever show up.
Version tool schemas alongside tool implementation changes
When a tool's implementation changes in a way that affects its expected parameters, update the schema at the same time and version them together, rather than letting the schema drift out of sync with what the implementation actually expects. A stale schema validating against an outdated parameter set can either incorrectly reject valid calls matching the tool's current actual interface, or worse, fail to catch calls invalid against the tool's current, changed interface.
Test schema validation with both valid and deliberately invalid inputs
Following unit testing guidance covered elsewhere, test each tool's schema validation with a representative set of valid inputs that should pass, and a set of deliberately invalid inputs, wrong types, out-of-range values, extra fields, missing required fields, confirming each specific invalid case gets correctly rejected. This test coverage confirms the schema definition itself is both correctly permissive for legitimate use and correctly restrictive against the specific invalid patterns it's meant to catch.
Treat schema validation as necessary but not sufficient
Schema validation confirms a tool call is well-formed. It doesn't confirm the call is authorized or within business rule limits, which are separate validation concerns covered in output validation guidance. A tool call can pass schema validation completely while still representing an unauthorized or policy-violating request, so schema validation should be understood explicitly as the first layer in a validation pipeline, not the whole validation story on its own.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, applies authorization and business rule checks to tool calls that have already passed your application's own schema validation, functioning as a distinct, later layer in the overall validation pipeline.
Defining and maintaining the specific schema for each tool's parameters remains application-level implementation work tied directly to each tool's own interface and requirements.
A short checklist
- Define an explicit, formal schema for every tool's parameters.
- Reject unexpected or extra fields rather than silently ignoring them.
- Use strict type checking without permissive automatic coercion.
- Bound numeric and string values explicitly within the schema itself.
- Validate enum-like parameters against an explicit allowed list.
- Version tool schemas alongside implementation changes.
- Test schema validation with both valid and deliberately invalid inputs.
- Treat schema validation as the first layer, not the complete
validation pipeline.
Schema validation for AI-generated tool calls works best when the model is treated as an untrusted API caller from the start, with strict, explicit, well-tested validation that rejects anything outside a clearly defined expected structure rather than attempting to permissively accommodate whatever the model happens to generate.