ATTRACTOR Verification, State & Evidence

extract_json

Read-onlyIdempotent

Use this tool when your workflow needs extract json from llm output. Input: text. Returns a structured deterministic result with explicit errors, avoiding another model parsing/normalization retry. Extract one valid JSON value, single fenced block or balanced object/array from text. Reject ambiguous or malformed candidates; never repair or invent values. 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.

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": {
      "text": "<text>"
    },
    "name": "extract_json"
  }
}

Input Schema

Name	Required	Description
`text`	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

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": {
+            "fingerprint": {
+              "type": "string"
+            },
+            "value": {}
+          },
+          "required": [
+            "value",
+            "fingerprint"
+          ],
+          "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 already declare readOnlyHint=true and idempotentHint=true, but the description goes well beyond them by disclosing deterministic behavior, explicit errors, rejection of ambiguous/malformed candidates, never repairing/inventing values, specific limits (24 KB, depth 24, 4,000 nodes), reserved prototype keys, unsafe integers, and transient input processing with HMAC trace metadata retention. This adds substantial value 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 well-structured, front-loading the primary use case, then detailing extraction behavior, limits, and error handling. Every sentence adds value: no filler or redundancy. It is longer than typical but each clause earns its place by covering critical operational constraints and error semantics.

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?

The description is complete for a tool of this complexity. It explains the return behavior (structured deterministic result with explicit errors), covers edge cases (ambiguous/malformed rejection), defines limits, and notes privacy aspects (transient input processing, HMAC metadata). With an output schema present (per context), the description need not elaborate further on return values.

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 67% (the two optional params have descriptions), and the schema itself documents maxLength for text. The description only mentions 'Input: text' without adding format or syntax details beyond the schema. The description implies the text should contain a JSON value but does not elaborate on parameter-specific constraints beyond what the schema provides. Baseline 3 is appropriate given the high coverage.

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 states a specific verb (extract) and resource (JSON from LLM output), and distinguishes itself from siblings by focusing on extraction from text with deterministic results. It explicitly mentions rejecting ambiguous/malformed candidates, which differentiates it from canonicalize_json or validate_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?

The opening line 'Use this tool when your workflow needs extract json from llm output' gives a clear when-to-use context. It does not explicitly name alternatives or exclusions, but the focus on extraction from LLM output implies when other tools (e.g., diff_json, flatten_json) would be inappropriate. It could benefit from explicit sibling differentiation.

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 & Evidence tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.