TWZRD Agent Intelligence

score_wallet_for_intel

Read-onlyIdempotent

Free discovery: PAYER-side 0-100 intel score for a wallet from the x402
payments it SENT (paid calls, distinct counterparties, volume, recency).
Not a seller check: to vet a seller/payTo before paying, use
get_readiness_card_tool (gate) or get_provider_reputation / get_merchant_card
(seller reputation). A pure seller scores 0 here by construction and the
response says so in seller_side_hint. A Base 0x wallet is scored from the
relayer-attributed x402_base_daily rollup (90d) with the same shape; no Base
wash graph exists yet, so its wash_flag is "unknown" unless single-counterparty.

Uses a simple transparent heuristic (volume log + breadth + spend log + recency
decay) — the exact formula is returned inline as `score_model`. Returns
intel_score, the wash-discounted effective_score + wash_flag/wash_factor
(cheap Sybil signal), counts, component breakdown, and a data_available flag.
Malformed pubkeys are rejected cleanly; the failure path returns the same
shape as success.

Sourced from the cross-facilitator corpus via the public Rust HTTP endpoint
GET /v1/agents/{wallet}/x402 (backed by the x402_solana_payer_agg matview).
First paid hop is the score-only teaser GET /v1/intel/quick/{wallet} (0.001 USDC).
Optional V7 signed receipt (intel_renorm_v1_1: score_raw, confidence,
breadth_factor, wash_factor) is GET /v1/intel/trust/{wallet} (0.05 USDC).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`wallet`	Yes	Wallet to score: a Solana base58 pubkey or a Base 0x address, using x402 payment-history intelligence.

Output Schema

TableJSON Schema

Name	Required	Description
`role`	No	Observed role: "payer" \| "merchant" \| "both" \| "unknown".
`basis`	No	Human-readable basis line.
`chain`	No	"base" when scored from the Base corpus; null on the Solana path.
`error`	No	Present only on the degraded path.
`wallet`	No	The scored wallet: Solana base58 pubkey or Base 0x address (lowercased).
`network`	No	CAIP-2 network of the corpus used, e.g. "eip155:8453"; null on the Solana path.
`last_seen`	No	ISO timestamp of last observed activity.
`wash_flag`	No	"clean" \| "single_counterparty" \| "unknown".
`first_seen`	No	ISO timestamp of first observed activity.
`paid_calls`	No	Observed x402 paid calls SENT (payer side).
`total_usdc`	No	Total observed USDC sent.
`intel_score`	No	Raw activity-reputation score, 0-100.
`score_model`	No	Self-describing scoring contract (scale, formula, component maxes, recency tiers).
`wash_factor`	No	Multiplier applied to intel_score for effective_score.
`window_days`	No	Observation window in days when the corpus is windowed (Base: 90); null on the Solana path.
`score_version`	No	Scoring contract version.
`wash_coverage`	No	Which wash signals exist for this chain. Base: single-counterparty only, so wash_flag is "unknown" (never "clean") for multi-counterparty wallets.
`data_available`	No	False when the corpus could not be observed (vs genuinely inactive).
`effective_score`	No	Wash-discounted score (single-counterparty fleets demoted).
`score_components`	No	Per-component breakdown: volume, breadth, spend, recency_factor.
`seller_side_hint`	No	Set when this wallet reads as a SELLER (role merchant, or payments received with no paid calls sent). intel_score here is the PAYER-side score and is 0 for a pure seller by construction; it is not a verdict about the seller. Points at get_provider_reputation / get_merchant_card (seller side) and get_readiness_card_tool (the pre-spend gate).
`payments_received`	No	Observed x402 paid calls RECEIVED (merchant side).
`total_usdc_received`	No	Total observed USDC received (merchant side).
`is_single_counterparty`	No	True if all payments went to one counterparty (Sybil signal).
`distinct_counterparties`	No	Distinct counterparties (merchants paid + payers received from).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedOutput schema / properties / seller_side_hint

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Set when this wallet reads as a SELLER (role merchant, or payments received with no paid calls sent). intel_score here is the PAYER-side score and is 0 for a pure seller by construction; it is not a verdict about the seller. Points at get_provider_reputation / get_merchant_card (seller side) and get_readiness_card_tool (the pre-spend gate).",
+  "title": "Seller Side Hint"
+}

Changed6 schema fields changedSep 4, 2026

changedInput schema / properties / wallet / description

Previous value: -"Solana wallet public key (32-44 base58 chars) to score using x402 payment-history intelligence."New value: +"Wallet to score: a Solana base58 pubkey or a Base 0x address, using x402 payment-history intelligence."

addedOutput schema / properties / chain

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "\"base\" when scored from the Base corpus; null on the Solana path.",
+  "title": "Chain"
+}

addedOutput schema / properties / network

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "CAIP-2 network of the corpus used, e.g. \"eip155:8453\"; null on the Solana path.",
+  "title": "Network"
+}

changedOutput schema / properties / wallet / description

Previous value: -"The scored Solana wallet."New value: +"The scored wallet: Solana base58 pubkey or Base 0x address (lowercased)."

addedOutput schema / properties / wash_coverage

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Which wash signals exist for this chain. Base: single-counterparty only, so wash_flag is \"unknown\" (never \"clean\") for multi-counterparty wallets.",
+  "title": "Wash Coverage"
+}

addedOutput schema / properties / window_days

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Observation window in days when the corpus is windowed (Base: 90); null on the Solana path.",
+  "title": "Window Days"
+}

First observedJul 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover readOnly/idempotent, but the description adds substantial behavior: the transparent heuristic components, wash_flag/wash_factor semantics, Base vs Solana scoring paths and the 'unknown' wash_flag caveat, clean rejection of malformed pubkeys, and the guarantee that the failure path returns the same shape as success. These are exactly the traits annotations cannot convey.

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-loaded with the core purpose and the exclusion, then layers in caveats and endpoints. It is dense and long, and the trailing endpoint/pricing details (quick teaser, signed receipt) are more operational than call-relevant, keeping it just short of maximally tight.

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 scoring tool with dual-chain logic, wash signals, and a non-trivial failure path, the description covers inputs, semantics, edge cases, and downstream signals. With an output schema present it need not restate return fields, yet it still names the key ones, so nothing an agent needs to invoke it correctly is missing.

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 coverage is 100% and already documents that the wallet is a Solana base58 pubkey or Base 0x address, so the baseline is 3. The description adds real meaning beyond the schema by explaining how a Base 0x wallet is scored (relayer-attributed x402_base_daily rollup, 90d) versus the Solana path.

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/resource/scope: a 'PAYER-side 0-100 intel score for a wallet from the x402 payments it SENT', with the exact signals (paid calls, distinct counterparties, volume, recency). It also explicitly names the sibling it is not (seller checks -> get_readiness_card_tool, get_provider_reputation, get_merchant_card), so an agent can disambiguate without opening other 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?

Gives explicit when-to-use (free payer-side discovery) and when-NOT-to-use ('Not a seller check'), routing to named alternatives for seller vetting. It also flags the seller-scores-zero edge case so an agent won't misread a 0 as an error.

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.