bantamkit

Overview Schema Source Related Servers Discussions Admin

Validate JSON against a schema

validate_json

Read-only

Checks model-produced JSON against a JSON Schema and returns where it fails with the offending value quoted, so you can retry before acting. Accepts bare values or JSON in prose.

Instructions

Validate candidate output text against a JSON Schema and say what is wrong. Answers {valid, feedback}: when invalid, hand feedback back to the model and retry — it says where the document fails and quotes the offending value, clipped to 200 characters; when valid, feedback is null. Use it on any JSON a model produced before acting on it; for a shift-work checkpoint call shiftwork_status or shiftwork_clock_in instead, which validate against the shipped checkpoint schema themselves. output may be a bare JSON value; otherwise the first fenced code block, else the first object or array in the text, is what gets validated. $schema selects draft-04, draft-06, draft-07, 2019-09 or 2020-12 (the default). $ref resolves only inside the one schema given (#, #/..., #name): a remote reference or an embedded $id is refused with its own sentence, never fetched. pattern is Python re syntax without inline flags, look-behind, backreferences, atomic, possessive or conditional groups or \N{...}, and all of a document's patterns share 500 ms: past that the answer is one refusal sentence naming the pattern that ran out, not a partial validation. Reads nothing but its two arguments and writes nothing.

Input Schema

Name	Required	Description	Default
`output`	Yes	The text to validate, as the model returned it: a JSON value, or prose holding a fenced code block or a JSON object/array.
`schema`	Yes	The JSON Schema object (draft-04 through 2020-12) the output must satisfy; `$ref` may only point inside it.

Output Schema

Name	Required	Description	Default
`valid`	Yes	True when the extracted JSON satisfies the schema.
`feedback`	Yes	null when valid; otherwise where the document fails and the clipped offending value, to hand back to the model.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.36.2Oct 23, 2026

addedInput schema / properties / output / description

Added value: +"The text to validate, as the model returned it: a JSON value, or prose holding a fenced code block or a JSON object/array."

addedInput schema / properties / schema / description

Added value: +"The JSON Schema object (draft-04 through 2020-12) the output must satisfy; `$ref` may only point inside it."

addedOutput schema / properties

Added value: +{
+  "feedback": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "description": "null when valid; otherwise where the document fails and the clipped offending value, to hand back to the model."
+  },
+  "valid": {
+    "description": "True when the extracted JSON satisfies the schema.",
+    "type": "boolean"
+  }
+}

addedOutput schema / required

Added value: +[
+  "valid",
+  "feedback"
+]

First observedv0.36.0Oct 20, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only and closed-world; the description goes far beyond them with the retry contract (hand `feedback` back, retry), feedback truncation at 200 characters, null-on-success, $ref confinement with remote refs refused and never fetched, and a 500 ms shared regex budget that yields a refusal rather than partial results. The closing "reads nothing but its two arguments and writes nothing" reinforces the annotation rather than contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense single paragraph but front-loaded: purpose and return shape come first, then routing, then argument conventions, then edge cases. Every sentence carries information an agent needs to call or interpret the tool; nothing is decorative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-arg validator with an output schema and closed-world annotations, the description covers the retry loop, the failure modes (refused remote refs, regex timeout), and the input acceptance rules. No gap remains that would cause a misinvocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds real semantics the schema lacks: the extraction order for `output` (bare JSON value, else first fenced block, else first object/array), which drafts `$schema` accepts and that 2020-12 is the default, and the allowed `$ref` forms. These change how an agent must shape its arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("Validate candidate output text against a JSON Schema") and immediately states the answer shape {valid, feedback}. It also distinguishes itself from the sibling checkpoint tools, so an agent can route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ("Use it on any JSON a model produced before acting on it") and an explicit exclusion with named alternatives ("for a shift-work checkpoint call shiftwork_status or shiftwork_clock_in instead"). Both the when and the when-not are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server