ATTRACTOR Verification & State

find_solutions

Read-only

Find persistent declarative JSON transformations. Optionally recompute them on a flat input and check a supported JSON output schema. Search uses English keywords. Results include evidence, immutable IDs and direct variants. Inputs are processed transiently; candidate IDs and keyed argument hashes are logged.

Input Schema

TableJSON Schema

Name	Required	Description
`input`	No
`limit`	No
`query`	No
`output_schema`	No
`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": {
+        "solutions": {
+          "type": "array"
+        }
+      },
+      "required": [
+        "solutions"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "error": {
+          "type": "string"
+        },
+        "request_id": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "error"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: inputs are processed transiently, candidate IDs and keyed argument hashes are logged, and reuse is counted only on matching fingerprints. This goes beyond the annotations and helps an agent understand side effects and privacy implications.

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 description is compact and front-loaded with the core purpose, followed by optional behavior and result details. Every sentence adds information, though the last sentence about logging could be more specific about retention or access.

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

Completeness4/5

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

Given the tool has an output schema and annotations covering safety, the description covers the main behavioral aspects: search, optional recomputation, result contents, transient processing, and logging. It does not explain pagination or how to interpret results, but the output schema likely covers that. A 4 is appropriate for a search tool with this complexity.

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 only 33%, so the description must compensate for undocumented parameters. It explains the purpose of query, input, output_schema, and the two attractor handles at a high level, but does not detail how they interact or what formats are expected beyond the schema. It adds some meaning but leaves gaps.

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 states a specific verb ('Find') and resource ('persistent declarative JSON transformations'), and distinguishes itself from siblings by mentioning search via English keywords, optional recomputation, and result contents. It is clear but does not explicitly name sibling alternatives.

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 description implies when to use it: when searching for transformations with English keywords, optionally validating against an input/output schema. It does not explicitly state when not to use it or name alternatives like read_solution or verify_reuse, but the context is clear enough for an agent.

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.