TWZRD Agent Intelligence

get_provider_reputation

Read-onlyIdempotent

Free discovery: corpus-backed SELLER reputation for a merchant/provider wallet.

Answers "is this provider organic, narrow, or a wash fleet?" from the merchant's
inbound payment graph over the last 90 days: unique payers, repeat-payer %,
heavy-fleet revenue concentration, captive-payer % (onboarding-sink proxy), and
a scripted-fleet uniformity signal, and top_payer_tx_pct (captive
concentration). Returns wash_label + reputation tier + wash_flagged
(tri-state: true | false | null; null = never evaluated, not clean).

Complements score_wallet_for_intel (payer side) with the seller side.
wash_flagged=true never soft-allows (buyer refuse; preflight block). Fail-open:
a DB gap returns wash_label/tier "unknown" AND wash_flagged=null (plus
wash_confidence) - an unevaluated verdict, never a clean one. This is the free
seller signal. First paid hop is GET /v1/intel/quick/{wallet} (0.001 USDC).
Optional V7 renorm + signed receipt is GET /v1/intel/trust/{wallet} (0.05 USDC).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`merchant`	Yes	Seller/merchant Solana wallet public key (the pay_to address) to score on inbound corpus reputation.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	No	Degraded-path reason (e.g. db_unavailable, no_corpus_inbound).
`merchant`	No	The seller/merchant Solana wallet looked up.
`total_tx`	No	Total inbound paid calls (90d).
`wash_label`	No	Seller class: "provider_organic_broad" \| "provider_mixed" \| "provider_narrow_or_unknown" \| "wash_shaped" \| "fleet_dominated" \| "unknown".
`wash_flagged`	No	true = fleet/wash/captive/scripted-fleet signals tripped — never soft-allow (refuse / preflight block); false = evaluated and clean; null = never evaluated (unknown - do NOT coerce to false).
`score_version`	No	provider_reputation_v1.
`unique_payers`	No	Distinct payers observed paying this merchant (90d).
`wash_confidence`	No	"full" when self+reciprocal+ring ran; "base_2cycle" when the Base 2-cycle overlay ran but the live 3-cycle ring query did not return (not a full screen); "partial_inbound_only" when the circular-flow overlay did not run.
`avg_tx_per_payer`	No	Average inbound tx per payer.
`repeat_payer_pct`	No	Percent of payers who paid more than once.
`top_payer_tx_pct`	No	Percent of inbound settles supplied by the single largest payer (captive concentration; >=90 with volume floor flags wash; null = not computed).
`captive_payer_pct`	No	Percent of payers who pay ONLY this merchant (captive/onboarding-sink proxy).
`heavy_fleet_tx_cv`	No	Tx-count uniformity across heavy-fleet payers; near-zero = scripted sybil fleet.
`total_revenue_usd`	No	Total inbound USDC revenue (90d).
`heavy_fleet_payers`	No	Count of heavy single-counterparty fleet payers.
`heavy_fleet_revenue_pct`	No	Percent of revenue from heavy-fleet payers.
`provider_reputation_tier`	No	Tier: "tier_a_provider" \| "tier_b_provider" \| "tier_tail" \| "tier_wash_demo" \| "unknown".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 12, 2026

changedOutput schema / properties / wash_flagged / description

Previous value: -"true = fleet/wash/captive/scripted-fleet signals tripped; false = evaluated and clean; null = never evaluated (unknown - do NOT coerce to false)."New value: +"true = fleet/wash/captive/scripted-fleet signals tripped — never soft-allow (refuse / preflight block); false = evaluated and clean; null = never evaluated (unknown - do NOT coerce to false)."

Changed1 schema field changedSep 7, 2026

changedOutput schema / properties / wash_confidence / description

Previous value: -"\"full\" when self+reciprocal+ring ran; \"base_2cycle\" when only the Base 2-cycle overlay ran (3-cycle ring not evaluated — not a full screen); \"partial_inbound_only\" when the circular-flow overlay did not run."New value: +"\"full\" when self+reciprocal+ring ran; \"base_2cycle\" when the Base 2-cycle overlay ran but the live 3-cycle ring query did not return (not a full screen); \"partial_inbound_only\" when the circular-flow overlay did not run."

Changed1 schema field changedSep 6, 2026

changedOutput schema / properties / wash_confidence / description

Previous value: -"\"full\" when the circular-flow overlay ran; \"partial_inbound_only\" when it did not."New value: +"\"full\" when self+reciprocal+ring ran; \"base_2cycle\" when only the Base 2-cycle overlay ran (3-cycle ring not evaluated — not a full screen); \"partial_inbound_only\" when the circular-flow overlay did not run."

Changed3 schema fields changedAug 19, 2026

addedOutput schema / properties / top_payer_tx_pct

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Percent of inbound settles supplied by the single largest payer (captive concentration; >=90 with volume floor flags wash; null = not computed).",
+  "title": "Top Payer Tx Pct"
+}

addedOutput schema / properties / wash_confidence

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "\"full\" when the circular-flow overlay ran; \"partial_inbound_only\" when it did not.",
+  "title": "Wash Confidence"
+}

changedOutput schema / properties / wash_flagged / description

Previous value: -"True if fleet/wash/captive/scripted-fleet signals tripped."New value: +"true = fleet/wash/captive/scripted-fleet signals tripped; false = evaluated and clean; null = never evaluated (unknown - do NOT coerce to false)."

First observedJul 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses critical runtime behavior: wash_flagged is tri-state where null means 'never evaluated, not clean', fail-open behavior on DB gaps returns an 'unevaluated' verdict rather than a clean one, and wash_flagged=true blocks preflight/buyer refusal. This is exactly the kind of non-obvious behavior an agent needs.

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 dense but purposeful: purpose, output semantics, fallback behavior, sibling contrast, and paid alternatives are all packed in without fluff. A few parenthetical asides make it slightly run-on, but every sentence earns its place and the core purpose is front-loaded.

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?

For a single-parameter, read-only, idempotent tool with an output schema, the description is complete. It covers call semantics, failure behavior, pricing, and the relationship to the paid API, leaving no material gap in what an agent needs to invoke or interpret this tool correctly.

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?

The schema already documents the sole parameter 'merchant' with 100% coverage, so the description does not need to carry much weight. It adds the useful nuance that the merchant is the pay_to address scored on 'inbound corpus reputation', but no new format or constraints beyond the schema.

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 opens with a specific verb and resource: 'free discovery: corpus-backed SELLER reputation for a merchant/provider wallet.' It names the exact questions answered and the computed signals (wash_label, reputation tier, wash_flagged), and explicitly differentiates from score_wallet_for_intel as the seller-side complement to the payer side.

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 frames this as the free seller signal, states that it complements score_wallet_for_intel, and names the paid upgrade paths with prices. It does not explicitly state when NOT to use it relative to siblings like is_wash_fleet or low_level_preflight, so exclusion guidance is slightly incomplete.

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.