Skip to main content
Glama

Lordevo Shop (x402 website checks)

JSON Schema validator: check JSON (or LLM output) against a schema ($0.002/call)

json_validate
Read-onlyIdempotent

$0.002 per call (x402, USDC on Base; free trial: add "trial": true or use try_free). [Data utilities] JSON Schema validator. Validates a JSON document against a JSON Schema (draft-07, 2019-09 or 2020-12, formats included) and returns valid true/false with every error as a JSON Pointer, keyword and message. Input: json and schema (POST for large documents). Limits: 1 MB JSON, 200 KB schema, 100 errors listed; remote $ref is not fetched. Offline.

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": {
      "json": "<json>",
      "schema": "<schema>"
    },
    "name": "json_validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsonYesJSON text to validate, up to 1 MB, e.g. {"name":"Ada","age":36} (a JSON value is also accepted in a POST body or MCP arguments)
trialNoOptional. true = free if a trial call is left (3 per IP per UTC day), else the payment terms.
schemaYesJSON Schema (draft-07, 2019-09 or 2020-12) as JSON text or object, up to 200 KB

Output Schema

NameRequiredDescriptionDefault
toolNo
cacheNo
draftNo
validNo
_trialNoPresent when the call was a free trial call.
errorsNo
providerNo
price_usdNo
error_countNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / trial / description
      Previous value: -"Optional. true = answer free if a trial call is left (3 per IP per UTC day); otherwise you get the payment terms."New value: +"Optional. true = free if a trial call is left (3 per IP per UTC day), else the payment terms."
  2. Changed1 schema field changed
    • changedInput schema / properties / json / description
      Previous value: -"JSON text, up to 1 MB (a JSON value is also accepted in a POST body or MCP arguments)"New value: +"JSON text to validate, up to 1 MB, e.g. {\"name\":\"Ada\",\"age\":36} (a JSON value is also accepted in a POST body or MCP arguments)"
  3. Changed2 schema fields changed
    • addedInput schema / properties / trial
      Added value: +{
      +  "description": "Optional. true = answer free if a trial call is left (3 per IP per UTC day); otherwise you get the payment terms.",
      +  "type": "boolean"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "anyOf": [
      +    {
      +      "required": [
      +        "tool",
      +        "valid",
      +        "errors"
      +      ]
      +    },
      +    {
      +      "properties": {
      +        "accepts": {
      +          "type": "array"
      +        },
      +        "error": {
      +          "type": "string"
      +        },
      +        "resource": {
      +          "type": "object"
      +        },
      +        "x402Version": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "x402Version",
      +        "accepts"
      +      ]
      +    },
      +    {
      +      "properties": {
      +        "charged": {
      +          "type": "boolean"
      +        },
      +        "error": {
      +          "type": "string"
      +        },
      +        "message": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "error"
      +      ]
      +    }
      +  ],
      +  "properties": {
      +    "_trial": {
      +      "description": "Present when the call was a free trial call.",
      +      "type": "object"
      +    },
      +    "cache": {
      +      "type": "object"
      +    },
      +    "draft": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "error_count": {
      +      "type": "integer"
      +    },
      +    "errors": {
      +      "items": {
      +        "properties": {
      +          "keyword": {
      +            "type": "string"
      +          },
      +          "message": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "pointer": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "price_usd": {
      +      "type": "number"
      +    },
      +    "provider": {
      +      "type": "string"
      +    },
      +    "tool": {
      +      "type": "string"
      +    },
      +    "valid": {
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  4. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the read-only, idempotent, non-destructive annotations, it discloses pricing and payment terms, supported schema drafts and formats, error details, size and error-count limits, the lack of remote $ref fetching, and offline operation. These details provide substantial cost, capability, and boundary information rather than repeating the annotations.

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 paragraph is compact and information-dense, with nearly every clause conveying an operational detail. Leading with payment mechanics rather than the core purpose and including the redundant phrase Input: json and schema slightly weaken its front-loading and economy.

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 three-parameter validator with full input-schema coverage and an output schema, the description supplies the remaining decision and invocation context: cost, supported dialects, result semantics, limits, and remote-reference behavior. Explicit sibling comparisons are the main omission, but they are not necessary to invoke the tool correctly.

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 much of the description repeats parameter information already present there, including the json and schema inputs, supported drafts, and size limits. The POST guidance for large documents and the alternative try_free route add modest value, but not enough additional parameter semantics to exceed the baseline.

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

Purpose4/5

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

The description clearly states the verb and resources: it validates a JSON document against a JSON Schema and reports validity plus detailed errors. It does not explicitly distinguish validation from siblings such as json_repair, json_schema_infer, or json_query, so that differentiation remains implied.

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 validation use case is clear, and the description adds practical invocation guidance to use POST for large documents and either the trial parameter or try_free for a trial call. It does not explain when to choose this tool over the closely related JSON siblings.

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.

Resources