TWZRD Agent Intelligence

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 by detailing the return value, including the effective_score ranking logic and edge cases (tie, null if unavailable). This 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 concise, front-loaded, and uses two sentences to convey purpose, use case, and return behavior with edge cases. Every sentence is informative and necessary.

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 and annotations, the description provides complete context for a two-wallet comparison tool. It covers return values, ranking logic, and special cases, leaving no gaps for the 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?

Input schema has 100% coverage with descriptions for both parameters. The tool description does not add additional parameter details beyond the schema, so it meets the baseline without extra 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?

The description clearly states the tool compares two wallets side-by-side, returns full score objects, and indicates which ranks higher. This specific verb-resource combination (compare wallets) is distinct from sibling tools like score_wallet_for_intel (single wallet) and score_wallets_batch (batch scoring).

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 an example use case (choosing between two candidate providers) but does not explicitly state when not to use this tool or mention alternative tools like score_wallet_for_intel or score_wallets_batch. The context is clear but lacks 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?

Annotations indicate readOnlyHint and idempotentHint, which the description supports by describing a fetch-and-evaluate process without mutation. The description adds behavioral context such as the revenue path for 'warn' decisions, which 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 well-structured: a concise first sentence summarizing the tool, followed by clear bullet points for decision outcomes, and a revenue path note. It is slightly lengthy but every sentence contributes 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 presence of an output schema, the description adequately covers the tool's behavior and outcomes, including the is_x402 flag and the revenue path. It provides sufficient context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters have descriptions. The description adds value by explaining how the parameters (method, price_usdc, agent_intent, resource_url) are used in the evaluation process, complementing 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's purpose: a one-shot x402 guard that fetches a resource URL, extracts seller wallet, runs preflight, and returns a spending decision. It distinguishes itself from sibling tools by focusing specifically on x402 resource evaluation.

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 the tool (before paying an x402 resource) and details the decision outcomes (allow, warn, block, is_x402 False). It does not explicitly state when not to use it or mention alternative tools, but the context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral traits: it's a capped teaser, returns top-N by event count, includes 'capped' and 'total_distinct_merchants' fields, and mentions 'fail-open'. This adds context about data completeness and potential partial success.

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 a clear lead sentence and subsequent details. It is somewhat verbose but contains no wasted sentences. It front-loads the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters and an output schema, the description is complete. It explains the return format (per-edge details, capped/total fields), notes the paid alternative, and mentions failure behavior ('fail-open'). No critical information is missing.

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 clarifying the 'wallet' parameter is a payer and the 'limit' is a cap (teaser). It also provides context about the default and maximum. This adds value beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists top-N merchants a wallet pays, with per-edge details. It uses specific verbs ('discover', 'list') and resources ('merchants', 'wallet'). However, it does not explicitly differentiate from sibling tools like get_merchant_card or get_provider_reputation, though the context suggests it's a counterparty discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides usage guidance: it's a free capped teaser, useful before trusting a counterparty, and notes that the full graph is paid. It implicitly suggests when to use (free discovery) and when not (if full graph needed). It does not explicitly mention alternative tools, but the context is clear.

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

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

Annotations indicate readOnlyHint and idempotentHint. The description adds beyond these by specifying fail-open behavior (returns data_available=false on DB gap) and the exact data returned (facilitator_ids list plus tx/merchant context), which are not covered by 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 covering purpose, interpretation, and behavioral details. It is front-loaded with the main purpose and avoids fluff, though could be slightly more compact.

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 only one parameter and an output schema (exists but not shown), the description provides sufficient context: purpose, interpretation hints, and fail-open behavior. It is complete for the 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 already fully describes the wallet parameter (format, base58). The description does not add any additional parameter semantics, so 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 it provides discovery of which x402 facilitators a payer has settled through and their count, with a specific verb (discovery) and resource (facilitator footprint). It distinguishes from sibling tools like get_x402_directory by focusing on a specific payer's settled facilitators.

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 gives interpretive guidance (e.g., unique_facilitators = 1 indicates a thin/captive agent) and contextual hints for when to use the tool (to assess cross-rail activity). However, it does not explicitly state when not to use it or name 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?

The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint): it is free, uses dual input resolution via a registry, and clarifies it does not claim service quality. 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 (5 sentences) and front-loaded with the primary purpose. Every sentence adds essential information: purpose, dual input, resolution, what it does not do, and HTTP twin reference. No redundant text.

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 (2 optional parameters, output schema present, annotations covering safety and idempotency), the description is complete. It explains the tool's behavior, parameter usage, limitations, and API equivalent, leaving no critical 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 coverage is 100% with parameter descriptions. The description adds semantic value by explaining the relationship between wallet and resource_id (dual input, resolution via PR-3 registry), which is not evident from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves observed inbound payment-graph quality around a Solana receive wallet. It uses specific verbs ('get', 'observe') and distinguishes itself by explicitly stating what it does NOT claim (service quality like resource_listing_only/catalog_listing_only), differentiating it from sibling tools that may focus on service quality.

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 when to use this tool (for payment-graph quality) and what not to use it for (service quality), but does not explicitly name alternatives or provide exclusions. It gives context on dual input and registry resolution but lacks explicit '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 indicate readOnlyHint and idempotentHint, which the description supports. Beyond that, it adds useful behavioral context: the tool is free, returns specific outputs (wash_label, reputation tier, wash_flagged bool), and fails open by returning 'unknown' on a DB gap rather than erroring.

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 core purpose and key differentiators, then elaborates on metrics and behavior. It is slightly verbose but remains clear and well-structured, earning its 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 presence of an output schema (not shown but indicated), the tool is fully described: purpose, inputs, outputs, error handling, and relationship to siblings. No gaps remain for an agent to misinterpret.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'merchant' is already well-described in the input schema (100% coverage), with explanation that it is a Solana wallet public key. The tool description adds minimal additional semantic value beyond restating the 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 it is a 'Free discovery: corpus-backed SELLER reputation' tool that answers whether a provider is 'organic, narrow, or a wash fleet'. It specifies the metrics used and explicitly distinguishes from sibling tool 'score_wallet_for_intel' (payer side vs seller 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 notes it 'Complements score_wallet_for_intel (payer side) with the seller side', providing context on when to use each. It also contrasts with a paid alternative. However, it does not explicitly list all alternative tools or state when not 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.

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds substantial context: the tool is free, advisory, and does not substitute for buyer policy. It details decision semantics, return fields, the heuristic nature of trust_score, and the activation handoff, all of which inform the agent of expected behavior and limitations.

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 longer than average but well-structured with clear sections. Every paragraph adds necessary information: usage, decision mapping, activation handoff, and next steps. It is front-loaded with the primary purpose, and while dense, it avoids fluff for a tool of this complexity.

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 decision-gate tool with an output schema, the description is remarkably complete. It covers when to call, decision semantics with exact actions, critical pitfalls (template handling), and follow-up steps. The return fields are partially enumerated, and the handoff instruction ensures the agent knows what to do after receiving the card.

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 covers all 8 parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaning by stating the OR relationship between seller_wallet and resource_name, and provides a critical warning about never passing OpenAPI templates, which the schema does not emphasize. This raises it above 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 opens with 'PRIMARY free pre-spend gate (advisory)', a specific verb-plus-resource statement that clearly identifies the tool's role. It distinguishes from sibling tools by explicitly mentioning when to use verify_receipt instead, making the tool's purpose unambiguous.

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 'When to use' (before any x402 payment) and 'When not to use' (after already deciding to refuse, use verify_receipt for signed receipts). It also names an alternative tool and offers optional follow-up with twzrd_watch_add, giving clear decision 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 valuable behavioral context: two return shapes, failure envelope format, and ticker format example, going beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with bullet points and clear sections, every sentence adds value, 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 the output schema exists, the description appropriately omits return details, but covers failure envelope, two output shapes, and ticker format. Complete for a single-parameter tool with rich 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 coverage is 100%, baseline 3. The description adds meaning by explaining the behavioral difference when ticker is present vs absent, which is not fully captured in the schema description, raising the score to 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?

The description clearly states the tool returns recent on-chain trade and settlement activity, and distinguishes two operational modes (with/without ticker) with different outputs, making its purpose unambiguous and distinct from sibling 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?

The description implies when to use each mode based on ticker presence, but does not explicitly compare to sibling tools or state when not to use this tool. The context is clear but lacks explicit exclusions.

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 safe and idempotent behavior. The description adds value by disclosing the failure envelope format ({status:"error", kind, retryable, detail}) and labeling it as a free discovery tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at four sentences, each serving a distinct purpose: function, ticker clarification, cost/usage note, and failure behavior. No unnecessary words.

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 one-parameter read tool with an output schema (present but not shown), the description covers purpose, parameter semantics, failure mode, and usage cost. It does not elaborate on what 'normalized orderbook depth' means, but the output schema likely fills that gap.

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 a clear description of the 'ticker' parameter, including uppercase convention and an example. The tool description reinforces this but adds no new semantic detail beyond what the schema already provides, meeting the baseline for high coverage.

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 normalized orderbook depth and liquidity profile for a specific ticker from Solana Market API data, and explicitly clarifies that tickers are prediction-market event tickers, not spot DEX symbols. This distinguishes it from unrelated 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?

The description provides context about the ticker format and notes it's a free discovery tool, but does not explicitly state when to use this tool versus alternatives (e.g., get_solana_market_shape) or when not to use it.

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

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

Beyond readOnly and idempotent annotations, it describes error envelope structure (status, kind, retryable, detail). 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 with no wasted words. Purpose, use case, and error handling are 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?

With only one parameter, annotations, and output schema, the description provides all necessary context including error behavior.

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 and parameter description explains ticker format and that it's not a spot symbol. Description reinforces with example and warning.

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 returns market shape/structure signals (concentration, venue fragmentation, settlement patterns) for prediction-market tickers. Distinguishes from sibling tools like orderbook depth or trade summaries.

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 it's for understanding how a market trades on-chain and specifies ticker type. Could mention alternatives but is clear about its use case.

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 significant behavioral context: short-timeout hit, reports reachability, and mentions response fields (prod_key_configured, data_first_available, actionable note), which goes well beyond 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 concise (5 sentences) and front-loaded with the key purpose. Every sentence adds value, though minor tightening could be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description fully explains the tool's purpose, usage guidance, and behavioral details. It is complete for the agent to decide when and how to use it.

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?

There are zero parameters, so baseline is 4. The description does not need to add parameter info; it correctly focuses on the tool's purpose and behavior.

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 health probe for the Solana Market API data backend, using specific verb+resource ('Health probe') and explicitly distinguishes it from sibling tools by advising to call it 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?

The description explicitly tells when to use this tool ('Call this to gate or degrade gracefully BEFORE the other get_solana_market_* tools') and provides context about being a free discovery tool, giving clear guidelines.

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 and idempotentHint, so the description adds value by stating it is free, describing the structured error envelope on failure, and referring to get_solana_market_status for disambiguation. 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 four sentences long, concise, and front-loaded with the main purpose. Each sentence adds necessary detail 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 no parameters and an output schema, the description fully explains the return values and failure behavior. It is complete for the 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?

With zero parameters, the description does not need to add parameter information. The baseline of 4 applies as the schema coverage is 100% and no parameters exist to explain.

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 the Solana Market API visibility map, listing specific metrics like metadata-market count, on-chain-trade-market count, overlap, coverage_pct, and sample tickers. It distinguishes itself from get_solana_market_status for failure 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?

The description labels it as a 'Free discovery tool' and mentions get_solana_market_status for failure cases, providing some context. However, it lacks explicit guidance on when to use this tool versus other sibling tools like get_solana_market_orderbook_depth or get_solana_market_shape.

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 goes beyond annotations (readOnlyHint, idempotentHint) by explaining the ranking mechanism: 'Ranks by the wash-discounted effective_score (single-counterparty fleets are demoted, not hidden).' This reveals important behavioral context for interpreting results.

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 (three sentences), front-loads the main purpose, and avoids extraneous information.

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 (3 optional parameters, output schema exists), the description covers purpose, ranking logic, parameter intent, and a disclaimer about the data's nature. It is complete for effective 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?

Schema coverage is 100%, so baseline is 3. The description's parameter guidance ('suppress one-shot wallets', 'suppress dormant ones') largely repeats the schema descriptions, adding minimal new 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?

The description clearly states it returns a 'Leaderboard of observed payer wallets in the x402 settlement graph, each with its intel score.' This distinguishes it from sibling tools like score_wallet_for_intel (single wallet) and get_counterparties (different aspect).

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 guidance on parameter usage: 'Set min_paid_calls to suppress one-shot wallets and max_days_since_last to suppress dormant ones.' It also includes a disclaimer about the nature of the data. However, it does not explicitly state when to use this tool versus alternatives like score_wallet_for_intel.

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 read-only and idempotent behavior. The description adds valuable context: operations include wash flag handling, chain-specific behavior (Solana only has wash overlay, Base/Polygon carry 'unknown'), and that it returns a raw merge. 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 somewhat verbose, including tangential information about MCP tool count and an HTTP preference. It is front-loaded but could be streamlined without losing key information.

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?

The description covers the tool's purpose, data sources, chain-specific behavior, and parameter mapping. With an output schema present, the lack of detailed return value description is acceptable. It provides sufficient context for correct 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?

Schema coverage is 100% with clear parameter descriptions. The description restates the parameter names and mentions they mirror the HTTP endpoint, but does not add significant new meaning 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 'multi-bazaar x402 listing overlay' with wash flags, and specifies it provides the raw multi-bazaar merge indexed by payTo. This uniquely identifies what the tool does and distinguishes it from siblings.

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 preferring an HTTP endpoint for a related use case ('resource join SOT') and explicitly says to use this tool when needing the raw multi-bazaar merge. This provides clear context and an alternative, though it does not directly compare with 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 already indicate readOnlyHint and idempotentHint. The description adds behavioral details: 'Fail-open: a DB gap returns classification unknown' and explicitly lists what is NOT returned (wash_factor, full model). This fully discloses behavior 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?

Four sentences with zero waste. First sentence states purpose and benefit ('Free discovery'), then explains output, usage, and edge case. Well front-loaded and 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?

For a single-parameter tool with output schema (implied by the descriptive summary of return fields), the description covers purpose, output, usage guidance, and edge cases (fail-open). It is fully complete given the available 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?

The input schema covers the single parameter 'wallet' with a good description. The tool description adds context like 'payer wallet' and 'corpus edges', reinforcing the purpose. With 100% schema coverage, the description adds modest extra value but not essential.

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 performs a 'cheap circular-flow (wash) check for a payer wallet' and returns a categorical classification and boolean. It does not explicitly differentiate from the many sibling tools, but its focus on being a fast Sybil/wash gate provides enough distinction.

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 'Use as a fast Sybil/wash gate before trusting a counterparty', which gives clear usage context. It does not specify when not to use it or mention alternatives, but the use case 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=true and idempotentHint=true. The description adds behavioral context: it returns a richer result with specific fields, an upsell path, and notes that the embedded readiness_card has same shape as get_readiness_card_tool. This adds value beyond annotations. 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?

Five sentences, front-loaded with key guidance. Every sentence earns its place: purpose, guidance, return details, and output schema reference. No waste.

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 parameters (all optional), output schema present, and annotations rich, the description covers when to use, what it returns, and relationship to sibling tool. It doesn't describe every nuance but is sufficient for a well-structured tool with comprehensive 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning to parameters; it mentions return fields but not parameter behavior. No extra semantics 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 it is a 'low-level preflight check' that returns a richer result object including upsell path. It distinguishes from sibling 'get_readiness_card' by specifying exact fields it provides. Verb 'preflight' is specific and resource is implied (payment/intel readiness).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicit guidance: 'Prefer get_readiness_card for most callers. Use this when you need max_spend_recommendation_usdc, full_report_hint, or the suggest_full_report flag.' This tells the agent when to use and when not to use, with specific alternative named.

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 consistent. The description adds details: uses a heuristic, returns score_model inline, handles malformed pubkeys cleanly, and describes data source. 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 informative but slightly verbose. It is front-loaded with the main purpose, and each sentence adds value. A minor trim could improve conciseness, but overall 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?

The description covers the scoring model, return fields, failure behavior, and data source. With an output schema present, it doesn't need to list fields exhaustively. It is complete for this single-parameter 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 a clear description for 'wallet'. The description adds context about wallet format and usage, going beyond the schema. Thus, it adds meaningful 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?

The description clearly states the tool provides a free intel score (0-100) for a wallet based on x402 payment history. It distinguishes from siblings like 'score_wallets_batch' (batch mode) and 'get_top_intel_agents' (top agents), and contrasts with a paid endpoint for a more comprehensive model.

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 explicitly says 'Free discovery' and contrasts with a paid HTTP surface for the full model, implying when to use the free vs. paid version. However, it lacks explicit when-not-to-use or alternative sibling names, though context is sufficient.

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 that truncation is disclosed via requested/capped fields, which is valuable 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, no wasted words. Front-loaded with purpose and key constraints.

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 signaled), the description adequately covers purpose, truncation behavior, and use case. No missing critical information for an AI 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?

Schema description coverage is 100%, so baseline is 3. The description adds nuance about the model being the same as score_wallet_for_intel and reinforces the cap/truncation, providing 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?

The description clearly states it scores up to 25 wallets in a single call, referencing the same model as score_wallet_for_intel, and explicitly distinguishes itself as a batch convenience for triaging 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 implies use for multiple wallets and mentions the sibling single-wallet tool, providing clear context. However, it lacks explicit when-not-to-use or alternative conditions.

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, but the description adds rich behavioral detail: no wallet/signer contact, no USDC spend, ledger candidate surface with real inbound IP, and the requirement for non-VPS source_ip and run_id matching to promote a candidate to an EXTERNAL_RUN. This goes far beyond the structured annotations without contradicting them.

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 core purpose and safety characteristics, then moves to caveats and proof requirements. It is somewhat dense and technical, but every sentence contributes needed context and there is no filler.

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 an output schema present, the description still covers behavior, side-effect-like attribution implications, safety, and proof verification steps. It fully explains the candidate-vs-run distinction and references the returned not_external_run_proof, making it complete for a tool of this 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?

The input schema already provides 100% parameter coverage for run_id and integration. The description reinforces the semantic role of run_id in transcript correlation and mentions the integration id in the attribution ledger context, adding value beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource statement: 'Runnable, no-spend proof of the TWZRD buyer-side x402 trust gate.' It then concretely states what happens (block path ABORTS, allow path would proceed, ok=true), clearly distinguishing it from sibling tools that perform other x402/intel operations.

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 clearly conveys when to use this tool: as a no-install, no-human, no-spend proof/demo of the gate. It adds important context about the EXTERNAL_RUN candidate versus a real EXTERNAL_RUN, but it does not explicitly name alternative tools or provide when-not-to-use instructions.

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 discloses behaviors beyond annotations: proactive re-checking when 'recheck_after_unix' elapses, posting to webhook on material changes, and returning the watch row with a timestamp. No contradiction with annotations (openWorldHint, idempotentHint, destructiveHint are all false, consistent with registration).

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 short paragraphs, front-loaded with the core action. Every sentence provides useful context: registration, lifecycle, return value. No redundant or vague language.

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 tool with 3 parameters, an output schema, and annotations, the description covers the registration process, follow-up behavior, and return details. It does not explain what a 're-call watch' is in depth, but the context is sufficient for an agent to understand its 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?

All 3 parameters are described in the schema (100% coverage). The description adds value by explaining the purpose of 'webhook_url' (optional, POST on staleness) and clarifying the role of 'payer_wallet' and 'seller_wallet'. It also notes the return value includes 'recheck_after_unix', enhancing 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 states the tool registers a re-call watch on a seller wallet, using a specific verb ('Register') and resource ('watch on seller wallet'). It distinguishes itself from sibling tools like 'twzrd_watch_list' and 'twzrd_watch_remove' by focusing on creation.

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 what the tool does and its lifecycle (proactive re-check, webhook notification), but does not explicitly state when to use it vs. alternatives or when not to use it. This is adequate but lacks explicit exclusions.

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, covering safety and idempotency. The description adds the return structure (fields listed) but does not disclose additional behavioral traits beyond what annotations provide. A score of 3 is appropriate as the description adds context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first states purpose, second lists output fields. Every sentence adds value, no redundancy, and the purpose is 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?

With one fully described parameter, clear annotations, and an output schema, the description is largely complete. It covers the tool's function and output. A minor gap is the lack of mention of pagination or limits, but given the simplicity, a score of 4 is reasonable.

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% (payer_wallet already described as 'Your agent wallet address'). The description mentions 'your agent wallet' but does not add meaning beyond the schema. Baseline 3 is suitable.

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 explicitly states the tool lists active re-call watches for the agent wallet, and details the returned fields (seller, score/decision, recheck_after_unix). This clearly distinguishes it from sibling tools like 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 does not provide any guidance on when to use this tool versus alternatives, nor does it indicate when not to use it. The context of sibling tools implies its listing role, but explicit usage guidelines are absent.

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 non-destructive behavior. The description adds the owner-matching constraint, which is useful behavioral context. However, it does not elaborate on side effects or reversibility.

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 sentence that directly states the purpose and key constraint with no extraneous words.

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 removal tool with an output schema, the description covers the essential information. It could mention return behavior, but the output schema likely handles that.

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 description adds little beyond what the schema provides. It reiterates the payer_wallet constraint, but the schema already includes that information.

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 action ('Deactivate a re-call watch by ID') and includes a specific constraint. It distinguishes from sibling tools like twzrd_watch_add and twzrd_watch_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?

The description tells when to use (to deactivate a watch) and includes a prerequisite (payer_wallet must match owner). It does not explicitly mention when not to use or alternatives, but the context is sufficient.

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 behavioral details: offline, no DB/network/payment, returns multiple validity flags and errors, and warns about trust anchoring. Contradictions none.

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?

Well-structured with a bold opening statement. Information is front-loaded and each section adds value. Slightly verbose but not excessive.

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 inputs, trust model, return values (valid/leaf_valid/signature_valid plus leaf and errors). Output schema exists, so return details are not needed. Complete for a verification 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?

All four parameters have descriptions in the schema (100% coverage). The description adds value by providing source context for receipt, cross-referencing Python library/CLI for max_age_seconds, and usage guidance for require_signature.

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's purpose: offline verification of v5/v6 trust receipts. It specifies the actions (recomputes Keccak256 leaf, verifies Ed25519 signature) and distinguishes from sibling tools by focusing on receipt verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit usage guidance: pass the full PaidReceipt object, trust anchored on published key, and explains optional parameters like max_age_seconds and require_signature. No explicit when-not-to-use, but sufficient for correct invocation.

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, so the read-only nature is clear. The description adds 'via recompute logic' implying computation, but doesn't contradict annotations. Provides minimal extra 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?

Extremely concise at two sentences with no waste. Could benefit from slightly more detail, but front-loads the core 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 100% schema coverage, output schema present, and annotations, the description is minimally adequate. However, it lacks contextual completeness for a verification tool that might need explanation of what verification entails.

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. The description adds nothing about parameters, 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 states 'Independent root verification' which identifies the tool's action and resource, but lacks specificity about what 'root' refers to and does not differentiate from sibling tools like verify_receipt.

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 (e.g., verify_receipt). The description provides no context for selection.

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