Tools MCP and External Integration
Tool Schema Validation — Stack
Tool schema validation › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Two things are being chosen and they are often confused: the library that checks a payload, and the mechanism — if any — that constrains the payload at generation time so it rarely needs checking.
- Dialect and keyword coverage. Which draft the validator implements, and whether the keywords you intend to rely on are actually supported rather than parsed and ignored.
- Error quality. Whether a failure yields the offending path, the violated constraint, and the received value in a form that can be turned into a sentence a model can act on. Most validators are tuned for developers reading a stack trace.
- Performance at call frequency. Whether schemas compile once and reuse, since validation runs on every invocation in the hot path of a user-visible turn.
- Format assertion. Whether semantic formats — dates, durations, identifiers, addresses — are enforced or treated as annotations. The default in most implementations is annotation.
- Generation-time enforcement. Whether the stack can constrain the model's output so that invalid arguments are not produced at all, and what proportion of your schema it can express as a constraint.
- Round-tripping with the declaration source. Whether the same document drives the model's declaration, the validator, and the implementation's types, or whether three artefacts must be kept in agreement by hand.
- Evolution tooling. Whether compatibility between two versions of a declaration can be checked mechanically, so a tightened constraint is caught before release.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Standalone JSON Schema validators (ajv, jsonschema, python-jsonschema, everit and similar) | Validating against the declaration exactly as the model was shown it | Format assertion is usually off by default; error objects need substantial translation before a model can use them |
| Type-first libraries that emit schemas (Pydantic, Zod, TypeBox, attrs-based stacks) | Keeping one definition for the implementation types, the declaration, and the check | The emitted schema includes constructs model runtimes handle poorly; review the generated output rather than trusting it |
| Provider strict-mode structured output | Eliminating most malformed arguments before they are emitted | The enforceable subset is narrower than the schema language; unsupported constructs are dropped or rejected at registration |
| Grammar-constrained decoding (Outlines, llguidance, LM Format Enforcer, GBNF grammars) | Self-hosted models where conformance must be guaranteed rather than likely | Needs logit access; grammar compilation cost per distinct schema; expressiveness below full JSON Schema |
| Protocol buffer or Avro schemas with a compatibility-checking registry | Organisations that already run schema evolution discipline on messages | Not the format model runtimes accept; you maintain a translation into the declaration shape |
| Hand-written argument checks in the tool implementation | Business invariants that no schema language expresses | Not a substitute for a declaration; it cannot shape what the model emits, only reject it afterwards |