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

Name	Required	Description	Default
`merchant`	Yes	Seller/merchant pay_to address to score on inbound corpus reputation: a Solana base58 wallet or a Base 0x address.

Output 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 changedOct 20, 2026

changedInput schema / properties / merchant / description

Previous value: -"Seller/merchant Solana wallet public key (the pay_to address) to score on inbound corpus reputation."New value: +"Seller/merchant pay_to address to score on inbound corpus reputation: a Solana base58 wallet or a Base 0x address."

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.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing the fail-open contract (DB gap returns 'unknown' + wash_flagged=null, never clean), the tri-state meaning of wash_flagged, and the downstream consequence that wash_flagged=true triggers a buyer refuse / preflight block. This is exactly the operational semantics an agent needs and cannot get from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core question and keeps to a tight set of sentences, but the signal list is a dense run-on and 'captive-payer % (onboarding-sink proxy)' and 'top_payer_tx_pct (captive concentration)' restate the same captive-payer concept. Minor redundancy, otherwise every sentence carries weight.

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?

Given an output schema exists, the description correctly focuses on interpretation rather than return format, and it covers the failure mode, the tri-state null semantics, and the pricing/escalation ladder. Nothing an agent needs to invoke and interpret this tool correctly is missing.

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 100% and the single parameter is already fully documented (base58 Solana or 0x Base address). The description reinforces that this is the seller/merchant side of the graph but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('corpus-backed SELLER reputation for a merchant/provider wallet') and frames the question it answers ('is this provider organic, narrow, or a wash fleet?'). It explicitly differentiates from the sibling score_wallet_for_intel by naming the seller-side vs payer-side split, so an agent can pick between them without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly positions itself as the 'free discovery' / 'free seller signal' entry point and names the paid escalation hops with prices (GET /v1/intel/quick/{wallet} at 0.001 USDC, GET /v1/intel/trust/{wallet} at 0.05 USDC). The when-to-use context (seller side, complementing the payer-side tool) is spelled out rather than inferred.

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.