How to Validate LLM Tool Calls with JSON Schema Before Execution

Quick answer

Define an object schema for each tool’s arguments. Specify the expected properties, their types, which fields are required, and any value constraints the executor relies on.

When a tool call arrives, route it through an application-owned gate before dispatch. The gate should match the call to its tool schema and validate the argument object; a JSON Schema validator checks a JSON instance against a schema and returns a validation result.

If the arguments fail validation, stop the call from reaching the executor and send the agent a structured error that identifies what needs correction. If they pass, dispatch the validated arguments.

This error-handling pattern is an implementation recommendation; the cited references establish schema definition and validation, not a specific error format or retry mechanism.

Keep provider-side strict mode separate from this gate. It can enforce supported schema rules, but only a subset of JSON Schema is supported, so it is not a substitute for validating arguments in your application before execution.

Step-by-step guide

Prerequisites

To build a robust tool-call validation layer, you need a solid grasp of JSON and the basics of JSON Schema. You should understand how to define object properties, types, and required fields for a simple tool input, as this is the contract your validator will enforce.

You will also need a programming environment with a JSON Schema validator library installed, such as ajv for JavaScript or jsonschema for Python. These libraries perform the actual validation checks against your schemas, saving you from writing custom parsing logic.

Finally, having a basic LLM integration that returns tool calls as structured JSON is essential. This lets you intercept the raw arguments before they reach your actual tool functions, which is where the validation gate will live.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Define the tool argument schema

Start by writing a JSON Schema object that describes exactly what each tool expects to receive. I treat this schema as the single source of truth for that tool's input contract, so every field the executor depends on appears here, including types and constraints.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Intercept tool calls before execution

At the point where your LLM integration receives a response, route every proposed tool call through an application-owned dispatcher instead of invoking the named function directly. The dispatcher should resolve the requested tool, pair its argument payload with that tool’s schema, and pass both to the validation layer before any executor can run.

Keep the provider adapter and tool executor on opposite sides of this gate: the adapter hands off calls, while only the gate can authorize dispatch. If a call names an unknown tool or its arguments cannot be decoded, stop the route rather than falling through to a default function.

Provider-side strict mode can help enforce supported schema rules, but it covers only a subset of JSON Schema. Keep application-side validation in this path even when strict mode is enabled.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Validate arguments against the schema

Pass the decoded argument object and the schema for the requested tool to your JSON Schema validator. It checks the JSON instance against the schema and returns a validation result; keep the reported violations so you can explain what needs correcting.

result = validate(tool_schema, arguments)
if result is invalid:
    collect(result.violations)
    stop this call from reaching the executor

Treat this as pseudocode: use the result format provided by your chosen validator. When available, retain each violation’s field location and reason, rather than returning only “invalid.”

That gives the next error-handling step useful detail to send back to the agent.

Check that the validator is using the same schema you defined for the tool. A mismatch can make the gate enforce a different contract than the one you intended.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Return structured errors to the agent

When validation fails, stop the dispatch and return a structured error payload instead of executing anything. I recommend including an error code, field path, and message that tells the agent what to correct.

Send this payload back as a tool result so the agent can retry with corrected arguments. Keep it machine-readable and avoid dumping schema internals unless they help the model fix the call.

To verify, submit a malformed tool call and confirm the error contains a code, field, and message. Then submit a valid call and confirm the tool executes normally.

If the agent cannot interpret the payload, simplify the field names and retry. A vague “invalid arguments” message forces the model to guess.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Proceed only on success

When validation passes, dispatch the tool with the validated arguments. Only the gate should reach this point, so the executor can treat incoming payloads as already checked.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Verification

Run two tests: one valid payload and one malformed one. Send a valid tool call payload through the intercept layer.

The gate validates the arguments and dispatches normally. Confirm the executor runs.

Send a malformed payload, such as a missing required field or wrong type. The gate blocks execution and returns a structured error with code, field path, and message.

Verify it reaches the agent as a tool result. If valid calls are blocked, confirm your validator loads the same schema as step 1.

If invalid calls pass, ensure the gate runs before the executor and violations halt dispatch. Then re-run both tests again.

Log each result to separate schema bugs from validator misconfiguration before changing code.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Troubleshooting

If strict mode rejects a schema or behaves differently than your application validator, check whether it uses features outside the provider’s supported JSON Schema subset. Keep the application-side gate in place; provider strict mode does not replace validation before dispatch.

If valid arguments are unexpectedly blocked, compare the schema registered with the tool against the one loaded by the validator. They should describe the same fields, types, and constraints; correct the mismatch, then rerun your valid and invalid payload checks.

If the agent cannot act on a validation error, make the response concise and consistent: include a stable error code, the field path, and a specific correction message. Return it as a tool result, then check that the agent can use it to form corrected arguments rather than guessing from a vague “invalid arguments” message.

Sources: OpenAI API Reference: Chat Completions; JSON Schema: Getting Started Step by Step.

Next steps

The key design choice is to make validation a mandatory boundary, not an optional check inside the tool. Define the input contract once, ensure the validator uses that schema, and allow dispatch only after the arguments pass.

To verify the gate, send one valid payload and one malformed payload through it. Confirm that the valid call proceeds and the invalid one is blocked; return an actionable validation error to the agent so it can correct its arguments.

If you use provider strict mode, treat it as an additional aid rather than the final safeguard because its schema support is limited. Your next step is to test the gate in your own integration with the schemas and validator your application actually uses.