ATTRACTOR Verification & State

verify_reuse

Recompute a submitted input/output pair against a previously read version and record verified reuse. Requires the private exposure_id and marker from read_solution. This does not prove independent agency.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`input`	Yes
`marker`	Yes
`output`	Yes
`exposure_id`	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": {
+        "verified": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "verified"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "error": {
+          "type": "string"
+        },
+        "request_id": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "error"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds that it 'records verified reuse' (a write operation) and the explicit limitation about independent agency, which is useful. But it does not describe side effects (e.g., what exactly gets recorded, whether it alters existing data) or return behavior. Given the annotations are present but minimal, the description adds some value without being rich.

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 three short sentences with no waste. The core action and scope are front-loaded, followed by the prerequisite and a critical limitation. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex: 7 parameters, 5 required, nested objects, and an output schema. The description does not explain what the input/output objects represent, what the verification process entails, or what 'verified reuse' means in practice. The note about exposure_id/marker is helpful but insufficient for an agent to correctly construct a call. Even with an output schema, the missing input semantics make this incomplete.

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

Parameters2/5

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

Schema description coverage is low at 29%, so the description must compensate. It only makes a vague connection: 'Requires the private exposure_id and marker from read_solution' — which helps for those two UUID params but gives no guidance on what input and output should contain (the two nested objects), nor the optional attractor handles beyond schema descriptions. With 7 parameters and minimal schema detail, this is a significant gap.

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 the specific action: 'Recompute a submitted input/output pair against a previously read version and record verified reuse.' It also distinguishes itself from siblings by requiring the private exposure_id and marker from read_solution, and it explicitly clarifies what it does NOT do ('does not prove independent agency'), which differentiates it from other tools in the set.

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 gives explicit prerequisites: 'Requires the private exposure_id and marker from read_solution.' This tells the agent when to use it (after read_solution). It also cautions about the tool's limitation ('does not prove independent agency'), which guides interpretation. However, it does not name alternative sibling tools or explain when NOT to use it, so it stops short of a full when/when-not guide.

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.