Skip to main content
Glama

IA-QA — 152 QA & Dev Tools for AI Agents

json_schema_validate

Read-onlyIdempotent

Validate a JSON value against a JSON Schema (draft-07 subset). Supports type, required, properties, items, enum, const, pattern, format (email/uri/date/date-time/uuid), minimum/maximum, minLength/maxLength, minItems/maxItems, uniqueItems, additionalProperties, anyOf, allOf, oneOf, not, and local $ref (#/definitions/…, #/$defs/…). A schema using a keyword outside that list (patternProperties, if/then, dependencies, a remote $ref…) is never reported valid: the keyword is named in unevaluated_keywords. Returns all validation errors with dot-notation paths.

Input Schema

NameRequiredDescriptionDefault
valueYesThe JSON value to validate — a JSON string, or the value itself.
schemaYesThe JSON Schema — a JSON string, or the schema object itself.

Output Schema

NameRequiredDescriptionDefault
validNo
errorsNo
error_countNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "schema": {
      +      "$defs": {
      +        "P": {
      +          "properties": {
      +            "n": {
      +              "type": "string"
      +            }
      +          },
      +          "type": "object"
      +        }
      +      },
      +      "properties": {
      +        "p": {
      +          "$ref": "#/$defs/P"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "value": {
      +      "p": {
      +        "n": "five"
      +      }
      +    }
      +  }
      +]
  2. Changed4 schema fields changed
    • changedInput schema / properties / schema / description
      Previous value: -"JSON Schema as a JSON string"New value: +"The JSON Schema — a JSON string, or the schema object itself."
    • changedInput schema / properties / schema / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "object",
      +  "array"
      +]
    • changedInput schema / properties / value / description
      Previous value: -"JSON string to validate"New value: +"The JSON value to validate — a JSON string, or the value itself."
    • changedInput schema / properties / value / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "object",
      +  "array"
      +]
  3. Changed1 schema field changed
    • addedOutput schema / properties
      Added value: +{
      +  "error_count": {
      +    "type": "number"
      +  },
      +  "errors": {
      +    "type": "array"
      +  },
      +  "valid": {
      +    "type": "boolean"
      +  }
      +}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive safety profile, and the description goes well beyond them with a genuinely non-obvious behavior: schemas using unsupported keywords are never reported valid and the offending keyword is surfaced in `unevaluated_keywords`. It also discloses that all errors are returned with dot-notation paths, giving the agent a concrete picture of the response shape.

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?

The purpose is front-loaded in the first sentence and the fail-closed caveat follows logically. The long keyword enumeration is dense but earns its place because it defines the supported subset precisely; it is the one part that could be tightened.

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?

With an output schema present, the description needn't explain return values, yet it still flags the two semantically important response fields (`unevaluated_keywords` and error paths). Combined with 100% parameter coverage and clear annotations, an agent has everything needed to call it correctly and interpret conservative results.

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

Parameters3/5

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

Schema description coverage is 100%, and the two parameter descriptions already explain the 'JSON string or value itself' polymorphism. The description adds nothing further about parameter shapes or edge cases, so the baseline 3 applies.

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 precise verb+resource: validate a JSON value against a JSON Schema, with the dialect version (draft-07 subset) named. It is clearly distinguishable from siblings like json_schema_generate (produces schemas) or openapi_validate (different document type).

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?

The description makes the applicable context clear by enumerating exactly which schema keywords are supported, which implicitly tells the agent when this tool will give a trustworthy answer. It does not, however, explicitly name alternatives such as openapi_validate or json_schema_generate, nor state when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.