Which JSON Schema features are supported?

The common subset used in tool definitions — type (including integer), properties, required, items for arrays, and enum. It validates nested objects and arrays recursively.

Why validate tool results before returning them?

When a tool returns a malformed result, the model receives garbage and often hallucinates a recovery or repeats the call. Catching the mismatch first lets you fix or re-fetch the data instead of corrupting the conversation.

No. Validation is pure local JSON Schema checking in your browser. Nothing is sent anywhere, so it is safe for sensitive tool outputs.

What does the path in an error mean?

It is a dotted/bracketed path to the offending value, like "items[2].price", so you can locate exactly which field in a deep result failed and why.

Tool Response Validator

Why validate tool results

In function calling and tool use, the model asks your code to run a tool, your code returns a result, and that result is fed straight back into the conversation. If the result does not match the schema you advertised — a missing field, a string where a number was promised, an enum value outside the allowed set — the model receives something it was not designed to handle. It may hallucinate a value, apologise and retry the call, or silently produce a wrong answer. Validating the result against your tool’s own schema before returning it closes that gap.

How it works

Paste the tool result JSON and the JSON Schema from your tool definition. The validator parses both and walks the result against the schema, supporting the subset of JSON Schema that tool definitions actually use:

type — including integer as a stricter form of number.
properties — recursively validated for nested objects.
required — flags any required property that is missing.
items — validates every element of an array against the item schema.
enum — confirms a value is one of the allowed options.

If anything is wrong, it lists each violation with the exact dotted/bracketed path (for example forecast[1].unit) and a plain-language reason. If the result is clean, you get a single green confirmation.

Tips

Use the same schema you put in your tool definition (OpenAI parameters, Anthropic input_schema, or your function’s output schema). Validating against the contract the model was told about is what prevents surprises.
Wire this logic into your tool runner: validate the result, and on failure return a structured error to the model (“the tool failed; do not invent a value”) rather than the malformed payload.
A wrong type at a node stops descent into its children, so fix type errors first — a fixed type often clears several downstream messages at once.
Because it runs entirely locally, it is safe for tool outputs containing private or internal data.