What a good schema does
It names each argument, states its type, marks what is required, and describes what the value means in business terms. The description matters as much as the type: an assistant choosing between two similar tools reads the text, not your intentions.
Loose schemas — a free-form object, an untyped identifier — invite the model to invent shapes that parse but mean nothing.
What the server still has to do
- Re-validate types and required fields, rejecting unknown properties.
- Confirm every referenced record exists and belongs to the caller's organization.
- Apply business rules the schema cannot express, such as state transitions.
- Return a typed, readable error instead of a generic internal failure.
Never trust a model-supplied identifier
Language models produce plausible identifiers. A call that names a record from a different tenant must fail on existence-and-ownership verification before any handler logic runs. This check is not an optimization; it is the difference between a scoped consumer and a cross-tenant read.