How do you stop a model from calling a tool with an argument it invented?
A strict JSON schema defines every tool argument. A call that fails validation gets a structured, actionable error. The schema uses enums for known value sets and validated patterns for IDs. It marks fields required where needed and offers no free-text catch-all. The system never coerces a failed call or passes it to execution.
Also known as schema-validated tools, strict tool schemas, validate-reject-repair
What problem does this solve?#
A tool schema that accepts any string for an ID field never forces the model to justify the source of a value. Such a schema often marks every field optional too. The model can generate a plausible-looking ID from pattern alone, as it completes plausible code. The schema does not distinguish that value from one that came from a prior lookup. Both look identical to the calling code.
The server may also skip checking that a generated value matches something real before it acts. Then a fabricated argument reaches execution unchecked. This gap sits in the schema and the validation layer. A model asked to fill an unconstrained field completes the pattern it learned in training. A plausible-shaped ID is exactly that pattern.
How does it work?#
Every tool argument gets the tightest schema the domain allows. Use a known enum where the value set is small and fixed. Use a validated regex pattern where it is not. The schema marks `required` accurately. Free-text fields hold only free-text content, such as a message body. Identifiers and structured values come from a lookup.
The server validates every call against its schema before it executes anything. It counts validation failure as a distinct category from execution failure. A validation failure returns a structured, specific reason, such as "no matching record for X." The model can act on that reason. A silent no-op or a generic 500 gives the model nothing to use.
Where practical, mutating tools accept only IDs that trace back to an earlier read or lookup call in the same run. The orchestration layer enforces this check. The model has no discretion over it. An argument the model wrote from scratch cannot reach anything that changes state.
What are the moving parts?#
- Constrain every ID and enum field to the tightest schema available
Use an enum or a validated pattern wherever the domain allows it. Avoid a bare free-form string.
- Mark fields required based on actual need
Set required accurately for each field. Avoid the default of optional everywhere.
- Validate every call server-side before execution
Treat validation failure as a category distinct from execution failure.
- Return a structured, specific error on validation failure
Give the model an error it can act on. A silent no-op or a generic error gives it nothing.
- Give the agent a lookup tool for IDs
Let the agent search for a real ID. It then has no need to infer or remember one from context.
- Trace mutating arguments back to a prior read result
Where practical, enforce that a value passed to a mutating tool came from an earlier lookup in the same run.
When does it fit, and when doesn't it?#
Use it when
- Tool calls fail at a rate well above the expected legitimate user error, especially with plausible-shaped IDs that do not exist
- Any tool in the reach of the agent can mutate state, such as write or delete, and not only read
- The agent must reference existing records by ID across multiple turns
- The team onboards a new tool and wants its contract to fail safely from day one, before any incident
Don't use it when
- The tool is read-only, low-stakes, and idempotent, as with a public search. A bad argument there returns an empty result with no downstream harm
- The value space is open-ended free text, such as a user message or a search query. An enum or pattern there breaks the purpose of the tool
- The caller already validated the value one layer up, and a second check adds only latency. Check whether the guarantee already holds before you add a redundant layer
What does it cost?#
The server rejects fabricated IDs before they reach anything real
Tighter schemas need domain modeling work up front. The team must know the actual enum or pattern
Validation failures become a measured, distinct metric and stop hiding inside a generic error rate
The server rejects more calls in the short term, because it also catches legitimate edge cases the schema missed. Expect a tuning period
A model with a lookup tool no longer needs to recall or infer IDs
The lookup adds one tool call to every task that references an existing record. That call adds a step and some latency
Tracing mutating arguments back to a prior read call closes off invented IDs at the orchestration layer as well as the schema layer
The team must build and maintain that tracing in the harness. A schema alone cannot enforce it
How do you know it's working?#
- Tool call rejection rate, split into validation failures and execution failures
- Rate of rejected calls where the invalid argument appears in no prior tool result the agent received
- HallucinationA hallucination is a confident, fluent output that is factually wrong or unsupported. rate on free-form ID fields compared directly with the rate on enum-constrained and pattern-constrained ID fields
- Share of mutating-tool calls whose argument traces to a prior read-tool result
What failure modes does this prevent?#
Sources
- JSON Schema - JSON Schema, Draft 2020-12
The schema specification a tool description must satisfy under our rule bank. Retrieved 2026-08-24.
- Model Context Protocol - MCP Specification: Tools (2026-07-28)
The specification text our tool-design and catalogue rules are checked against. Retrieved 2026-08-24.
A Ship Audit checks which of these patterns your system needs. It ranks them by what is most likely to break first.