TWZRD Agent Intelligence

score_wallet_for_intel

Read-onlyIdempotent

Free discovery: real 0-100 intel score for a wallet from its observed x402
payment history across the broader x402 ecosystem (paid calls, distinct
counterparties, volume, recency). 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.
`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.

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

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds rich behavioral detail: it discloses the transparent heuristic, states the exact formula is returned as `score_model`, lists all output fields including wash_flag/wash_factor, and describes the clean failure path for malformed pubkeys. It also reveals the Base-specific wash_flag behavior explicitly. This goes well beyond the annotations and provides exceptional transparency.

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 moderately long but well-structured, moving from core purpose to heuristic, output, and data source details. Each sentence provides useful information with no fluff. The purpose is front-loaded, making it easy to scan, though the length is above average. It earns a 4 for density and structure without being overly verbose.

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?

With one parameter and an output schema present, the description covers the essential aspects: input types, scoring model, output fields, failure behavior, and data source. It also mentions optional paid endpoints for deeper verification. Minor ambiguity remains in the relationship between intel_score and effective_score, but overall it is complete enough for an agent to invoke correctly.

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?

The schema already describes the 'wallet' parameter as a Solana base58 pubkey or Base 0x address, and the description reinforces this while adding meaningful nuance: it explains how a Base wallet is scored differently due to the lack of a wash graph, and that malformed pubkeys are cleanly rejected. This adds value beyond the schema's simple 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 explicitly states the tool scores a wallet from 0-100 based on observed x402 payment history, listing exact inputs (paid calls, counterparties, volume, recency). It clearly focuses on a single wallet, differentiating it from the sibling 'score_wallets_batch', and specifies accepted wallet types (Solana base58 and Base 0x). The verb 'score' plus resource and score range make the 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 Guidelines3/5

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

The description provides context about the data source and notes it is a free discovery tool, with optional paid endpoints for signed receipts. However, it does not explicitly state when to prefer this tool over siblings like 'score_wallets_batch' or 'compare_wallets', nor does it mention exclusions or prerequisites. The guidance is implied from the singular-wallet focus and free nature, but not made explicit.

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.