Validation · bigonotes

Before running any tool, your code checks the arguments the model provided. The model makes mistakes: wrong types, missing fields, values outside the expected range, or arguments that look plausible but would cause harm if executed.

Three checks#

A tool request passes three checks in order: schema, authorization and sanity; if all pass the tool runs, and any failure goes back to the model as an error message

Check	Question it answers	Example
Schema	Do the arguments have the right type and format?	A date field holds a valid date. A user ID is an integer. A required string is not empty.
Authorization	Is the current user allowed to do this?	Order 1234 belongs to the signed-in user.
Sanity	Does this make sense to do silently?	Deleting 10,000 records at once is stopped.

Schema#

Schema validation is the cheapest check. It catches malformed calls before they reach your systems.

Authorization#

A valid argument is not the same as an allowed one. If the model calls get_order(order_id=1234), the schema check only confirms that 1234 is an integer. Your code must also check that order 1234 belongs to the user who is signed in.

The model has no idea who the current user is or what they are allowed to see. Your code knows, so your code must check. This is the same rule as filtering by permissions in RAG.

Sanity#

Some requests are well formed and authorized but still should not happen silently, for example a bulk delete or a very large refund. Set limits for these and stop the request, or send it to the user to confirm.

When a check fails#

Don't crash. Send the error back to the model as the tool result, with a clear message that says what to fix.

Weak error	Actionable error
`Error`	`date must be YYYY-MM-DD, got "next Friday"`
`Invalid input`	`order 1234 not found for this user`

The model reads the error and can correct its next call, for example by reformatting the date or asking the user which order they mean.

Short line#

Check every tool call before it runs: schema for types and format, authorization for whether this user may do it, and sanity for actions that should not happen silently. When a check fails, return a clear error as the tool result so the model can correct itself.

Key takeaways#

The model can produce wrong types, missing fields, out-of-range values or harmful arguments.
Schema checks catch malformed arguments.
Authorization checks that the signed-in user may do this. The model does not know who the user is.
Sanity checks stop requests like bulk deletes from happening silently.
On failure, send a clear, actionable error back as the tool result instead of crashing.

Core idea#

Check the model's arguments before any tool runs. The model makes mistakes: wrong types, missing fields, out-of-range or harmful values.

Three checks#

Check	Question	Example
Schema	Right type and format?	Valid date, integer ID, non-empty required string
Authorization	Is this user allowed?	Order 1234 belongs to the signed-in user
Sanity	Should this happen silently?	Stop a 10,000-record delete

Key points#

A valid argument is not an allowed one. Check ownership, not only type.
The model does not know who the current user is. Your code does.
On failure, send a clear error back as the tool result.
The model reads the error and fixes its next call.

Pitfalls#

Do not crash on a bad call.
Do not send vague errors like "Invalid input". Say what to fix.

Short line#

Check schema, authorization and sanity before every tool call. Return clear errors so the model can correct itself.