Tool Validation
Models emit wrong types, extra keys, and prompt-injected strings. The handler must not trust them.
Airport security before the gate — ticket looks real, still scan it.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
Before the API
Scroll inside the frame to explore · use + / − to zoom up to 200%
Parse, schema-check, then policy-check, then call.
Key Takeaways
- 1.Validate arguments before the handler runs. Schema first, then business rules (ids exist, amounts in range)
- 2.Reject with a short error the model can fix. Never pass raw model JSON straight into SQL or a shell.
- 3.Validate against JSON Schema. Then apply policy (tenant, max amount).
- 4.Return a crisp error string. Do not interpolate args into SQL or bash.
Learn elsewhere
- →Structured Outputs
- →SQL Tool
Real Example
Scenario
refund amount: -5 and user_id: '1 OR 1=1'. Schema fails the amount. Policy would have failed the id. Handler never runs.
What you would do
In Tool Calling & Function Calling, apply Tool Validation to this scenario: refund amount: -5 and user_id: '1 OR 1=1'. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Schema then policyNo raw SQL/shellShort errors for retryNever trust model JSON
Cheat Sheet
Quick recap
quick ref- •Scan before the gate
- •Types + business rules
- •Crisp errors
- •No interpolation
Common Mistakes
- ✕json.loads and go
- ✕Putting args into f-string SQL
- ✕Returning a stack trace to the model