TWZRD Agent Intelligence
Server Details
Trust + receipt layer for x402 agents on Solana: free preflight + paid signed V6 trust receipt.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 17 of 17 tools scored. Lowest: 2.7/5.
Each tool targets a distinct aspect of wallet intelligence, Solana market data, or verification. Even the Solana market tools (status, depth, shape, visibility, trades) are clearly separated. Overlaps like score_wallet_for_intel and score_wallets_batch are differentiated by batch vs single, and low_level_preflight vs get_readiness_card_tool are distinguished by detail level.
Tool names mix verb prefixes: mostly 'get_' (10 tools), but also 'compare_', 'is_', 'low_level_', 'score_', 'verify_'. While each is readable, the pattern is not uniform. Some are verb_noun (get_counterparties), others adjective_noun (low_level_preflight), leading to moderate consistency.
17 tools is well-scoped for an intelligence platform covering wallet discovery, market analysis, and verification. Each tool has a clear purpose with no redundancy, and the count feels appropriate for the breadth of functionality offered.
The tool set covers free discovery, scoring, reputation checks, market data, and verification. Missing is a direct tool to initiate a paid intel purchase, but the readiness card and preflight tools provide upsell paths. Minor gap but core workflows are supported.
Available Tools
18 toolscompare_walletsARead-onlyIdempotentInspect
Free discovery: side-by-side intel for two wallets (e.g. choosing between two
candidate providers). Returns both full score objects and which ranks higher by
the wash-discounted effective_score ("tie" on equal, null if a side is unavailable).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_a | Yes | First Solana wallet pubkey to compare. | |
| wallet_b | Yes | Second Solana wallet pubkey to compare. |
Output Schema
| Name | Required | Description |
|---|---|---|
| wallet_a | No | Full score object for the first wallet. |
| wallet_b | No | Full score object for the second wallet. |
| higher_effective_score | No | Wallet with the higher wash-discounted score, or "tie", or null if a side was unavailable. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent behavior, which is consistent. The description adds concrete behavioral details: return of full score objects, ranking by wash-discounted effective_score, handling of ties and unavailable sides. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and output details. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and strong annotations, the description covers the key behavioral aspects: comparison, ranking metric, edge cases. It is slightly lacking in prerequisites or error scenarios, but these are likely covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters ('First Solana wallet pubkey', 'Second Solana wallet pubkey') with 100% coverage. The description adds no additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two wallets side-by-side and returns score objects plus a ranking indicator. It includes an example use case and distinguishes from siblings like score_wallet_for_intel by specifying pairwise comparison with effective_score ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('choosing between two candidate providers') and implies when to use this tool. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evaluate_x402_resourceARead-onlyIdempotentInspect
One-shot x402 guard. Fetches resource_url, extracts the seller wallet from the 402 accepts
array (prefers Solana network entries), runs TWZRD preflight, and returns a spending decision.
Decision:
"allow" -> safe to proceed with the payment.
"warn" -> proceed with caution; consider buying the paid trust receipt (receipt_url, $0.05).
"block" -> DO NOT PAY. Stop immediately.
is_x402 == False -> not an x402 resource (HTTP != 402); treat as allow.
Revenue path: when decision is "warn", fetch receipt_url with an x402-capable wallet ($0.05
USDC to TWZRD) to get a signed V6 corpus-backed credential with the full trust score.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | HTTP method to use when probing the resource. Default: GET. | GET |
| price_usdc | No | Known price in USDC — overrides what the 402 reports. Leave unset to use the 402-reported amount. | |
| agent_intent | No | Natural-language description of what the agent intends to purchase. | |
| resource_url | Yes | URL of the x402 resource to evaluate before paying. Will be fetched to extract 402 payment requirements. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | The evaluated resource URL. |
| error | No | Error or info message; present on non-402 and degraded paths. |
| is_x402 | No | True if the resource returned HTTP 402 with x402 payment requirements. |
| decision | No | Spend decision: "allow" | "warn" | "block". |
| price_usdc | No | Quoted price in USDC from the 402 response. |
| receipt_url | No | URL to fetch the paid trust receipt ($0.05 USDC to TWZRD). |
| trust_score | No | Composite trust signal, 0-100. |
| upsell_usdc | No | Cost of the TWZRD paid trust receipt in USDC. |
| seller_wallet | No | Seller wallet extracted from the 402 accepts array (Solana preferred). |
| readiness_card | No | Full readiness card from the preflight evaluation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by detailing the fetch, extraction, preflight, and decision logic, including the revenue path. No contradictions; it provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (around 100 words) and well-structured with bullet points for decision outcomes. Every sentence adds value, and it separates the main function from the revenue path clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (x402 evaluation, preflight, decision logic), the description covers the main outcomes and the revenue path. Since an output schema exists, detailed return format is not required. Slightly incomplete on edge cases but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description explains how parameters like price_usdc and agent_intent fit into the flow but does not add significant meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'One-shot x402 guard' that fetches a resource URL, extracts seller wallet, runs preflight, and returns a spending decision. It explains the decision outcomes and even the revenue path, distinguishing it from sibling tools that focus on wallets, reputation, or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (evaluate a resource before paying) but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not-to-use guidance is provided, making it rely on implicit understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_counterpartiesARead-onlyIdempotentInspect
Free discovery (capped teaser): the top-N merchants a wallet actually pays, by
event count, with per-edge tx_count / total_usdc / first+last timestamps.
See WHO a counterparty transacts with before trusting it. The list is capped
(default 10, max 25) and `capped`/`total_distinct_merchants` disclose how much
is withheld; the FULL deduped payment graph and numeric edge weights are part
of the paid intel surface (GET /v1/intel/trust/{wallet}). Fail-open.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max counterparties to return (default 10, hard cap 25 - this is a capped teaser). | |
| wallet | Yes | Payer Solana wallet public key (32-44 base58 chars) whose counterparties (merchants paid) to list. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only on the degraded path. |
| capped | No | True if the full merchant set exceeds the returned list. |
| wallet | No | The payer wallet looked up. |
| returned | No | Number of counterparties returned (<= limit). |
| teaser_note | No | States that the full deduped graph + edge weights are paid. |
| total_events | No | Total observed payment events for this payer. |
| counterparties | No | Capped top-N merchants paid, each with tx_count, total_usdc, first_at, last_at. |
| data_available | No | False when the corpus/DB was unavailable. |
| total_distinct_merchants | No | Total distinct merchants this payer has paid (full, uncapped). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds that it's a capped teaser, discloses cap/withheld fields, and mentions fail-open behavior and that full graph is paid, providing valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with main purpose, and uses bullet-like formatting. Slightly dense but efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and existence of output schema, the description sufficiently covers what is returned, the cap, and fallback behavior. It provides enough context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces the cap for limit and wallet purpose but doesn't add new semantic details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers top-N merchants a wallet pays, with details on event count, tx_count, total_usdc, timestamps. It distinguishes from siblings like compare_wallets and score_wallet_for_intel by focusing on counterparty listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool before trusting a counterparty, mentions the capped nature, and points to the full graph endpoint for paid intel. It explicitly says the list is capped and how to check withheld data, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facilitator_footprintARead-onlyIdempotentInspect
Free discovery: which x402 facilitators a payer has settled through, and how many.
unique_facilitators = 1 is a thin/captive agent (locked to one rail); breadth
across facilitators indicates a more established cross-rail agent. Returns the
facilitator_ids list plus tx/merchant context. Fail-open: a DB gap returns
data_available=false rather than erroring.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Solana wallet public key (32-44 base58 chars) to look up its x402 facilitator footprint. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only on the degraded path. |
| found | No | True if the wallet has observed corpus activity. |
| wallet | No | The wallet looked up. |
| tx_count | No | Total observed paid calls. |
| last_seen | No | ISO timestamp of last observed activity. |
| first_seen | No | ISO timestamp of first observed activity. |
| data_available | No | False when the corpus/DB was unavailable. |
| facilitator_ids | No | The facilitator identifiers observed for this payer. |
| unique_merchants | No | Distinct merchants paid. |
| unique_facilitators | No | Distinct x402 facilitators this payer has settled through (1 = thin/captive). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint) by documenting fail-open behavior (DB gap returns data_available=false) and explaining the interpretation of output values (e.g., unique_facilitators=1 indicates captive agent). This aligns with and enriches 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences plus a line break to convey purpose, interpretation, return content, and error behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, annotations present, output schema exists), the description covers purpose, input, output elements, and error handling. No gaps remain for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description covers the parameter completely (100% coverage), so the tool description does not need to add much. It restates the wallet concept but does not introduce new semantic details beyond what the schema provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool discovers which x402 facilitators a payer has settled through and how many, with a specific verb ('discover') and resource ('facilitators'). It distinguishes itself from siblings like get_counterparties by focusing specifically on facilitator footprint and providing a heuristic (unique_facilitators=1 for captive agents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking facilitator breadth but does not explicitly specify when to use it over alternatives. It lacks direct comparisons or exclusion criteria for sibling tools, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_provider_reputationARead-onlyIdempotentInspect
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. Returns a wash_label + reputation tier +
wash_flagged bool.
Complements score_wallet_for_intel (payer side) with the seller side. Fail-open:
a DB gap returns wash_label/tier "unknown" rather than erroring. This is the free
seller signal; the paid per-wallet renorm model + signed v6 receipt remain at
GET /v1/intel/trust/{wallet} (0.05 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| merchant | Yes | Seller/merchant Solana wallet public key (the pay_to address) to score on inbound corpus reputation. |
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 if fleet/wash/captive/scripted-fleet signals tripped. |
| score_version | No | provider_reputation_v1. |
| unique_payers | No | Distinct payers observed paying this merchant (90d). |
| avg_tx_per_payer | No | Average inbound tx per payer. |
| repeat_payer_pct | No | Percent of payers who paid more than once. |
| 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds behavioral details: uses 90-day inbound payment graph, fail-open returns 'unknown', free vs. paid version. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded key phrase 'Free discovery'. Slightly verbose but informative and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with multiple metrics, outputs, and comparisons, the description is fully adequate. It mentions return fields, fail-open, and alternatives, compensating for missing output schema in the provided data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. Description adds context: 'pay_to address' and 'score on inbound corpus reputation', clarifying the parameter's role beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing corpus-backed seller reputation for a merchant wallet, listing specific metrics and outputs. It distinguishes from sibling tool score_wallet_for_intel (payer side).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that it complements the payer-side tool and contrasts with a paid version. It also describes fail-open behavior, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_readiness_card_toolARead-onlyIdempotentInspect
Free pre-spend gate. Pass seller_wallet (or resource_name for marketplace listings).
Check decision in the response (top-level, no nesting via MCP):
"block" -> DO NOT PAY. Stop.
"warn" -> proceed with caution.
"allow" -> proceed.
trust_score is a free heuristic (heuristic_registry_v0), NOT the full corpus.
For the corpus-backed score + signed v6 receipt: GET /v1/intel/trust/{wallet} (0.05 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| price_usdc | No | Quoted price in USDC for the action you are evaluating. | |
| agent_intent | No | Natural-language intent describing the planned paid action. | |
| buyer_wallet | No | Buyer's Solana wallet public key used for spend-context checks. | |
| resource_url | No | Canonical endpoint URL for the resource, if available. | |
| resource_name | No | Provider or resource label in a marketplace (for example marketplace:agent-name). Provide this OR seller_wallet. | |
| seller_wallet | No | Seller's Solana wallet public key associated with the listing or endpoint. Provide this OR resource_name. | |
| queried_pubkey | No | Consumer pubkey for velocity attribution (echoed on output when provided). | |
| marketplace_score | No | Optional upstream marketplace trust score (0-100) to blend into preflight context. |
Output Schema
| Name | Required | Description |
|---|---|---|
| proof | No | Proof block: v5_receipt_upsell_available, has_v5_receipts, receipt_endpoint, known_seller_wallets, provider_reputation. |
| caveats | No | Risk factors and the always-on trust_score_basis caveat. |
| version | No | Card schema version, e.g. readiness_card_v1. |
| category | No | Resource category (e.g. defi, defi_intelligence). |
| decision | No | Spend decision: "allow" | "warn" | "block". |
| can_spend | No | True iff decision == allow. |
| next_fixes | No | Actionable steps the provider can take to raise trust. |
| price_usdc | No | Quoted price in USDC. |
| trust_score | No | Composite trust signal, 0-100. |
| resource_name | No | Resolved resource/provider label. |
| seller_wallet | No | Seller Solana wallet, if known. |
| paid_deep_dive | No | Path to the paid full-trust surface (/v1/intel/trust/{wallet}). |
| queried_pubkey | No | Consumer pubkey echoed when provided on input (velocity attribution; not a settle gate). |
| paid_price_usdc | No | Price of the paid deep dive in USDC. |
| root_provenance | No | WZRD protocol root metadata (for deposit/claim/settle resources): latest_root_seq, dataset_hash (if known), leaf_version (GLOBAL_V5), verification_status, onchain_match (null = call verify_root_inputs before on-chain action), dflow_velocity (when TWZRD_DFLOW_DATA_FIRST_URL set, for cross-referencing on-chain velocity/attention signals with the root's attention_bonus). Auto-populated on protocol keywords/mints/categories. Complements the verify_root_inputs tool for independent GLOBAL_V5 leaf + dataset + sorted-pair root recompute from public leaves. Null/absent on non-protocol resources. |
| trust_score_basis | No | Provenance of the score; ALWAYS the free heuristic, never the paid 42k corpus. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds valuable behavioral context: it is free, provides a heuristic trust_score (not full corpus), and explains the response interpretation. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loaded key information. While concise overall, it could be slightly streamlined to reduce line count without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 optional parameters, output schema exists), the description adequately explains the decision response and trust_score. It might lack error handling details, but for a pre-spend gate the coverage is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 8 parameters. The description adds clarifying value by specifying the mutual exclusivity of seller_wallet and resource_name, which aids parameter selection beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a free pre-spend gate that checks a decision (block/warn/allow) and provides a trust_score. It distinguishes itself from sibling tools by contrasting with the corpus-backed score tool, making its specific purpose and uniqueness evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (before paying) and how to invoke it (provide seller_wallet or resource_name). It contrasts with the alternative GET endpoint for corpus-backed scores, clarifying when each should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_solana_market_onchain_trades_summaryARead-onlyIdempotentInspect
Returns recent on-chain trade and settlement activity.
- With `ticker`: raw per-market trade rows from the live by-market feed
(/onchain-trades-by-market).
- Without `ticker`: aggregated counts across all markets
(total_trades_observed, distinct_markets_observed, markets_sample) from
/onchain-trades-summary.
The two branches return DIFFERENT shapes (raw rows vs aggregated counts).
Tickers are prediction-market event tickers (e.g. KXUSNFP-26MAY01). On failure
returns a structured {status:"error", kind, retryable, detail} envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional prediction-market event ticker (e.g. KXUSNFP-26MAY01); omit for the global recent-trades summary. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent. Description adds that branches return different shapes (raw rows vs aggregated counts) and that failures return a structured error envelope. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, using bullet points for clarity. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the two execution paths and error format. With good annotations and an output schema, this is complete. Could optionally mention data freshness or limits, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (ticker) is well described in schema (100% coverage). The description adds crucial context about its optionality and the resulting two output shapes, which is valuable beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns on-chain trade and settlement activity, distinguishes two operational modes based on ticker presence, and differentiates from sibling tools like get_solana_market_orderbook_depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use with vs without ticker, including the different return shapes. Does not explicitly say when not to use compared to alternatives, but the two-branch explanation is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_solana_market_orderbook_depthARead-onlyIdempotentInspect
Returns normalized orderbook depth and liquidity profile for a specific ticker
from Solana Market API data.
Tickers are prediction-market event tickers (e.g. KXUSNFP-26MAY01), not spot
DEX symbols. Free discovery tool. On failure returns a structured
{status:"error", kind, retryable, detail} envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Prediction-market event ticker, uppercased (e.g. KXUSNFP-26MAY01). NOT a spot token symbol. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds error envelope format and 'free discovery tool' note, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. Front-loaded purpose, then clarifying constraints, then failure behavior. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single parameter with full schema coverage, annotations present, output schema exists. Description covers input, behavior, and error response, making it complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already covers ticker semantics. Description repeats the same info without adding new meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Returns' and resource 'normalized orderbook depth and liquidity profile' for a specific ticker. Distinguishes from siblings by clarifying tickers are prediction-market event tickers, not spot DEX symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states tickers are prediction-market event tickers (not spot symbols) and calls it a 'Free discovery tool'. No explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_solana_market_shapeARead-onlyIdempotentInspect
Returns market shape / structure signals for a ticker (concentration, venue
fragmentation, settlement patterns).
Excellent for understanding *how* a market actually trades on-chain. Tickers
are prediction-market event tickers (e.g. KXUSNFP-26MAY01). On failure returns
a structured {status:"error", kind, retryable, detail} envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Prediction-market event ticker, uppercased (e.g. KXUSNFP-26MAY01). NOT a spot token symbol. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. Description adds error behavior ('On failure returns a structured {status:"error", kind, retryable, detail} envelope'), which is beneficial. However, no details on success response shape (e.g., what fields are returned) despite no output schema being provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, context with ticker format, error behavior. Front-loaded with main purpose, no extraneous information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter and annotations providing safety, description covers error envelope but omits success output structure. With many sibling tools, the description sufficiently differentiates context but could elaborate on what 'concentration, venue fragmentation, settlement patterns' entail. Adequate but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter 'ticker' with a description. Tool description merely repeats that tickers are prediction-market event tickers (e.g., KXUSNFP-26MAY01) and not spot tokens. No additional semantic value beyond schema; baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns market shape/structure signals (concentration, venue fragmentation, settlement patterns). Distinguishes from siblings like trades summary, order book depth, status, and visibility map by focusing on how a market trades on-chain. Specifies ticker format as prediction-market event tickers (e.g., KXUSNFP-26MAY01).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context of use ('Excellent for understanding how a market actually trades on-chain') and explicitly warns tickers are NOT spot token symbols, preventing misuse. Does not explicitly state when to use vs alternatives like get_solana_market_onchain_trades_summary, but the distinct focus on structure implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_solana_market_statusARead-onlyIdempotentInspect
Health probe for the Solana Market API data backend.
Call this to gate or degrade gracefully BEFORE the other get_solana_market_*
tools: it does a short-timeout hit on the data service and reports whether it
is reachable, so an agent can tell "market has no data" from "service is down"
without failing a real query.
Free discovery tool. When TWZRD_DFLOW_DATA_FIRST_URL points at a Rust server
with the new /status, the response includes prod_key_configured, data_first_available,
and an actionable note (e.g. "set WZRD_DFLOW for full on-chain visibility").
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| score | No | Normalized velocity score 0.0-1.0. |
| trend | No | Velocity trend: rising | stable | declining. |
| detail | No | Human-readable status or error detail. |
| available | No | True if the Solana Market data service responded. |
| velocity_rank | No | Velocity rank from dflow signals (higher better). |
| dflow_velocity | No | Full velocity payload when present (rank/trend/score/last_updated). Populated into ReadinessCard.root_provenance.dflow_velocity for WZRD protocol resources. |
| base_url_configured | No | Whether the market data-service base URL is explicitly configured. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds value by disclosing the short-timeout behavior and the specific fields in the response depending on the backend. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, usage guidance, behavior, and response details. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description covers all necessary aspects: purpose, usage, behavioral details, and response content. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter meaning. Baseline for 0 parameters is 4, and the description does not include irrelevant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a health probe for the Solana Market API data backend, with a specific verb and resource. It distinguishes itself from sibling tools by its role as a gating/discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this before other get_solana_market_* tools for graceful degradation, and it explains the benefit. It does not mention when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_solana_market_visibility_mapARead-onlyIdempotentInspect
Returns the current Solana Market API visibility map (which markets have meaningful
on-chain settlement activity and liquidity signals).
Returns metadata-market count, on-chain-trade-market count, their overlap
(decodable_overlap), coverage_pct, and sample tickers unique to each side.
Free discovery tool. On failure returns a structured {status:"error", kind,
retryable, detail} envelope (call get_solana_market_status to disambiguate).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; description adds details about return fields (counts, overlap, coverage_pct, sample tickers) and explicit error envelope structure, exceeding what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. The first sentence is slightly long but remains clear and efficient. Could be marginally tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return content, error behavior, and links to a sibling for disambiguation. Given no parameters, rich annotations, and existing output schema, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters; description does not need to add parameter info. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it returns the Solana Market API visibility map, specifying content (markets with on-chain settlement and liquidity signals) and distinguishes from sibling get_solana_market_status for error disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes it as a 'free discovery tool' and advises using get_solana_market_status on failure, but does not discuss when to avoid using it or compare to other siblings beyond error cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_intel_agentsARead-onlyIdempotentInspect
Leaderboard of the most active paying agents on the network, each with its
real intel score. The free discovery flywheel: find credible counterparties
by actual on-chain payment activity.
Ranks by the wash-discounted effective_score (single-counterparty fleets are
demoted, not hidden) with a deterministic tiebreaker. Set min_paid_calls to
suppress one-shot wallets and max_days_since_last to suppress dormant ones.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked agents to return (default 10). | |
| min_paid_calls | No | Filter out wallets with fewer than this many observed paid calls (default 0 = no filter). Use to get credible *active* counterparties, not a raw dump. | |
| max_days_since_last | No | Only include wallets active within this many days (default null = no recency filter). Use e.g. 14 to get a feed of currently-active agents and exclude dormant/historical payers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | Number of rows returned. |
| error | No | Present only on the degraded path. |
| agents | No | Ranked agent rows, each with intel_score, effective_score, wash fields, and rank. |
| score_model | No | Self-describing scoring contract. |
| score_version | No | Scoring contract version. |
| data_available | No | False when the corpus/DB was unavailable. |
Tool Definition Quality
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: the ranking is based on a wash-discounted effective_score, single-counterparty fleets are demoted not hidden, and tiebreaker is deterministic. This goes beyond annotations to inform agent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no fluff. The first sentence immediately states the tool's purpose. Subsequent sentences add ranking logic and filter usage. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (ranking algorithm, filtering), the description fully explains the behavior. Output schema exists so return values are covered. The description is self-contained and sufficient for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds extra context by explaining the intent of the filters: suppress one-shot wallets and dormant agents. This enriches the agent's understanding of when to use each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a leaderboard of the most active paying agents ranked by real intel score. The verb is implied (list/rank) and resource is 'top intel agents'. It distinguishes from sibling tools like score_wallet_for_intel which scores individual wallets, and get_counterparties which may list counterparties differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose as a discovery flywheel for credible counterparties and gives explicit usage for filters: min_paid_calls to suppress one-shot wallets and max_days_since_last to suppress dormant ones. It does not explicitly contrast with siblings but provides enough context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_wash_fleetARead-onlyIdempotentInspect
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Solana wallet public key (32-44 base58 chars) to check for circular-flow / wash behavior. |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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. |
| 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". |
| reciprocal_events | No | Events forming a 2-cycle (counterparty also pays this wallet). |
| distinct_merchants | No | Distinct merchants this wallet paid. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint). It details return values (classification, is_circular, event counts, distinct_merchants), notes fail-open behavior ('DB gap returns 'unknown''), and clarifies what is NOT returned (wash_factor/ratio). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three well-structured paragraphs: purpose, return values, and additional notes (fail-open, exclusions). It is front-loaded with the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (wash classification with multiple return fields), the description is complete. It explains the returned fields (classification, is_circular, counts) and handles edge cases (DB gap). The presence of an output schema means return value details are not required, and the description sufficiently covers what the agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'wallet' is fully described in the schema (100% coverage). The description reinforces the schema with additional context ('Solana wallet public key...'), but does not add fundamentally new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'cheap circular-flow (wash) check for a payer wallet.' It specifies the verb ('check'), resource ('payer wallet'), and distinguishes it from siblings by highlighting its focus on wash detection. The mention of 'fast Sybil/wash gate' further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Use as a fast Sybil/wash gate before trusting a counterparty,' providing clear context for when to use the tool. While it does not explicitly list alternatives or when not to use, the sibling list offers broader context. The description implies lightweight usage with 'cheap' and 'free discovery,' which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
low_level_preflightARead-onlyIdempotentInspect
Low-level preflight check. Returns a richer result object including
the upsell path to the paid /v1/intel/trust surface with v6 receipt.
Prefer get_readiness_card for most callers. Use this when you need
max_spend_recommendation_usdc, full_report_hint, or the suggest_full_report
flag. The embedded `readiness_card` carries the SAME full shape as
get_readiness_card_tool (see the outputSchema).
| Name | Required | Description | Default |
|---|---|---|---|
| price_usdc | No | Quoted payment amount in USDC for this intended request. | |
| agent_intent | No | What the agent intends to do with the purchased response or tool. | |
| buyer_wallet | No | Buyer's Solana wallet public key; enables buyer-context evidence in scoring. | |
| resource_url | No | Canonical endpoint URL for the resource, if available. | |
| resource_name | No | Provider or listing identifier to evaluate before payment. | |
| seller_wallet | No | Seller's Solana wallet public key for reputation and spend checks. | |
| marketplace_score | No | Optional marketplace-provided score (0-100) for blend-in scoring context. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Decision-consistent one-line rationale. |
| decision | No | Spend decision: "allow" | "warn" | "block". |
| evidence | No | Evidence bullets behind the decision. |
| trust_score | No | Composite trust signal, 0-100. |
| readiness_card | No | The full ReadinessCard shape (same keys as get_readiness_card_tool). |
| full_report_hint | No | How to fetch the paid full report. |
| paid_trust_endpoint | No | Paid trust endpoint path, if seller identity is known. |
| suggest_full_report | No | Whether to upsell the paid v6-receipt report. |
| max_spend_recommendation_usdc | No | Suggested per-call spend ceiling for this decision. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds behavioral context on the return shape, including the upsell path and that the embedded readiness_card matches the output of get_readiness_card_tool, providing useful transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, each sentence adds distinct value: purpose, richer result, usage guidance, and output shape relation. No fluff or repetition. Front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, output schema, and annotations, the description is fairly complete. It covers purpose, usage context, and output relationship. It does not detail error conditions or prerequisites, but these are less critical given the read-only nature. Slight gap on what 'preflight check' entails, but sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is well-described in the schema. The description does not add extra meaning for the parameters, describing only the outputs. Baseline score of 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'low-level preflight check' that returns a richer result object with an upsell path and specific fields. It distinguishes itself from the sibling get_readiness_card_tool by noting what additional fields it provides, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer get_readiness_card for most callers. Use this when you need max_spend_recommendation_usdc, full_report_hint, or the suggest_full_report flag.' This clearly tells when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_wallet_for_intelARead-onlyIdempotentInspect
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).
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).
For the full corpus-breadth renormalized model (intel_renorm_v1: score_raw,
confidence, breadth_factor, wash_factor) + signed portable v6 receipt, pay for
the HTTP surface: GET /v1/intel/trust/{wallet} (0.05 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Solana wallet public key (32-44 base58 chars) to score using x402 payment-history intelligence. |
Output Schema
| Name | Required | Description |
|---|---|---|
| role | No | Observed role: "payer" | "merchant" | "both" | "unknown". |
| basis | No | Human-readable basis line. |
| error | No | Present only on the degraded path. |
| wallet | No | The scored Solana wallet. |
| 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. |
| score_version | No | Scoring contract version. |
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, ensuring safety. The description adds substantial behavioral details: the heuristic formula is returned, output fields are listed (intel_score, effective_score, wash_flag, etc.), failure path returns same shape, and data sourcing is explained. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the main purpose, then efficiently covers the heuristic, output fields, error handling, data source, and paid alternative. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (heuristic scoring, multiple output fields) and the presence of an output schema, the description is highly complete. It covers inputs, outputs, failure handling, data sourcing, and even a paid alternative. All necessary context for agent usage is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'wallet'. The description adds context about malformed pubkeys being rejected cleanly, reinforcing the parameter's constraints and behavior. This goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Free discovery: real 0-100 intel score for a wallet from its observed x402 payment history.' It specifies the verb (score/discover), resource (wallet), and scope (from x402 ecosystem). Distinguishes from siblings like compare_wallets or get_counterparties by focusing on a single wallet's score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by contrasting the free basic score with the paid full model: 'For the full corpus-breadth renormalized model ... pay for the HTTP surface.' It implies when to use this tool (basic free discovery) vs. alternatives (paid for richer model). However, it does not explicitly compare to sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_wallets_batchARead-onlyIdempotentInspect
Free discovery: score up to 25 wallets in a single call (each via the same
transparent model as score_wallet_for_intel). Convenience for triaging a set of
candidate counterparties at once; `requested`/`capped` disclose any truncation.
| Name | Required | Description | Default |
|---|---|---|---|
| wallets | Yes | List of Solana wallet pubkeys to score in one call (hard cap 25; extras are dropped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | Number of wallets scored. |
| error | No | Present only on the degraded path. |
| capped | No | True if the request exceeded max_per_call. |
| results | No | Per-wallet score objects (same shape as score_wallet_for_intel). |
| requested | No | Number of valid wallets requested. |
| max_per_call | No | Hard cap on wallets per batch call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it is a 'free discovery' tool, up to 25 wallets, and that requested/capped fields disclose truncation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. The key facts (free discovery, batch size, model reference, truncation disclosure) are front-loaded and efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately covers the batch cap and truncation handling. All context needed for a batch scoring tool is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'wallets' is described in the schema with a clear description including the hard cap. The tool description adds no additional parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores up to 25 wallets in a single call using the same model as score_wallet_for_intel. It distinguishes from the single-wallet sibling by emphasizing batch triaging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates use for triaging candidate counterparties at once and mentions truncation disclosure. It implies when to use but does not explicitly state when not to use or contrast with all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_receiptARead-onlyIdempotentInspect
Free utility: offline-verify a portable v5/v6 trust receipt — the "after you pay"
half of the loop.
Recomputes the Keccak256 leaf from the receipt's preimage (tamper-evidence) AND
verifies the Ed25519 signature against the published TWZRD receipt-signing key
(authenticity). Returns valid/leaf_valid/signature_valid plus the recomputed
leaf and any errors. Pure and offline — no DB, no network, no payment.
Pass the entire PaidReceipt object you were issued. Trust is anchored on the
published key (or expected_pubkey), NOT on whatever pubkey the receipt carries.
max_age_seconds: optional freshness gate (replay protection). Same semantics
as the Python library verify_paid_receipt(..., max_age_seconds=...) and the
standalone CLI --max-age.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The full v6 PaidReceipt object (leaf + preimage + signature + signing_pubkey) returned by the paid /v1/intel/trust surface. | |
| expected_pubkey | No | Override the trusted signing pubkey to verify against (default: the published TWZRD receipt key). | |
| max_age_seconds | No | If > 0, reject the receipt if its preimage.timestamp_unix is older than this many seconds (replay/freshness protection, same as CLI --max-age and library). | |
| require_signature | No | Require and verify the Ed25519 signature (default true). Set false only to inspect an unsigned preview. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | No | True iff the leaf recomputes AND the signature verifies against the trusted key. |
| domain | No | The V5 domain detected in the preimage. |
| errors | No | Issues found; empty on success. |
| leaf_valid | No | True iff the Keccak256 leaf recomputes from the preimage. |
| provided_leaf | No | The normalized leaf supplied in the receipt. |
| signing_pubkey | No | The pubkey carried by the receipt. |
| trusted_pubkey | No | The published key authenticity was checked against. |
| recomputed_leaf | No | The leaf recomputed from the preimage (0x...). |
| signature_valid | No | True iff the Ed25519 signature verifies; None if the signature check was skipped. |
| signature_checked | No | Whether the signature was checked (require_signature). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds rich behavioral detail: explains the verification logic (Keccak256 leaf recomputation and Ed25519 signature verification), mentions return fields (valid/leaf_valid/signature_valid plus leaf and errors), and describes freshness guarantees (max_age_seconds for replay protection). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-organized: purpose first, then procedure, then usage, then parameter details. Every sentence adds value. It is concise yet comprehensive, with no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, multiple parameters, output schema exists), the description is fully complete. It covers purpose, behavior, usage, parameter semantics, and return values. The mention of Python library and CLI provides helpful cross-reference. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with descriptions. The description adds significant context: explains the receipt parameter as the full PaidReceipt object from the trust surface, clarifies expected_pubkey overrides the trusted key (not the receipt's embedded key), and describes max_age_seconds as replay protection consistent with Python library and CLI. It also notes require_signature default true and use for unsigned preview.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a free utility to offline-verify a portable v5/v6 trust receipt (the 'after you pay' half of the loop). It specifies exact steps: recomputes Keccak256 leaf for tamper-evidence and verifies Ed25519 signature for authenticity. This distinguishes it from sibling tools like compare_wallets or get_counterparties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: after receiving a PaidReceipt from the paid /v1/intel/trust surface. It instructs to pass the entire PaidReceipt object and clarifies trust anchoring. It specifies it is pure and offline with no DB/network/payment, establishing safe usage context. Though no negative guidance is given, the tool's unique purpose among siblings makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_root_inputsCRead-onlyIdempotentInspect
Independent root verification (see tools/root_verifier.py for the recompute logic).
| Name | Required | Description | Default |
|---|---|---|---|
| root_seq | No | Specific root sequence to verify. If omitted, best-effort resolution via resource metadata or latest. | |
| resource_name | No | WZRD protocol resource (deposit/claim/settle etc.) for auto-detection and seq hints. | |
| seller_wallet | No | Seller wallet for WZRD protocol resource detection. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Error message on the ERROR path; null on PASS/FAIL. |
| status | No | "PASS" = recomputed GLOBAL_V5 leaves + dataset_hash + sorted-pair root match the published values. "FAIL" = mismatch (do not trust the root). "ERROR" = could not run (fetch failure / missing data). |
| root_seq | No | Root sequence number that was verified. |
| leaf_count | No | Number of leaves (users) in the verified root. |
| onchain_match | No | Always null: this tool does NOT read Solana/the AO program. Use server_consistent for the recompute result; do not gate on-chain actions on this field expecting a chain anchor. |
| leaf_hash_match | No | True iff every server-provided leaf_hash matches the locally recomputed value. |
| recomputed_root | No | Independently recomputed sorted-pair keccak256 merkle root (hex). |
| server_consistent | No | True iff the recomputed root/dataset_hash matches the value the SERVER published alongside its own leaves (self-consistency). NOT an on-chain check. Null when not comparable. |
| recomputed_dataset_hash | No | Independently recomputed keccak-concat dataset_hash (hex). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds minimal value beyond mentioning 'Independent' and a reference to recompute logic, which does not disclose concrete behavioral traits like side effects or data consumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but includes a reference to an external Python file that is inaccessible to an AI agent. This reference wastes space and does not aid understanding. The core purpose is front-loaded, but irrelevant detail reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to connect the verification action to the tool's parameters (e.g., 'root_seq', 'resource_name', 'seller_wallet'). The term 'root' is undefined, and the domain context (WZRD protocol) is implicit in the schema but not explained. The agent lacks sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters with descriptions. The tool description does not add any additional meaning or usage guidance beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Independent root verification' but does not clarify what 'root' refers to, leaving the tool's core purpose ambiguous. It fails to distinguish the tool from siblings like 'verify_receipt' or 'low_level_preflight', which could also perform verification tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about use cases, prerequisites, or exclusions, leaving the agent without direction for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!