ATTRACTOR Verification & State

validate_schema

Read-onlyIdempotent

Use this tool when your workflow needs json schema validation api. Input: value, schema. Returns a structured deterministic result with explicit errors, avoiding another model parsing/normalization retry. Validate the documented bounded JSON Schema subset. Unsupported keywords rejected. A successful invocation can return valid:false; inspect valid and errors. Limits: request 24 KB, JSON depth 24, 4,000 nodes. Reserved prototype keys and unsafe integers rejected. Inputs processed transiently; private HMAC trace metadata retained.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes
`schema`	Yes
`attractor_trace_id`	No	Optional public correlation handle from a prior result; not authentication or proof of identity.
`attractor_knowledge_id`	No	Optional prior result handle. Reuse is counted only when the supplied value matches that result fingerprint.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 10, 2026

addedInput schema / properties / attractor_knowledge_id

Added value: +{
+  "description": "Optional prior result handle. Reuse is counted only when the supplied value matches that result fingerprint.",
+  "pattern": "^ATR-K-[a-f0-9]{64}$",
+  "type": "string"
+}

addedInput schema / properties / attractor_trace_id

Added value: +{
+  "description": "Optional public correlation handle from a prior result; not authentication or proof of identity.",
+  "pattern": "^ATR-T-[a-f0-9]{32}$",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "attractor_trace_id": {
+          "type": "string"
+        },
+        "commons": {
+          "type": "object"
+        },
+        "knowledge_id": {
+          "type": "string"
+        },
+        "ok": {
+          "const": true
+        },
+        "request_id": {
+          "type": "string"
+        },
+        "result": {
+          "properties": {
+            "errors": {
+              "type": "array"
+            },
+            "valid": {
+              "type": "boolean"
+            }
+          },
+          "required": [
+            "valid",
+            "errors"
+          ],
+          "type": "object"
+        },
+        "tool": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "ok",
+        "tool",
+        "result",
+        "knowledge_id",
+        "attractor_trace_id",
+        "request_id",
+        "commons"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "error": {
+          "type": "string"
+        },
+        "request_id": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "error"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

AddedSep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover safety (readOnly, idempotent, non-destructive). The description adds substantial behavioral context: deterministic results, explicit errors, constraints (24 KB, depth 24, 4,000 nodes, reserved key/unsafe integer rejections), and transient input processing with HMAC trace retention. This goes well beyond 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.

Conciseness5/5

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

The description is dense and efficiently front-loaded with purpose, then covers behavior, constraints, and data handling without redundancy. Every sentence provides operational value; no fluff.

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 correctly focuses on invocation context: when to use, what is validated, deterministic results, limits, and side-effects. It provides everything an agent needs to call the tool correctly and interpret outcomes (inspect valid and errors).

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 50%, covering only the two attractor_* optional parameters. The description says 'Input: value, schema' but does not elaborate on their structure or expected formats beyond noting the bounded subset and 'unsafe integers' rejection. It adds some context but does not fully compensate for the undocumented main parameters.

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?

The description clearly identifies the tool as a JSON Schema validation API with specific inputs (value, schema) and a deterministic structured result. It implies a validation operation that is distinct from sibling tools like canonicalize_json or coerce_to_schema, and explicitly states the bounded subset being validated.

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?

It clearly states when to use the tool ('when your workflow needs json schema validation api') and gives a rationale (avoiding model retry). However, it doesn't explicitly mention alternatives or when not to use it, though the specificity of the purpose implicitly differentiates it from siblings.

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

All ATTRACTOR Verification & State tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.