Skip to main content
Glama
Sign In

xytara MCP Executor

by com.naxytra
OverviewDiscussionsAdmin

JSON Schema validation

json.validate
Read-onlyIdempotent

Validates a JSON payload (any JSON value, or JSON text as a string) against a JSON Schema and returns valid plus every error with its JSON Pointer path. Supported keywords: type, required, properties, additionalProperties, items/prefixItems, enum, const, minimum/maximum, exclusiveMinimum/exclusiveMaximum, multipleOf, minLength/maxLength, pattern, minItems/maxItems, uniqueItems, min/maxProperties, allOf. A schema using other keywords ($ref, anyOf, oneOf, not, if/then) is rejected (not charged) rather than half-checked. Without a schema only well-formedness is checked. Price: $0.01 USDC per call on Base mainnet ($0.001 on Base Sepolia), paid with x402; failed calls are not charged.

Input Schema

NameRequiredDescriptionDefault
schemaNoJSON Schema (object, or JSON text).
payloadYesThe JSON value to validate; a string is parsed as JSON text unless parse_string is false.
schema_nameNoOptional label echoed back.
parse_stringNoParse a string payload as JSON text (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / parse_string
      Added value: +{
+  "description": "Parse a string payload as JSON text (default true).",
+  "type": "boolean"
+}
    • changedInput schema / properties / payload / description
      Previous value: -"JSON payload to inspect."New value: +"The JSON value to validate; a string is parsed as JSON text unless parse_string is false."
    • removedInput schema / properties / payload / type
      Removed value: -"object"
    • addedInput schema / properties / schema
      Added value: +{
+  "description": "JSON Schema (object, or JSON text).",
+  "type": [
+    "object",
+    "boolean",
+    "string"
+  ]
+}
    • changedInput schema / properties / schema_name / description
      Previous value: -"Optional schema label for the validation request."New value: +"Optional label echoed back."
    • addedInput schema / properties / schema_name / maxLength
      Added value: +200
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: x402 payment requirement, exact price on Base mainnet/Sepolia, 'failed calls are not charged', and that unsupported-keyword schemas are rejected rather than partially checked. This is precisely the extra behavioral context the annotations cannot 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?

Front-loaded with purpose, then constraints, then pricing; each sentence carries information. The supported-keyword enumeration is long but functional rather than filler, and there is no redundant restatement of the title.

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?

Despite having no output schema, the description explains the return values (valid flag plus errors with JSON Pointer paths), covers the no-schema case, the rejection case, payment mechanics, and the schema_name echo behavior. An agent has everything needed to call this correctly and anticipate failures.

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?

Schema coverage is 100%, so the structured fields already define all four parameters. The description nonetheless adds real semantic value by enumerating which schema keywords are supported, which constrains what may legitimately be passed as `schema` and is not expressible in the schema itself.

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+resource ('Validates a JSON payload ... against a JSON Schema') and the return contract ('returns valid plus every error with its JSON Pointer path'). No sibling in the list does schema validation, so it is trivially distinguishable from abi.decode, merkle.verify, etc.

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?

Gives clear operating conditions: pass a schema to validate against one, omit it to check only well-formedness, and schemas using unsupported keywords ($ref, anyOf, oneOf, not, if/then) are rejected rather than half-checked. It does not name an alternative sibling or an explicit when-not to call, but the branch conditions are unambiguous.

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

All xytara MCP Executor toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources