TWZRD Agent Intelligence

is_wash_fleet

Read-onlyIdempotent

Free discovery: cheap circular-flow (wash) check for a payer wallet.

Returns the CATEGORICAL classification (clean / self_pay / reciprocal /
self+reciprocal), an is_circular bool, and the observed event counts +
distinct_merchants from the wallet's corpus edges. Use as a fast Sybil/wash
gate before trusting a counterparty.

Accepts a Solana public key or a Base/EVM address. On Base the signal reads
the high-confidence x402 rollup only, and 3-cycle ring detection does not run
(Solana-only precomputed matview), so ring_events=0 there means NOT EVALUATED,
never "no rings observed".

Fail-open: a DB gap returns classification "unknown". The numeric wash discount
(wash_factor / wash_ratio) and the full renormalized model stay paid — they are
NOT returned here.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`wallet`	Yes	Wallet to check for circular-flow / wash behavior: a Solana public key (32-44 base58 chars) or a Base/EVM address (0x + 40 hex).

Output Schema

TableJSON Schema

Name	Required	Description
`chain`	No	Which corpus answered: "solana" or "base". Base reads the high-confidence x402 rollup only.
`error`	No	Present only on the degraded path.
`reason`	No	Degraded-path reason, if any.
`wallet`	No	The wallet checked.
`is_circular`	No	True if any self-pay or reciprocal (2-cycle) flow was observed.
`ring_events`	No	Events forming a 3-cycle ring. Meaningless unless ring_evaluated is true: 0 with ring_evaluated false means NOT LOOKED FOR, not none found.
`self_events`	No	Events where the wallet paid itself.
`total_events`	No	Total observed payment events.
`classification`	No	Circular-flow class: "clean" \| "self_pay" \| "reciprocal" \| "self+reciprocal" \| "unknown".
`ring_evaluated`	No	True only when the ring axis actually ran for this wallet: the precomputed Solana ring aggregate was read, or the live Base 3-cycle query returned. False when the ring lookup failed or the Solana wallet has no aggregate row yet - in both of which ring_events=0 means not evaluated, never none found.
`reciprocal_events`	No	Events forming a 2-cycle (counterparty also pays this wallet).
`distinct_merchants`	No	Distinct merchants this wallet paid.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

changedOutput schema / properties / ring_evaluated / description

Previous value: -"True only when the precomputed Solana ring aggregate was actually read for this wallet. False on Base (no ring matview), when the ring lookup failed, or when the wallet has no aggregate row yet - in all of which ring_events=0 means not evaluated, never none found."New value: +"True only when the ring axis actually ran for this wallet: the precomputed Solana ring aggregate was read, or the live Base 3-cycle query returned. False when the ring lookup failed or the Solana wallet has no aggregate row yet - in both of which ring_events=0 means not evaluated, never none found."

Changed1 schema field changedSep 6, 2026

changedOutput schema / properties / ring_evaluated / description

Previous value: -"Whether 3-cycle ring detection ran. True on Solana (precomputed matview); false on Base, where no such matview exists."New value: +"True only when the precomputed Solana ring aggregate was actually read for this wallet. False on Base (no ring matview), when the ring lookup failed, or when the wallet has no aggregate row yet - in all of which ring_events=0 means not evaluated, never none found."

Changed4 schema fields changedSep 4, 2026

changedInput schema / properties / wallet / description

Previous value: -"Solana wallet public key (32-44 base58 chars) to check for circular-flow / wash behavior."New value: +"Wallet to check for circular-flow / wash behavior: a Solana public key (32-44 base58 chars) or a Base/EVM address (0x + 40 hex)."

addedOutput schema / properties / chain

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Which corpus answered: \"solana\" or \"base\". Base reads the high-confidence x402 rollup only.",
+  "title": "Chain"
+}

addedOutput schema / properties / ring_evaluated

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether 3-cycle ring detection ran. True on Solana (precomputed matview); false on Base, where no such matview exists.",
+  "title": "Ring Evaluated"
+}

addedOutput schema / properties / ring_events

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Events forming a 3-cycle ring. Meaningless unless ring_evaluated is true: 0 with ring_evaluated false means NOT LOOKED FOR, not none found.",
+  "title": "Ring Events"
+}

First observedJul 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds critical behavioral details beyond these: fail-open DB gap returns 'unknown', and Base-specific limitation where ring_events=0 means NOT EVALUATED. This transparently discloses edge cases and platform differences, going well beyond annotation coverage.

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?

Front-loaded with purpose and then organized behavioral details. Each sentence adds value, no redundancy. The structure flows logically from what it does, to platform caveats, to what is not returned, making it efficient and scannable.

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?

Output schema exists, so return format is covered. The description covers edge cases (DB gap, Base behavior), what is not returned, and usage context. It gives an agent all necessary information to decide when to call and what to expect, with no missing critical details.

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 covers 100% of parameter details (wallet formats). The description reinforces this and adds platform-specific behavior for the parameter, e.g., 'On Base the signal reads the high-confidence x402 rollup only, and 3-cycle ring detection does not run.' This adds meaningful context beyond the schema's type description.

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 'cheap circular-flow (wash) check for a payer wallet' with specific outputs (classification, is_circular bool, counts). It distinguishes itself from paid alternatives by noting the free discovery aspect and that the wash discount is not returned, making its purpose unambiguous.

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?

Explicitly states 'Use as a fast Sybil/wash gate before trusting a counterparty.' It also clarifies what is not returned (paid wash factor), implying when to seek a paid alternative. However, it does not explicitly name a sibling tool as the alternative, so guidance is strong but not exhaustive.

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

All TWZRD Agent Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.