TWZRD Agent Intelligence
Server Details
Trust + receipt layer for x402 agents on Solana: free preflight + paid signed V5 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.4/5 across 16 of 16 tools scored. Lowest: 3.9/5.
Most tools have distinct purposes, but there is some overlap between dexter_preflight and get_readiness_card_tool, and between score_wallet_for_intel and score_wallets_batch. However, descriptions clearly differentiate them, so only minor ambiguity exists.
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_counterparties, is_wash_fleet, verify_receipt). No mixing of conventions.
16 tools cover the complex domain of wallet intelligence and Solana market data comprehensively. Each tool serves a clear purpose without overloading the interface.
The tool set provides a thorough free discovery surface for wallet intelligence, including scoring, wash detection, counterparty analysis, leaderboards, and market data. Minor gaps exist (e.g., no free full transaction history), but these are intentionally reserved for paid tiers.
Available Tools
16 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.
dexter_preflightARead-onlyIdempotentInspect
Low-level Dexter preflight check. Returns a richer result object including
the upsell path to the paid /v1/intel/trust surface with V5 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 V5-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=true and idempotentHint=true, so the description builds on that by detailing the richer output (upsell path, V5 receipt, readiness_card shape). It adds behavioral context beyond safety.
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 four sentences, each serving a distinct purpose: core function, output richness, usage guidance, and output relationship to sibling. No wasted words; front-loaded with 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 presence of an outputSchema, the description explains the key output fields and their relationship to a sibling tool. All 7 parameters are optional and described in the schema. The guidance clarifies the tool's role in the broader set.
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 the baseline is 3. The description focuses on output and usage, not on parameter meanings. It does not add extra semantics 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 it is a 'Low-level Dexter preflight check' and explicitly distinguishes it from the sibling tool 'get_readiness_card'. It specifies the verb+resource and indicates the richer result object with specific fields.
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 explicit guidance: 'Prefer get_readiness_card for most callers. Use this when you need...' and lists the specific output fields that justify using this tool over alternatives.
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 V5 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 declare readOnlyHint and idempotentHint true. The description adds significant behavioral context: it is fail-open (returns 'unknown' on DB gap rather than erroring), and describes the signals used (unique payers, repeat-payer %, etc.). 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 relatively detailed but each sentence adds value: purpose, signals, fail-open behavior, complementarity, and paid alternative. It is well-structured and front-loaded with the core purpose. A minor trim could be possible, but overall 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 the complexity (multiple signals, output schema), the description provides a thorough overview: input, output (wash_label, tier, flagged), time window (90 days), fail-open behavior. It lacks detail on each signal but the output schema likely covers that. Completeness is high.
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 baseline is 3. The description adds meaning by explaining that 'merchant' is a Solana wallet public key (pay_to address) used for inbound corpus reputation. This enriches the schema 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 tool is for free discovery of corpus-backed seller reputation for a merchant/provider wallet. It specifies the verb (get), resource (provider reputation), and scope (seller side). It distinguishes itself from sibling tools like 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 explicitly says when to use: for seller side reputation, complementary to score_wallet_for_intel. It also provides fail-open behavior on DB gap and contrasts with the paid alternative at GET /v1/intel/trust/{wallet}. This gives clear guidance on usage and alternatives.
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
Returns an agentic readiness card for a provider or x402 resource.
Answers four questions before an agent pays:
- can_spend: bool — is it safe to spend on this resource?
- trust_score: 0-100 — composite trust signal
- proof: dict — V5 receipt upsell path, known wallets, provider reputation
- caveats: list[str] — risk factors and negative signals
- next_fixes: list[str] — what the provider should fix to improve trust
- decision: "allow" | "warn" | "block"
- trust_score_basis: str — ALWAYS a free heuristic from the small internal
registry + Dexter marketplace signals (dexter_heuristic_registry_v0:*).
This is NOT the real 42k+ cross-facilitator x402 corpus. The full corpus
(x402_payment_receipts + intel_renorm_v1 + signed V5 receipt) is paid-only,
via GET /v1/intel/trust/{wallet}. A caveat always restates this.
Also returns: resource_name, seller_wallet, category, price_usdc,
paid_deep_dive, paid_price_usdc (see the outputSchema for the full contract).
Provide at least one of resource_name or seller_wallet.| 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 dexter: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. |
| 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 indicate read-only and idempotent, which the description does not contradict. The description adds significant behavioral context: explains the trust_score_basis is always a free heuristic from a small registry, that a caveat restates this, and that the full corpus is paid-only. 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 front-loaded with the purpose and return fields, followed by key explanatory notes. It is somewhat verbose but well-structured and each sentence adds value. Could be slightly more concise.
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 parameters, output schema present), the description covers the main points: what it returns, data limitations, and parameter hints. It does not explain 'agentic readiness' in depth, but the output schema provides full return contract. Adequate for confident use.
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 schema already documents all 8 parameters. The description adds minimal parameter-specific meaning beyond reinforcing the requirement to provide resource_name or seller_wallet. Baseline of 3 is appropriate.
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 returns an agentic readiness card for a provider or x402 resource, and lists the specific fields returned. It distinguishes from sibling tools by its focus on readiness with caveats and free vs. paid data.
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 context on when to use the tool (before an agent pays) and explains the limitation of the free heuristic versus the paid full corpus via another endpoint. It also specifies to provide at least one of resource_name or seller_wallet. However, it lacks explicit guidance on when not to use this tool vs. alternative siblings like get_provider_reputation.
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.| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | Human-readable status or error detail. |
| available | No | True if the Solana Market data service responded. |
| 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 indicate readOnlyHint and idempotentHint, so description adds value by detailing the short-timeout hit and reachability reporting. 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?
Highly concise, front-loaded with purpose, then usage, then extra note. Every sentence is necessary and informative.
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?
For a simple health probe with zero parameters and an output schema, the description covers purpose, usage, and key behavioral notes fully.
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?
No parameters exist, baseline is 4. Description does not need to add parameter info as schema coverage is 100%.
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?
Description clearly states it is a health probe for Solana Market API, with verb 'health probe' and resource 'Solana Market API data backend'. It distinguishes from sibling tools by specifying it is used before other get_solana_market_* tools.
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 says to call this 'to gate or degrade gracefully BEFORE the other get_solana_market_* tools', providing clear when-to-use context and differentiating from alternatives.
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.
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 V5 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=true and idempotentHint=true. The description adds significant value beyond this by detailing the heuristic formula, return fields (intel_score, effective_score, wash_flag, etc.), error handling for malformed pubkeys, data source, and the exact failure path shape.
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 informative and front-loaded with purpose, but slightly verbose with details about the paid endpoint and Rust HTTP. Every sentence adds value, but it could be tightened slightly without losing meaning.
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 single parameter and presence of an output schema (not shown here but referenced), the description fully covers the tool's behavior: what it does, how the score is computed, what is returned, error handling, and alternative paid version. No significant gaps.
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 reinforces its purpose but does not add new semantic details beyond the schema. Baseline 3 is appropriate.
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 verb 'score' and the resource 'wallet for intel', with a specific scope (0-100 score based on x402 payment history). It distinguishes from siblings like 'score_wallets_batch' (batch) and 'compare_wallets' (comparison) by emphasizing the individual, free discovery nature.
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?
It mentions 'Free discovery' and contrasts with a paid version for a more comprehensive model, implying when to use this free tool vs alternatives. However, it does not explicitly state when to use other siblings like 'get_counterparties' or 'is_wash_fleet'.
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 valuable behavioral context: the hard cap of 25, truncation behavior, and that it uses the same transparent model as score_wallet_for_intel. This goes beyond the annotations to inform the agent about limits and output structure.
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 concise sentences with no unnecessary words. It is front-loaded with the key information ('Free discovery: score up to 25 wallets'), and every word earns its place, avoiding redundancy with the schema or annotations.
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 that an output schema exists (per context signals), the description does not need to detail return values. It covers purpose, usage context, the batch size limit, and truncation disclosure. For a tool of moderate complexity with good annotations, this is fairly complete, though a brief note about idempotency consistency could be added.
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 schema covers the single parameter with a description (100% coverage). The tool description reinforces the hard cap and adds the behavior that `requested`/`capped` disclose truncation, which provides output context not evident from the schema alone. This adds semantic value 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 states the tool scores up to 25 wallets in a single call using the same model as score_wallet_for_intel. It distinguishes itself from sibling tools like score_wallet_for_intel (single) and compare_wallets (comparison) by noting its batch capability for triaging candidate 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 provides clear usage context: 'Convenience for triaging a set of candidate counterparties at once.' It implicitly suggests when to use over single scoring, but does not explicitly state when not to use or mention alternative tools. The disclosure of truncation via `requested`/`capped` adds operational guidance.
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 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.| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The full V5 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). | |
| 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?
Beyond annotations (readOnlyHint, idempotentHint), the description adds significant behavioral context: pure offline operation, no DB/network/payment, trust anchored on published key, and the specific verification steps.
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?
Five sentences, each adding value: purpose, verification details, usage instruction, return format, and trust note. No fluff, well front-loaded.
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 rich annotations, complete input schema, and output schema presence, the description covers return values and verification logic sufficiently. No gaps identified.
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% of parameters with descriptions. The description adds minimal additional meaning (e.g., 'Pass the entire PaidReceipt object'), but does not significantly enhance understanding 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 uses specific verbs ('recomputes', 'verifies') and clearly identifies the resource ('V5 trust receipt'). It distinguishes from unrelated siblings by focusing on offline verification, a unique function.
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 the tool as a free, offline utility and instructs to 'Pass the entire PaidReceipt object you were issued.' However, it lacks explicit when-to-use or when-not-to-use guidance, though siblings are unrelated.
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!