TWZRD Agent Intelligence

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

Annotations already declare readOnlyHint and idempotentHint; description adds details about return value (both full score objects, ranking, tie/unavailability handling). No contradictions and adds meaningful 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?

Two sentences with maximum information density. Front-loaded purpose and returns, no filler. Every word earns its place.

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 output schema exists, the description adequately explains the return value (score objects, ranking, metric). It could mention what a 'score object' contains, but that is handled by the schema. Overall complete for a comparison 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% and the input schema already describes the parameters as wallet pubkeys. The tool description does not add extra meaning beyond the schema, so 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 'side-by-side intel for two wallets' with a specific use case example. It distinguishes from siblings like score_wallet_for_intel (single) and score_wallets_batch (batch) by focusing on pairwise comparison and ranking output.

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 ('Free discovery') and an example ('choosing between two candidate providers'), but does not explicitly exclude alternative tools or mention when not to use. The context is clear enough for typical use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate readOnly and idempotent. The description adds depth by detailing the extraction of seller wallet, TWZRD preflight, decision outcomes, and revenue path for 'warn'. It discloses that a purchase may be needed in the 'warn' case, which is crucial behavioral information. 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 moderately concise, with a clear front-loaded definition of purpose. It uses a bullet-like format for decisions, which aids readability. However, the revenue path explanation could be condensed. Overall well-structured but slightly verbose.

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 4 parameters (1 required), a rich description, and an output schema (implied), the description covers all important aspects: purpose, inputs, behavior, decision outcomes, and subsequent steps. It leaves no significant gaps for an AI agent to understand invocation and results.

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 baseline is 3. The description does not add significant meaning beyond the schema; it mentions using 'resource_url' and overriding 'price_usdc', but these are already described in the schema. No additional semantics for parameters.

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 'one-shot x402 guard' that evaluates a resource and returns a spending decision. It specifies the action (fetches, extracts, runs preflight) and the output (decision). The purpose is specific and distinct from sibling tools which focus on wallets, markets, and directories.

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 when to use: before paying an x402 resource. It provides decision outcomes and a revenue path for 'warn', guiding subsequent actions. It does not explicitly state when not to use, but the context and sibling comparisons make it clear. Slightly lacking in exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds that it's a 'capped teaser,' explains the cap mechanism, mentions full paid intel is elsewhere, and states 'Fail-open.' This provides useful behavioral context not in 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 that front-loads the main purpose, then adds details about cap and paid intel. It is concise and well-structured, though a slight reorganization could improve readability.

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 (2 params, output schema present), the description covers purpose, parameters, limitations, and behavioral quirks. 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 coverage is 100%, so the schema already documents both parameters (wallet, limit). The description reinforces that the limit is a capped teaser, adding minor context but not substantial new 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 it's a free discovery tool for top-N merchants a wallet pays, with per-edge details. It uses specific verbs ('discover', 'list') and distinguishes from sibling tools by focusing on counterparties of a wallet.

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 'See WHO a counterparty transacts with before trusting it,' providing clear context for when to use. However, it does not mention when not to use or list alternative tools, which would be helpful given the many sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations declare readOnlyHint and idempotentHint=true. Description adds crucial behavior: 'Fail-open: a DB gap returns data_available=false rather than erroring,' which is not in annotations. Also explains output structure (facilitator_ids, tx/merchant context) beyond schema.

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, significance interpretation, and error handling. No redundant words, front-loaded with key insight. Extremely concise and 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?

Given output schema existence (not shown but referenced), description is complete: explains what is returned (facilitator_ids, tx/merchant context), how to interpret results, and error behavior. No gaps for a discovery 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 has 1 parameter (wallet) with description, 100% coverage. Description adds meaning by explaining how the returned data should be interpreted (unique_facilitators significance), providing context beyond parameter 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?

Description clearly states the tool discovers which x402 facilitators a payer has settled through and how many, with specific verb 'discovery' and resource 'facilitator footprint'. Differentiates from sibling tools by focusing on facilitator settlement breadth, not covered by any sibling name.

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?

Description implies use for discovering facilitator footprint and interpreting results (e.g., unique_facilitators=1 means captive agent), but does not explicitly state when to use this tool vs alternatives like compare_wallets or get_counterparties. No when-not-to-use guidance provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint, so the tool's safety profile is clear. The description adds valuable context: it is free, uses a first-party registry for resolution, and explicitly states what it does NOT cover ('resource_listing_only / catalog_listing_only'). 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 with four sentences, no redundancy. It front-loads the core purpose and then provides necessary technical details (dual input, resolution, limitation). Every sentence earns its place.

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 adequately covers the tool's behavior: input options, resolution process, what the tool does not provide, and its HTTP twin. No critical gaps for an agent to select or invoke 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 coverage is 100%, and both parameters have descriptions. The tool description adds meaning beyond the schema by explaining the dual input (wallet and/or resource_id) and how resource_id is resolved via the registry. It also clarifies that the output is the same graph card regardless of input method.

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 'Free merchant card' that 'demands quality around a Solana receive wallet,' indicating the tool retrieves a merchant card for a wallet or resource ID. It distinguishes from claiming service quality by noting 'Does NOT claim service quality,' which adds specificity. However, the phrasing 'demand quality around' could be more direct.

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 dual input mechanism and that it does not claim service quality, implying a specific use case. However, it does not explicitly state when to use this tool vs. alternatives like 'get_readiness_card_tool' or other sibling tools, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate readOnly and idempotent. Description adds fail-open returning 'unknown' instead of erroring, and distinguishes free vs paid tiers. 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?

Front-loaded with key purpose, then details. Every sentence adds value, though slightly verbose in listing metrics (could be shortened). Still clear and 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?

With output schema present, description fully explains inputs, outputs, and behavior. Covers specific metrics, error handling, and commercial context. Complete for tool 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?

Only one parameter with full schema description. Description adds context about the parameter being a Solana wallet pay_to address, but schema already covers it. Slight additional value.

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 the tool provides seller reputation from inbound payment graph, answering specific questions. Distinguishes from sibling score_wallet_for_intel by specifying seller side vs 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?

Explicitly states it complements score_wallet_for_intel, mentions fail-open behavior, and notes the paid alternative for more detailed analysis. Provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by explaining the advisory nature, free pricing, and decision semantics (block/warn/allow) beyond what annotations provide. 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?

The description is well-structured with bolded terms and sections, but slightly verbose. Front-loaded with purpose, yet includes extra context like decision semantics and next steps. Still clear and 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?

Covers all necessary context: purpose, usage, decision semantics, output fields, next actions (paid intel, verify_receipt), and optional parameters. Output schema exists but description still explains key return fields.

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%, but the description adds crucial guidance: 'Pass seller_wallet OR resource_name.' This mutual exclusivity is not in the schema descriptions, enhancing parameter understanding.

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 'PRIMARY free pre-spend gate (advisory)' with explicit verb 'get readiness card'. It distinguishes from siblings by specifying it is used before payments, contrasting with verify_receipt and other 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?

Explicit 'When to use: before any x402 payment' and 'When not to use: after you already decided to refuse; use verify_receipt for signed receipts only' provide clear guidance and reference alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: different output shapes for each branch and a structured failure envelope, which goes beyond 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?

The description is concise and well-structured, with the main purpose stated first, followed by clear bullet-point-like explanations for each branch. Every sentence adds necessary information 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 (two branches, different shapes, failure envelope) and the presence of an output schema, the description covers the essential aspects. It lacks only minor details like rate limits, but is generally 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?

Schema coverage is 100%, so the schema defines the parameter. The description adds value by explaining the ticker is optional, providing an example format, and describing the behavioral difference with/without it.

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 recent on-chain trade and settlement activity, with two distinct branches depending on whether a ticker is provided. It differentiates from sibling tools like get_solana_market_orderbook_depth by focusing on trades summary.

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 when to use with ticker (per-market raw rows) vs without (aggregated counts), providing clear context. It does not explicitly exclude alternatives, but the context is sufficient for correct usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint as true. The description adds useful behavioral context by noting it is a 'Free discovery tool' and detailing the failure response format (structured error envelope), which exceeds 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?

The description is three sentences long, front-loading the core purpose. It is concise without redundancy, though the ticker clarification could be integrated more tightly.

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 tool with one parameter, annotations, and an output schema, the description covers key aspects: operation, ticker format, cost, and error handling. It is sufficiently complete, though it could briefly mention that the output schema documents the returned depth 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?

The schema provides 100% description coverage for the single parameter 'ticker', including its format and a warning against spot symbols. The description echoes this information without adding new parameter semantics, so 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 ('Returns normalized orderbook depth and liquidity profile') and resource ('a specific ticker from Solana Market API data'). It explicitly distinguishes prediction-market event tickers from spot DEX symbols, differentiating it from sibling tools like get_solana_market_onchain_trades_summary.

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 the tool is a 'Free discovery tool' for orderbook depth, implying usage context. However, it does not specify when to avoid using it or provide direct comparisons to sibling tools, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint. The description adds context about the structured signals returned and the failure envelope with status, kind, retryable, detail, which goes beyond 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?

The description is two sentences with no redundant words. The first sentence states the core functionality, and the second provides use-case context and failure behavior. Front-loaded and 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 presence of an output schema, the description appropriately doesn't detail return values. It covers the ticker semantics, failure behavior, and use-case, which is complete for a simple one-parameter tool with good annotations and 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?

Parameter schema has 100% coverage for the single 'ticker' parameter, which is well-described in the schema with example and note about uppercase. The tool description restates this info, adding slight value but not significantly 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 returns market shape/structure signals (concentration, venue fragmentation, settlement patterns) for a ticker, specifying that tickers are prediction-market event tickers, not spot tokens. This distinguishes it 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?

The description says it's excellent for understanding how a market trades on-chain, implying when to use it, but does not explicitly state when not to use it or compare it with alternatives like get_solana_market_onchain_trades_summary or get_solana_market_visibility_map.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safety. The description adds valuable behavioral details: short-timeout hit, reports reachability, and describes response fields (prod_key_configured, data_first_available, note). 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 well-structured paragraphs, front-loaded with the core purpose. Each sentence adds meaningful content—purpose, usage guidance, and response details—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?

For a zero-parameter health probe with an existing output schema, the description is fully sufficient. It explains when to use, what it does, and what the response includes, covering all necessary context.

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; schema coverage is 100% by default. The description does not need to add parameter details. Baseline score of 4 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 it is a health probe for the Solana Market API data backend, specifies the action 'gate or degrade gracefully', and distinguishes from siblings by advising use 'BEFORE the other get_solana_market_* tools' and explaining the diagnostic differentiation between 'market has no data' and 'service is down'.

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 instructs to use this tool before other market tools to check service reachability, providing clear context. It does not list explicit when-not-to-use scenarios, but the purpose is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by detailing the returned fields (counts, overlap, coverage_pct, sample tickers) and the structured error envelope with retryable flag. This goes beyond annotations and provides clear behavioral expectations.

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: two sentences covering purpose and return structure, plus a brief note on failure behavior and free discovery. 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 has no parameters and an output schema exists (context indicates true), the description adequately covers the essential aspects: what returns, its free nature, failure mode. It doesn't need to exhaustively list all return fields since output schema exists, but could mention the output schema. Still, it is complete enough for an agent.

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 schema coverage is 100% by default. Per guidelines, baseline is 4 for no parameters. The description adds no parameter-specific information, which is appropriate since there are none.

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 'Returns the current Solana Market API visibility map' with a specific verb and resource, and explains it shows markets with meaningful on-chain settlement activity and liquidity signals. It distinguishes from sibling tools like get_solana_market_status or get_solana_market_shape by its unique focus on visibility mapping.

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 notes that on failure, one should call get_solana_market_status to disambiguate, providing some error-handling guidance. However, it lacks explicit when-to-use or when-not-to-use instructions compared to alternative tools, meaning an agent may not know when this tool is preferred over others like get_solana_market_onchain_trades_summary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable behavioral context: ranking by wash-discounted effective_score, demotion of single-counterparty fleets, and deterministic tiebreaker. 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 sentences, each adding value. It is front-loaded with the main purpose. Slightly repetitive with 'free discovery flywheel' 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 tool's complexity (ranking, wash-discounting, optional filters) and the existence of an output schema, the description adequately covers the ranking method, behavior with respect to fleets, and how to use filters. No major 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%, but the description adds meaningful context for min_paid_calls ('get credible *active* counterparties') and max_days_since_last ('e.g. 14 to get a feed of currently-active agents'), augmenting the schema's baseline.

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's a 'Leaderboard of the most active paying agents' and specifies the verb 'find credible counterparties'. It distinguishes from siblings like get_counterparties and score_wallet_for_intel by referencing ranking by wash-discounted effective_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 explicit guidance on when to use the min_paid_calls and max_days_since_last parameters, such as 'Use to get credible *active* counterparties'. It implies use for finding credible counterparties but does not explicitly state when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds value by explaining the merged nature of the directory, the coverage of TWZRD wash overlay (Solana only), the behavior of the 'flagged_only' filter, and cross-chain caveats. 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 reasonably concise, with the main purpose in the first line. However, it includes detailed explanation of the wash overlay and cross-chain caveats, which is useful but slightly verbose. It is well-structured and 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 the presence of an output schema (not shown but indicated), the description adequately covers the tool's purpose, data sources, filtering options, and wash overlay behavior. It is complete for an agent to understand invocation and expected behavior, though it could briefly mention output format.

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%, but the description enriches understanding: it explains that 'flagged_only' returns wash-flagged listings, 'source' filters by specific bazaar (payai_bazaar, cdp_bazaar, agentic_market), and 'limit' controls rows. It also adds context that the wash overlay differentiates listings from different sources.

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 'Combined three-bazaar x402 service directory' that merges PayAI Bazaar, CDP Bazaar, and Agentic Market. It specifies the verb 'get' and the resource 'x402 directory', and distinguishes it from sibling tools like 'get_provider_reputation' or 'get_merchant_card' by focusing on directory 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 does not explicitly state when to use this tool versus alternatives. It mentions query parameters and the wash flag differentiator but lacks guidance on when to choose this over other tools like 'score_wallet_for_intel' or 'low_level_preflight'. Usage context is implied but not direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations (readOnlyHint, idempotentHint) are already present. The description adds critical behavioral details: categorical classification, is_circular bool, event counts, and distinct_merchants. It also describes fail-open behavior ('DB gap returns unknown') and explicitly states what is NOT returned (wash_factor, wash_ratio), enhancing transparency.

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 redundancy. First sentence states purpose, second lists outputs, third explains usage and fail-open behavior. Information is front-loaded and every sentence contributes meaningfully.

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 simple single-parameter structure and the availability of an output schema (context signals), the description fully covers purpose, output fields, failure modes, and exclusions. No gaps remain for an agent to misuse this 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 covers 100% of parameters (wallet). The description adds value by specifying character length range ('32-44 base58 chars') and reiterating the parameter's purpose within the context of the tool, complementing 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 identifies the tool's verb ('check'), resource ('payer wallet'), and specific purpose ('circular-flow/wash detection'). It distinguishes from siblings like 'score_wallet_for_intel' by emphasizing it is a 'fast Sybil/wash gate', setting clear expectations.

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 'Use as a fast Sybil/wash gate before trusting a counterparty', providing clear context. It lacks explicit 'when not to use' mentions but effectively implies its role as a quick preliminary check, differentiating from more comprehensive tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint, so the description focuses on behavioral context beyond safety: it is low-level, returns a richer object with upsell path, and notes the embedded readiness_card shape. This adds useful transparency without contradicting 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: first sets purpose, second gives usage guidance, third clarifies output structure. Every sentence earns its place with no redundancy or 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 7 optional parameters, full schema descriptions, output schema present, and rich annotations, the description covers all necessary context: purpose, when to use vs sibling, and what the output contains (including reference to another tool's shape).

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 each parameter described. The description does not add new parameter-level meaning beyond the existing schema, so 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 it is a 'low-level preflight check' that returns a 'richer result object' including an upsell path. It distinguishes itself from the sibling 'get_readiness_card' by specifying that the embedded readiness_card has the same shape as that 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?

Explicitly advises to 'Prefer get_readiness_card for most callers' and specifies when to use this tool: when needing max_spend_recommendation_usdc, full_report_hint, or suggest_full_report flag. Provides clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate readOnlyHint and idempotentHint; description adds significant behavioral details: heuristic formula, output fields, error handling (malformed pubkeys), data source, and alternative paid endpoint. 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?

Concise yet comprehensive: covers purpose, heuristic, output, error handling, data source, and alternative in a well-structured paragraph. No redundant 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 the tool's complexity (scoring algorithm), description fully covers input, output, model details, failure path, and data provenance. Output schema exists, so return values are documented.

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?

Single parameter 'wallet' has a clear schema description (Solana public key). Description adds context about wallet format and scoring logic, enriching the schema coverage which 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 the tool returns a 0-100 intel score for a wallet based on x402 payment history. It distinguishes from sibling tools by focusing on a single wallet and describing the heuristic formula explicitly.

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?

Implies usage for free wallet discovery but does not explicitly contrast with sibling tools like score_wallets_batch or compare_wallets. Mentions a paid alternative for more detail, providing some context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it uses the same transparent model as score_wallet_for_intel and that requested/capped disclose any truncation. This provides behavioral context beyond annotations, though it could mention rate limits or nothing further is needed.

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 concise sentences with no wasted words. The first sentence states the core purpose and capacity, the second adds context on truncation. 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 the tool is a batch version of a single-wallet tool and there is an output schema, the description covers all essential aspects: purpose, capacity, model, and truncation behavior. No gaps for selection and invocation.

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 parameter 'wallets' is fully described (100% coverage) including hard cap 25 and that extras are dropped. The description reinforces this and adds context on truncation disclosure and model, adding 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, and is a convenience for triaging candidate counterparties. This differentiates it from sibling tools like score_wallet_for_intel (single wallet) and compare_wallets (comparison).

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 it's for 'triaging a set of candidate counterparties at once' and mentions 'Free discovery' implying open use. It doesn't explicitly state when not to use it versus the single-wallet variant, but the batch nature and capacity are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating it spends no USDC and contacts no wallet. It adds behavioral context beyond annotations, explaining the internal gate behavior (block path aborts, allow path proceeds) and the attribution ledger mechanics.

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 fairly long but well-structured: it opens with the core purpose, then explains behavior and limitations. Every sentence adds necessary detail for a complex tool. A slight reduction could improve conciseness, but it remains 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 of the tool (demo gate with attribution) and the presence of an output schema, the description covers all essential aspects: what it does, what it doesn't, how it fits into the system, and what users must do for full verification. It is complete for the intended 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 coverage is 100% (both parameters have descriptions), so baseline is 3. The description adds value by explaining the purpose of each parameter in the broader proof process: run_id for correlation and integration for labeling, along with how they contribute to later confirmation.

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 'runnable, no-spend proof of the TWZRD buyer-side x402 trust gate' that returns a deterministic transcript. It distinguishes from sibling tools by specifying it does not contact wallets or spend USDC, serving as a demo gate rather than a production action.

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 explains when to use this tool (to test the gate without spending) and what it does not do (no wallet contact, no USDC spent). It also provides guidance on limitations (it's a candidate, not a full external run) and alternative steps for full proof, such as using a non-VPS source_ip and the confirmation script.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations provide non-destructive hint, but description adds valuable behavioral details: proactive re-checking, notification posting, and return of recheck_after_unix timestamp. 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?

Three sentences, front-loaded with main purpose, each sentence adds value without redundancy. 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?

Covers purpose, behavior, and return value. Lacks details on error conditions, prerequisites, or behavior without webhook_url, but sufficient for most use cases given existing annotations.

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% description coverage, so baseline is 3. Description adds minimal context beyond schema (e.g., webhook_url purpose), not significantly enhancing semantics.

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 registers a re-call watch on a seller wallet, which is specific and distinct from sibling tools like twzrd_watch_list and twzrd_watch_remove.

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?

Usage is implied (monitor a seller wallet), but no explicit guidance on when to use this vs alternatives, nor when not to use it. The description lacks decision-making context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description adds significant behavioral context beyond the annotations: it details the output structure (seller, score/decision, timestamp) and emphasizes the timestamp's role as a re-call signal. No contradiction with readOnlyHint/idempotentHint.

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 concise sentences with no redundant information. Front-loads the main action and then details output features efficiently.

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 listing tool with single parameter and an output schema, the description covers the essentials. It could mention potential absence of watches or pagination, but given the low complexity, it is sufficiently 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?

Schema coverage is 100%, and the parameter description in the schema ('Your agent wallet address.') is clear. The tool description adds minimal extra meaning for the parameter beyond repeating its purpose in context.

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 lists active re-call watches for the agent wallet and specifies the output fields (seller, score/decision, recheck_after_unix). It effectively distinguishes from sibling tools twzrd_watch_add and twzrd_watch_remove.

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 the tool is for listing watches of the agent's wallet, implying use for monitoring. While it doesn't explicitly state when not to use, the sibling tool names provide context, and the link to 're-call signals' gives clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Description says 'Deactivate' (non-destructive) which aligns with destructiveHint=false. Adds context about ownership requirement 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: one sentence plus a condition, no fluff, front-loaded with action and resource.

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?

Complete for a simple tool with 2 params, full schema coverage, output schema, and sibling context. No missing information.

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 parameter descriptions are clear. Description restates the payer_wallet condition but doesn't add new meaning 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?

Clearly states the action 'Deactivate a re-call watch by ID' and the resource, distinguishing it from siblings like twzrd_watch_add (add) and twzrd_watch_list (list).

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 explicit condition 'payer_wallet must match the owner' which guides correct usage, though does not mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description reinforces this by stating 'Pure and offline — no DB, no network, no payment.' It also details the verification steps and trust model, providing full 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 extremely concise and well-structured. It opens with the core purpose, lists key features, and details parameters in a clear, front-loaded manner. Every sentence adds necessary information without repetition.

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 (cryptographic verification), the description is comprehensive. It covers the algorithm (Keccak256, Ed25519), trust model, all parameters, and the pure/offline nature. The presence of an output schema means return values need not be described.

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 schema documents all parameters. However, the description adds meaningful context: max_age_seconds is explained as 'freshness gate (replay protection)', require_signature for inspecting unsigned preview, and expected_pubkey for key override. This adds 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 is a free utility to offline-verify a portable v5/v6 trust receipt. It specifies the core operations: recomputing Keccak256 leaf and verifying Ed25519 signature. This is distinct from sibling tools that deal with market data, wallet scoring, etc.

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 instructs to pass the entire PaidReceipt object and explains optional parameters like expected_pubkey and max_age_seconds. It clarifies that trust is anchored on the published key, not the receipt's pubkey. While not explicitly contrasting with alternatives, the purpose is so specific that usage is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds little behavioral context. The reference to recompute logic hints at internal processing but doesn't disclose side effects or constraints. Adequate but not insightful.

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 with one sentence and a code reference. No wasted words, but may be too terse for 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 presence of annotations, a robust output schema (not shown but exists), and fully described parameters, the description meets minimal needs but does not explain the concept of 'root verification' or its role among siblings.

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 already provides full descriptions for all three parameters (100% coverage). The description adds minimal extra meaning beyond the schema, so baseline score 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 states 'Independent root verification' which gives a verb and a vague resource, but 'root' is unclear and not distinguished from sibling tool 'verify_receipt'. It lacks specificity on what is being verified.

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 on when to use this tool versus alternatives like verify_receipt or other sibling tools. No context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.