BOZOS

Validate JSON against a JSON Schema without AI

validateJsonSchema

Read-onlyIdempotent

Validate JSON against a JSON Schema without AI. Use this to check supplied data against a supplied JSON Schema before relying on it. Returns valid, and each failure with the JSON Pointer of the failing value, the schema path, the keyword, and the reason. Nothing is repaired or coerced. Drafts 2020-12 (default), 2019-09, 7, and 4. References resolve only inside the supplied schema; nothing is fetched. The pattern and patternProperties keywords are refused with unsupported_keyword because user-supplied regular expressions can hang a server. Limits: 64 KiB total, 100 errors returned (error_count covers all), 64 nesting levels. Nothing is retained. Valid means this instance satisfies this schema, not that the data is correct. Same as POST https://bozos.si/api/v1/schema-validate.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schema": "<schema>",
      "instance": "<instance>"
    },
    "name": "validateJsonSchema"
  }
}

Input Schema

Name	Required	Description	Default
`draft`	No		2020-12
`schema`	Yes	The JSON Schema object.
`instance`	Yes	Any JSON value to validate.

Output Schema

Name	Required	Description	Default
`draft`	Yes
`valid`	Yes
`errors`	Yes
`safety`	Yes
`validator`	Yes
`error_count`	Yes
`interpretation`	Yes
`schema_version`	Yes
`errors_truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description still adds substantive behavior: no repair or coercion, in-schema-only reference resolution with no fetching, refusal of pattern/patternProperties via unsupported_keyword, size/error/nesting limits, no retention, and a caveat that 'valid' is not 'correct'. This is far beyond what the annotations convey.

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

Conciseness4/5

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

Purpose and return shape are front-loaded, and the caveats (unsupported keywords, limits) follow in a logical order. It is dense and every clause carries information, though the run-on limit/retention paragraph could be split for faster scanning.

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?

An output schema exists, so return values need not be described, yet the description still summarizes them (valid plus failures with JSON Pointer, schema path, keyword, reason). Combined with annotations, limits, draft support and the endpoint equivalence, an agent has everything needed to invoke it correctly.

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

Parameters4/5

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

With 67% schema coverage the baseline is 3; the description earns above that by naming the supported drafts and the 2020-12 default, and by clarifying that references must live inside the supplied schema (directly relevant to what the schema parameter may contain). It does not expand on the instance parameter beyond 'any JSON value', which the schema already states.

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?

States a specific verb and resource ('Validate JSON against a JSON Schema') and adds a scope qualifier ('without AI') that separates it from the inference-flavored siblings. An agent can distinguish it from canonicalizeJson or structuredDiff without opening any schema.

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

Usage Guidelines4/5

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

'Use this to check supplied data against a supplied JSON Schema before relying on it' gives a clear trigger condition and a workflow position (pre-reliance verification). It stops short of naming alternatives such as canonicalizeJson or structuredDiff, so there is no explicit when-not guidance.

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

All BOZOS tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?