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

The description thoroughly discloses behaviors beyond annotations, including persistence details, unsigned mode behavior, duplicate handling, and chain support limitations. Annotations only provide idempotentHint, but the description adds crucial context for safe usage.

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 lengthy but well-structured, starting with the core action and then detailing modes. It is information-dense but not bloated; every section serves a 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?

The description is remarkably complete given the tool's complexity (6 parameters, no output schema). It covers all modes, return signatures, constraints, and integration points with prepare flows, leaving 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?

The input schema already has 100% description coverage, providing a baseline of 3. The description adds macro context that clarifies parameter roles (e.g., intendedChains for defense-in-depth), justifying a slightly higher score.

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

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

The description clearly states the tool's purpose: 'Save a label → address binding to the address book.' It distinguishes from siblings like remove_contact and list_contacts by specifying this is for adding entries.

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 across three modes (production+ledger, production no ledger, demo) and how it integrates with send flows. However, it does not explicitly contrast with alternatives like remove_contact or verify_contacts.

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?

Adds rich behavioral context beyond annotations: explains data sources (demo-mode, Ledger, tx history), output formats (envelope + narrative), redaction behavior, v1 limitations (no prepared-tx ring buffer), and roadmap. 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?

Well-structured and front-loaded with purpose. Long but efficient, though some roadmap details could be condensed. Every sentence adds value.

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

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

Covers all necessary aspects: behavior, outputs, redaction, scopes, incident classes, limitations, and roadmap. Adequate given no output schema and comprehensive schema descriptions.

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% with detailed parameter descriptions. The tool description reiterates some parameter context but adds little new meaning beyond what the schema already provides.

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

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

The description clearly states it builds a forensic incident-report bundle for security review or disclosure, and distinguishes itself from siblings by noting it does not submit anywhere (roadmap for submit companion).

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

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

Describes when to use (security review/disclosure) and explicitly states it only builds, not submits, and that submission is deferred. Provides guidance on redaction modes and scope selection.

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, so the description reinforces that it 'surfaces data; it does NOT pick.' Adds context about the meaning of 'no dangerous functions' and agent behavior refusal. 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?

Description is long and includes repetitive warnings and issue references. While informative, it could be more concise. Essential information is present but padded with redundant instructions.

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?

No output schema is provided, yet the description does not explain the output format or structure. For a complex analysis tool, agents need to know what findings are returned. Parameter semantics are also incomplete, leaving gaps in understanding.

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

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

Schema coverage is 0%, so description must compensate. The description only vaguely alludes to 'a given contract' but does not explain the address or chain parameters. Missing explicit descriptions of parameter purpose, formats, or constraints 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?

Clearly states it checks Etherscan verification, proxy patterns, and dangerous admin functions. Distinguishes from unrelated tools by explicitly stating what it does NOT measure (token upside, price direction, investment merit). Provides a specific SCOPE: 'protocol/contract safety only'.

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

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

Explicitly says to use for due diligence on contract safety. Instructs agents not to use clean security reports as token-pick validation and to refuse speculative prompts. 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by explicitly stating the tool 'surfaces data; it does NOT pick' and describing the types of holders it classifies (EOA, Gnosis Safe multisig, TimelockController). This goes beyond 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 informative but verbose, including an issue reference ('Issue #599') and repeated emphasis on what the tool does not do. While well-structured with clear sections, it could be more concise without losing core 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 security focus, the description covers purpose, scope, behavioral constraints, and usage guidelines adequately. However, it lacks details about the return format or output structure, which would be helpful for an agent to process results. No output schema to compensate.

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 has 0% description coverage; the description does not elaborate on the parameters beyond what is in the schema (address pattern, chain enum). The agent must rely solely on the schema definitions, which are minimal. The description adds no new semantic information about the 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 the verb 'Enumerate privileged roles' and specifies the resource (contract roles like Ownable.owner, AccessControl hints) and classification of holders. It distinguishes itself from sibling tools like 'check_contract_security' by focusing specifically on governance posture and explicitly stating what it does not measure (token upside, price direction).

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 when-to-use and when-not-to-use guidance. It states the tool is for due diligence, not for picking tokens, and instructs the agent to refuse speculative-pick prompts. It also clarifies the interpretation of results ('safety floor, NOT an upside signal').

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?

Adds beyond annotations: describes error handling on body mismatch, return of per-input signature count, and 'No device touch' (no hardware interaction). No contradictions with annotations (destructiveHint=true, idempotentHint=true are consistent with merging operation).

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, front-loaded with core purpose, then constraints, error behavior, and output. No extraneous words. 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 no output schema, description covers return value (merged PSBT + signature count), error handling, and constraints. Covers all essential aspects for 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?

Single parameter 'psbts' is fully described in schema (100% coverage). Tool description repeats same constraints, adding no new information beyond the schema's description. Baseline 3 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?

Explicitly states it merges 2-15 partial PSBTs from multi-sig cosigners, with clear constraints on input format (base64 v0, same unsigned tx body). Distinguishes from sibling tools like sign_btc_multisig_psbt and finalize_btc_psbt by focusing on combination step.

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 clear conditions for use (same unsigned tx body, only witness data differs) and error behavior when violated. Could explicitly mention not to use with PSBTs from different transactions, but the constraints imply this. Alternative tools are identifiable from 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?

Beyond annotations (readOnlyHint, etc.), the description details output format, sorting, null handling for TVL and riskScore, filtering behavior, and edge cases like empty results. It also explains v1 coverage gaps and agent constraints (do not pick), providing significant additional 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?

The description is long but well-structured, starting with purpose, then detailing coverage, output, filters, and agent behavior. Every sentence serves a purpose, though the coverage gap explanation could be more succinct. It remains effectively scannable.

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 (4 parameters, no output schema), the description is exceptionally complete: it explains all parameter behaviors, output format, sorting, null handling, and agent usage constraints. It fully compensates for the lack of an output schema.

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

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

With 100% schema coverage, the description still adds value by explaining meta-asset 'stables', resolution rules (ETH→WETH), default chain behavior, and the nuanced filtering of null values for minTvlUsd and riskCeiling. This exceeds the schema's 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 returns a ranked table of supply-side yield opportunities for a given asset across integrated lending/staking protocols. It specifies covered protocols, output fields, sorting, and filters, distinguishing it from sibling tools that handle individual protocols or positions.

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 implicitly differentiates this tool from others by emphasizing it surfaces data rather than recommending actions, but it does not explicitly compare to sibling tools like get_protocol_risk_score or individual protocol yield tools. It provides clear filter guidance and agent behavior constraints.

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, destructive=false, idempotent, open world. The description adds that it uses current APRs, is forward-looking, returns specific fields (protocol, input amount, APR, projected rewards), and emphasizes no on-chain position reading. This adds significant behavioral context beyond annotations.

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

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

The description is four sentences, all essential, with purpose upfront. No fluff or redundancy. It efficiently conveys purpose, usage context, output, and limitations.

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 tool is simple (2 params, query). Description mentions return values explicitly despite no output schema, and provides sufficient context with annotations covering safety and idempotency. It also informs about pairing with a sibling tool for actual holdings.

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 has 100% coverage with detailed descriptions for both parameters (protocol enum and amount with examples). The description does not add new semantic information about parameters beyond what the schema provides, 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 tool projects annual yield on a hypothetical staking amount for Lido or EigenLayer using current APRs. It distinguishes itself from sibling tools by explicitly noting it is forward-looking and does not read on-chain positions, and recommends pairing with get_staking_positions for actual holdings.

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 specifies when to use: 'for 'what would I earn if I staked X ETH?' questions before the user commits capital.' It also clarifies what it does not do (no wallet reading) and suggests a complementary tool (get_staking_positions), giving clear boundaries.

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, destructiveHint=false, idempotentHint=true. The description reinforces these (stateless/read-only, does not change demo state) and adds behavioral context: response is verbose, presumes intent, and agent should not call as probe. 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?

Well-structured with clear sections and bullet-like flow. However, it is somewhat verbose with some repetition (e.g., 'stateless / read-only' appears twice). Still, every sentence adds value and it's appropriately detailed for a complex tool.

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

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

Despite no output schema, the description fully explains return value (tailored decision tree, no-op outside demo mode). Covers all parameters with usage context, preconditions, agent behavior, and edge cases. Nothing missing for effective use.

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

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

Schema description coverage is 100%, but the description adds significant context: hasLedger controls deferral, hasRunSetup skips setup walkthrough, chains drives RPC key recommendations, acquireKeys affects recommendation tone. This goes well beyond the brief 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 builds a step-by-step guide for exiting demo mode. It specifies the output is a tailored decision tree, distinguishes itself from other tools by being stateless/read-only, and the sibling list contains no similar tools.

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

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

Explicitly states when to call (only after user confirmation of intent), provides pre-call questions (hasLedger, hasRunSetup, chains, acquireKeys), and when not to call (as a probe). Also covers edge cases: deferral if no Ledger, no-op outside demo mode.

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 comprehensive behavioral traits beyond annotations: it walks top-level method/events, decodes events, shows balance changes, fee, and heuristics. It also notes limitations (v1 coverage, top-level only, current spot pricing) and confirms read-only, no signing/broadcast. 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 dense with valuable information and well-structured (purpose, agent behavior, details, distinctions, use cases, limitations). However, it is somewhat verbose, but every sentence contributes meaning.

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

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

Despite having no output schema, the description thoroughly explains what the tool returns (structured envelope and pre-rendered narrative). It covers supported chains, limitations, pricing, and parameter behavior, making it complete for an agent to understand.

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 4 parameters are fully described in the schema (100% coverage). The description adds context for wallet (defaults to sender, computes perspective) and format (both structured and narrative returns), going beyond schema details.

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

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

The description clearly states that this tool provides 'narrative analysis of a single confirmed transaction', listing specific decoded elements and use cases. It distinguishes itself from siblings like get_transaction_status and the prepare→preview→send pipeline, ensuring no overlap.

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 call this tool (when a user pastes a tx hash and asks why it failed/what it does) and what NOT to do (do not WebFetch explorer pages because they are JS SPAs). It also distinguishes from related tools, providing clear 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 details beyond annotations: it explains that the tool can broadcast (destructive behavior), returns broadcastedTxid on success, and refuses with per-input breakdown when threshold not met. It also aligns with annotations (destructiveHint=true, idempotentHint=true).

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 (4 sentences), front-loaded with the main action, and each sentence provides essential information without redundancy. It efficiently covers purpose, usage, behavior, and options.

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

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

Despite lacking an output schema, the description fully explains return values (tx hex, optional broadcastedTxid) and error conditions (refusal per input). For a complex tool, it covers all needed aspects for agent decision-making.

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 description adds meaningful context: psbtBase64 must be fully signed, broadcast parameter effect is explained. While the schema already describes parameters, the description clarifies the prerequisites and outcomes.

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 'Finalize' and the resource 'fully-signed multi-sig PSBT', and explicitly distinguishes from sibling tools like 'combine_btc_psbts' by referencing it as the typical preceding step.

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 provides explicit guidance on when to use (after combine_btc_psbts when threshold is met) and when broadcast=true vs false, and describes the refusal behavior for incomplete signatures. It also notes 'No device touch', contrasting with signing 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 indicate destructiveHint=true, and the description confirms the token creation is a mutable operation (issuer-side record). It adds behavioral details: token returned once, hash-only storage, revocation semantics. Minor gap: not stating that generating a token is non-reversible beyond revocation.

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 optimal but each sentence adds value. It front-loads the main purpose and proceeds through use case, token properties, security model, and related tools. Slightly verbose, but no redundancy.

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

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

Given the tool's complexity and lack of output schema, the description is remarkably complete. It covers the entire workflow: generate, share, import, query; explains token security (sha256, public data); and references sibling tools for revocation and listing. The agent can confidently use 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?

The description explains all four parameters in detail: wallets (with chain-specific regex validation), scope (read-portfolio only), expiresIn (with defaults), and name (auto-default pattern). Since the schema has 0% coverage, the description fully compensates, even clarifying the wallet structure.

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: generating a time-bound, revocable token for read-only access to specific wallets. It distinguishes this from similar tools by emphasizing that it creates a shareable token rather than performing direct reads. The mention of the classic use case with a financial advisor further solidifies clarity.

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 (granting temporary read-only access) and mentions related tools like import_readonly_token and revoke_readonly_invite. It lacks explicit guidance on when not to use it, but the context is sufficient for most agents.

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 labels the tool as READ-ONLY, explains the process of walking the pairing cache, fanning out to the indexer, and skipping empty addresses. This adds context beyond the annotations (readOnlyHint, idempotentHint) 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 fairly concise for the level of detail, starting with a clear header. While some sentences could be shorter, each adds value. It is well-structured and front-loaded with the core action.

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

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

Despite the lack of an output schema, the description fully explains the return format (rolled-up totals and per-address breakdown with type, chain, index). It also covers prerequisites, alternatives, and edge cases, making it complete for this complex 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?

The single parameter `accountIndex` has 100% schema description coverage. The schema description already explains its role and relation to pairing. The tool description reiterates similar context 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 it sums the on-chain balance across cached USED addresses for a specific Ledger Bitcoin account index. It distinguishes itself from other balance tools by specifying the use of pairing cache and per-address breakdown, making the purpose unambiguous.

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

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

The description provides explicit conditions for when to use this tool, when to call `rescan_btc_account` for stale cache, and when to re-run `pair_ledger_btc` for gap-limit extension. This guides the agent effectively on 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 readOnly, destructive, idempotent, openWorld hints. Description adds helpful context: uses mempool.space API, configurable via env var, and that testnet/signet are rejected. 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?

Single paragraph with essential information front-loaded. 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?

Complete for a simple read-only tool with full annotations and one parameter. Covers purpose, behavior, configuration, limitations, and expected output components.

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 address parameter completely (100% coverage). Description reinforces address types and adds behavioral constraint ('Phase 1 is mainnet-only'), which adds value 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 it fetches confirmed + mempool balance for a single Bitcoin mainnet address, lists returned data components, and differentiates from other get_btc_* tools by specifying single address. Includes address type restrictions.

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 READ-ONLY, mentions mainnet-only limitation, and describes backend. Does not explicitly contrast with sibling tools like get_btc_account_balance, but the single-address scope is implicit.

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, destructiveHint=false, idempotentHint=true. The description adds meaningful behavioral context: multi-address nature, per-address error handling resulting in 'errored' entries, and output shape mirroring get_btc_balance. 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?

Three sentences, each serving a distinct purpose: stating the operation and limits, explaining error behavior, and referencing sibling output for output shape. No redundant or extraneous information. 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?

No output schema exists, but the description compensates by referencing get_btc_balance's output shape. The single parameter is fully described in the schema. Given the tool's simplicity and the coverage from schema and annotations, the description is complete and self-sufficient.

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

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

Input schema coverage is 100% with descriptive text for the parameter and its items. The description reinforces the per-address error handling already in the schema, and adds context about output similarity to get_btc_balance, but does not significantly enhance meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool is a READ-ONLY multi-address Bitcoin balance fetch for 1-20 addresses, with a specific verb (fetch), resource (Bitcoin balances), and scope. It distinguishes itself from siblings like get_btc_balance by specifying multi-address capability and per-address error handling.

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 lacks explicit guidance on when to use this tool versus alternatives such as get_btc_balance or get_btc_account_balance. It mentions error handling but does not provide conditions like 'use when needing multiple addresses' or 'for single address use get_btc_balance'. The purpose is clear but the usage context is implied rather than stated.

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, etc. The description adds 'READ-ONLY', mentions the cap at 200, and discloses behavior about indexer-specific fields (mempool.space). 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 dense but not verbose, front-loading the main purpose. Each sentence adds value, and it's well structured 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?

For a simple read-only tool with one parameter and no output schema, the description covers input behavior, output fields, and use cases comprehensively.

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. Description adds meaning by explaining the default (144), cap (200), and rationale for the cap ('bound HTTP fan-out on free-tier indexers').

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 fetches recent Bitcoin block headers (newest-first) and enumerates the fields included. It distinguishes from siblings like get_btc_block_stats and get_btc_block_tip by specifying its purpose for chain-health questions.

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 provides example questions ('is the chain producing blocks at the expected rate?') and notes internal use by get_market_incident_status. Does not explicitly state when not to use it, but the context is clear enough.

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 that it is read-only and requires RPC configuration, and it lists specific data fields beyond what annotations convey. 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 concise: it front-loads 'READ-ONLY', lists outputs, states RPC requirement, provides use case, and references issues. 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?

For a simple read-only tool with one parameter and no output schema, the description covers purpose, data fields, usage context, and prerequisites. Minor omissions like error handling or valid block assumptions are acceptable given the clarity.

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 has 100% coverage with a detailed description of the hashOrHeight parameter. The tool description does not add additional parameter information 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 specifies that this tool provides bitcoind getblockstats output including fee distribution percentiles, tx count, block size, and total fees. It distinguishes itself from Esplora by noting that Esplora lacks fee percentiles, and it clearly targets fee-market anomaly detection and baselines for mempool_anomaly.

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 states it is RPC-only and requires BITCOIN_RPC_URL configured, and that it is used for fee percentiles not available via Esplora. It provides context for when to use this tool (spotting fee anomalies) but does not explicitly name an alternative tool for simpler queries like block size/tx count.

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 readOnlyHint annotation, describes indexer dependency (mempool.space default, configurable via env var or user-config), conditional availability of BIP-113 and difficulty fields, and normal block gap behavior. Adds significant operational 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?

Every sentence adds value. Front-loaded with core purpose and read-only flag. Followed by return fields, configuration detail, then use cases. No fluff, well-organized.

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

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

Covers all relevant aspects: what the tool does, what it returns, how it's configured, and appropriate use cases. With no output schema, the description fully explains return values. No 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?

No parameters exist, so schema coverage is 100%. Description adds meaning by listing return fields and their types (e.g., 64-hex hash, unix seconds) which compensates for lack of output schema. Baseline 4 for 0 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?

Explicitly states it is READ-ONLY and returns the current Bitcoin mainnet chain tip. Lists specific return fields (height, hash, timestamp, ageSeconds, BIP-113 median time past, difficulty). Clear verb+resource, distinct from sibling tools by focusing on the single latest block.

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 use cases: latest-hash lookups, block-age UX context, indexer-freshness checks, confirmation-depth math. Also explains Poisson block intervals. Does not explicitly exclude alternatives, but the guidance is clear and practical.

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 value beyond annotations by revealing that the tool returns available: false with a setup hint when RPC is not configured. It also confirms the read-only nature and idempotency. No contradictions with annotations; in fact, the description enriches the behavioral understanding.

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 yet comprehensive. It front-loads the read-only nature and includes key output details, use case, RPC requirement, and fallback behavior. Every sentence adds value, and the references to issues #248/#233 v2 are minor but acceptable.

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

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

Despite having no output schema, the description fully explains what the tool returns (branchlen, status with possible values) and covers the edge case of missing RPC configuration. It also explains why this data is unique (cannot be obtained from Esplora). For a zero-parameter tool, this is exceptionally complete.

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

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

The tool has no parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter information. According to guidelines, baseline for 0 params is 4, so this score 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 identifies the tool as returning bitcoind's getchaintips output, listing forks with branchlen and status. It explicitly states its purpose for fork/deep-reorg detection and distinguishes itself from Esplora indexers, which cannot expose this data. The verb 'get' and resource 'BTC chain tips' are clear, and it differentiates from sibling tools like get_ltc_chain_tips.

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

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

The description explicitly states that this is the primitive for fork/deep-reorg detection and notes that Esplora cannot provide this data. It also specifies the requirement for BITCOIN_RPC_URL and mentions the fallback behavior when RPC is not configured. While it could mention alternatives like get_btc_block_tip, the context is sufficient for an agent to decide when to use this tool.

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

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

Beyond annotations (readOnlyHint, etc.), the description reveals the data source (mempool.space with fallback to Esplora) and the exact labels returned. This provides significant behavioral context that helps the agent understand reliability and fallback behavior.

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

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

Three sentences, each adding value: purpose and unit, specific labels, and data source. Front-loaded with 'READ-ONLY' and clear verb. 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?

Given zero parameters and no output schema, the description fully covers what the tool returns (five labels with meaning) and where the data comes from. An agent can confidently use the tool and interpret 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?

With zero parameters (schema coverage 100%), the description compensates by thoroughly explaining the output labels and their meanings, which is essential for interpreting results. Baseline for no parameters is 4, and the extra detail on return values and data source elevates it to 5.

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 Bitcoin fee-rate recommendations in sat/vB, lists the five specific labels with their meanings (fastestFee, halfHourFee, etc.), and distinguishes itself from other BTC tools by focusing solely on fee estimates. No sibling tool duplicates this purpose.

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?

While the description does not explicitly state when not to use the tool or name alternatives, it clearly implies its use for obtaining Bitcoin fee recommendations. Given the uniqueness of this tool among siblings, explicit exclusions are not critical.

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 reinforces read-only nature from annotations ('READ-ONLY'). Adds details about data source (bitcoind), specific fields, and integration with get_market_incident_status. Requires configuration, which is not in annotations. 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?

Single paragraph, densely packed with useful information. Every sentence contributes distinct value (purpose, alternative comparison, usage context, config requirement, issue references). Could be slightly more structured but remains highly informative.

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

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

Given no parameters, no output schema, and annotations present, the description covers all necessary aspects: what it returns, how it differs from alternatives, required configuration, and its role in the broader system (used by get_market_incident_status). Completeness is high.

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

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

No parameters exist; schema coverage is 100%. Description implicitly confirms parameterless call by listing output fields, adding no confusion. Baseline 4 for well-covered 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?

Description explicitly states it returns bitcoind getmempoolinfo output with specific fields (tx count, bytes, memory, feerate, fees). Distinguished from Esplora's mempool view by emphasizing it provides the 'real local view' and daemon admission policy. Also notes usage by get_market_incident_status for mempool anomaly detection.

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?

Clearly indicates when to use: for the real local mempool summary from bitcoind RPC. Contrasts with Esplora's view, implying this is the authoritative source. Explicitly requires BITCOIN_RPC_URL configuration, setting a prerequisite.

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, destructiveHint, idempotentHint, openWorldHint. The description adds valuable context: derivation from cosigner xpubs, BIP-32 chain walking, gap-limit behavior, and the limitation to P2WSH (Phase 3). No contradictions.

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

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

Two sentences that front-load the core purpose and then efficiently detail the derivation method, chain walking, and limitation. 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 complexity (BIP-32, gap limit, P2WSH limitation, no output schema), the description covers essential behavioral aspects: it communicates what is returned (aggregate + per-address breakdown) and how addresses are derived. Still, the lack of explicit return format or error cases is acceptable for a read-only 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%; description adds meaninful detail beyond schema: walletName is linked to `register_btc_multisig_wallet`, gapLimit explains default 20 with BIP-44 context and cap rationale. The per-address breakdown detail is implied but not specified in 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 opens with 'Watch-only balance read for a registered multi-sig wallet', clearly stating the verb, resource, and scope. It distinguishes itself from sibling tools like `get_btc_balance` (single-sig) and `get_btc_multisig_utxos` (UTXOs) by focusing on aggregate balance with per-address breakdown from derived chains.

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

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

The description implies usage for quick balance checks ('No device touch') and notes a P2WSH-only limitation, but does not explicitly state when to use this tool over alternatives like `get_btc_multisig_utxos` or `get_btc_balance`. No mention of prerequisites beyond registration or contrast 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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description goes beyond by stating 'no device touch' and describing the content of each UTXO (witnessScript + cosigner pubkeys), which adds behavioral context about the output. 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 three sentences and front-loaded with the primary purpose. It is minimal but includes necessary context. No wasted words, though it could be slightly more compact by merging the last two sentences. Still 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 no output schema, the description provides information about the return content (witnessScript + cosigner pubkeys). It covers the tool's role (inspection vs. tx preparation) and safety ('no device touch'). For a straightforward read-only tool with two parameters, this is adequate but could include more about gapLimit defaults or 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 coverage is 50%. The description adds value for walletName by linking it to the input pool for prepare_btc_multisig_send. For gapLimit, it only references 'same gap-limit walk as get_btc_multisig_balance,' which does not explain the parameter's meaning or constraints. The description partially compensates for schema gaps but not fully.

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 the UTXO set for a registered multi-sig wallet, using same gap-limit logic as get_btc_multisig_balance. It explicitly differentiates from prepare_btc_multisig_send by noting internal usage and direct exposure for inspection. Additionally, 'no device touch' clarifies it's a read-only operation.

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 when to use this tool: to 'inspect the spendable set without preparing a tx.' It also notes the tool is used internally by prepare_btc_multisig_send, providing context for alternatives. However, it does not explicitly list when not to use it or edge cases, but the guidance is clear enough.

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 safety hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds value by detailing output fields (txid, sats, fee, block info, RBF flag) and the Esplora page limit, which are 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?

Two sentences that are front-loaded with the most critical information (read-only, what it returns, ordering). Every sentence adds value; no redundant or extraneous 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?

With no output schema, the description adequately covers all return fields and behavioral aspects (RBF flag, pagination cap). It is self-contained and sufficient for an agent to understand what the tool does and what it returns.

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 both parameters already described. The description adds useful context (e.g., 'one Esplora page' for limit, 'newest-first' ordering) that goes beyond the schema descriptions, 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?

Description clearly states specific verb+resource: 'Bitcoin transaction history for a single address (newest-first)' and details the data fields. Distinguishes from siblings like get_btc_account_balance (balance only) and get_transaction_history (likely multi-address).

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 marks as READ-ONLY, explains the limit and cap behavior, and notes pagination limitation ('pagination beyond is a follow-up'). While not detailing alternatives, the description provides clear context for proper 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 declare readOnly, non-destructive, idempotent, openWorld. Description adds useful context about confidence field and non-predictive nature, but doesn't add new behavioral traits 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?

Well-structured and front-loaded with purpose. Slightly verbose but all content is justified and adds value.

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

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

Very complete given complexity: explains two modes, allowlist details, return fields (though no output schema), and agent behavior. No 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 has 100% coverage. Description adds meaning: explains two input modes, allowlist, and escape hatch, providing context beyond 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?

Clearly states it fetches USD price by ticker or CoinGecko ID. Distinguishes from sibling tool `get_token_price` for non-EVM assets.

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 when to use (for non-EVM assets) and when not to (for EVM tokens, use `get_token_price`). Also provides scope (snapshot, not forecast) and agent behavior 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 confirm readOnly, non-destructive, idempotent. Description adds 'no wallet required' and details on returned fields (pause flags, collateral lists), providing full behavioral 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?

Description is front-loaded with purpose and use cases. Each sentence adds value, though slightly verbose in listing return fields. Could be tightened without loss of 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?

Without an output schema, the description exhaustively enumerates return fields (metadata, APRs, collateral details), making the tool's output fully predictable. Covers all needed context for 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?

Input schema already has 100% description coverage for both parameters. Description lists return fields but adds no additional parameter-level detail beyond the schema, meeting baseline expectation.

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 'Fetch structured market info for a single Compound V3 (Comet) market — no wallet required' and lists specific data returned, distinguishing from sibling tools like get_compound_positions which focus on user positions.

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 use cases: 'explain market state', answer specific questions, and 'diagnose an incident'. Lacks explicit comparison to alternatives, but the use cases are clear and actionable.

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 mark it as readOnly, idempotent, non-destructive. Description adds specific return fields (supply/borrow balance, collateral, valuations) and edge case behavior (empty list if no exposure), confirming safe read operation.

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 efficiently pack purpose, return details, usage context, and edge case. Front-loaded with action verb. No redundant 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?

Covers all necessary aspects for a read-only tool: what it does, what it returns, when to use, and empty result handling. Lacks explicit return structure details, but given no output schema, the listed fields are adequate.

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 descriptions for both parameters. Tool description mentions 'selected chains' but schema already covers default behavior. Minimal additional value 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?

Description specifies the exact verb 'Fetch', resource 'Compound V3 positions for a wallet', and scope 'across all known markets on selected chains'. It lists returned data fields (supply/borrow, collateral, USD valuations) and distinguishes itself from siblings by recommending use before prepare_compound_* actions.

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 when to use: to answer 'my Compound positions' or before preparing a Compound action to get the market address. Provides interpretation of empty result. Does not explicitly exclude other uses, but context is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: proxy following logic, cache, size cap, sanitization, and response structure, going 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?

Front-loaded with core purpose, then detailed behavior. While somewhat long, every sentence adds value and is well-structured for an AI agent.

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?

No output schema, but description fully explains response shape including edge cases (proxy, unverified). Covers error handling and context for all parameters.

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

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

Schema coverage is 100% with good descriptions. The description adds context for followProxy behavior and explains response fields like abiSource and proxyFollowSkippedReason, providing extra meaning.

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 fetches a verified contract's ABI on supported EVM chains, explicitly distinguishes itself from generic WebFetch and sibling tools like check_contract_security and prepare_custom_call.

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 prefer this tool over generic WebFetch for ABI lookups, explains when proxy following is applied, and what to do for unverified contracts (ask user to paste ABI).

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, etc.), the description details exact return values, filtering of zero-balance pools, and the additive expansion strategy. This provides agents with a clear understanding of tool behavior without hidden side effects.

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 core purpose and constraints, then details return values and future plans. While slightly verbose, every sentence serves a purpose. Could be slightly tightened 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?

Given no output schema, the description covers return value specifics and filtering behavior adequately. It addresses current scope and future expansions, though it omits error handling or edge cases. Still, it is sufficiently complete for v0.1.

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% and the schema parameter description is already quite detailed, including scope limitations. The main description does not add significant new meaning about the paramter beyond reinforcing the 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 retrieves Curve LP positions on Ethereum stable_ng plain pools, specifying return fields (LP token balance, gauge-staked, pending CRV) and filtering behavior. It distinguishes itself from sibling tools like get_lp_positions and get_compound_positions by focusing on a specific protocol and pool type.

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 defines when to use (Ethereum stable_ng plain pools) and when not to (meta pools rejected). It also outlines future expansions and references a planning document, providing clear context for appropriate 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?

The description adds significant behavioral context beyond annotations: it is composed from existing tools (not new on-chain reads), returns both structured and narrative formats, handles sub-tool failures gracefully, and explicitly lists missing features. 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 dense but every sentence provides necessary information. It front-loads the core purpose and efficiently covers sections, parameters, and limitations.

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 output schema and the tool's complexity, the description fully explains the return format (structured envelope and narrative), sections, failure mode, and punted features. It is comprehensive.

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 100% schema coverage, the description adds value by explaining address args mirror get_portfolio_diff, period defaults, and format options for agents. It enriches the meaning beyond the schema alone.

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

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

The description clearly states the tool generates a one-paragraph portfolio briefing composed from existing tools. It distinguishes itself from sibling tools get_portfolio_summary and get_portfolio_diff by specifying it is a conversational rollup.

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 defines when to use this tool: for a quick 'what's going on' briefing, defaulting to 24h. It also notes what is not covered (two punted sections with available: false) and differentiates from siblings.

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, idempotent, non-destructive, and open-world. The description adds significant detail: it always enumerates personas regardless of state, specifies response format, and explains the matrix enrichment (rehearsableFlows, flowGaps, recommendations). 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 verbose and contains multiple paragraphs with interleaved details. While all information is valuable, it could be better structured (e.g., bullet points for response shape or matrix explanation) to improve readability for an agent. It's functional but not lean.

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

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

Despite no output schema, the description fully defines the response structure including all fields and their meanings. It covers edge cases (envState values, matrix enrichment) and provides complete guidance for the agent to act on the result. The complexity is high, and the description meets 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?

Input schema has zero parameters. With no parameters, baseline is 4. The description does not need to explain parameters, and it correctly mentions that no input is required.

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's purpose: report active demo wallet, confirm default demo mode, or explain why demo mode isn't active. It also enumerates personas and provides response structure, clearly distinguishing it from siblings like set_demo_wallet and exit_demo_mode.

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 reading matrix data before user picks a flow to offer rehearsable flows and avoid unsupported ones. While it provides usage context, it doesn't explicitly state when not to use or mention alternative tools, but the guidance is clear enough for an agent.

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 confirm read-only, non-destructive, idempotent behavior. The description adds critical context: parallel fan-out, per-protocol failure handling via notes field, guarantee that missing protocols are never silently wrong, and return field details (e.g., marginToLiquidation). No annotation 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 detailed but every sentence adds value. It front-loads the core purpose and then structures details logically. The historical note (#427) is slightly meta but informative. Slightly longer than minimal but well-organized.

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

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

Despite no output schema, the description lists all returned fields (protocol, chain, market, healthFactor, collateralUsd, debtUsd, marginToLiquidation). It covers parameter constraints, error behavior, and cross-protocol scope, making it fully self-contained for a read-only health check 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 0% description coverage, but the description fully compensates by explaining wallet (EVM), solanaWallet (Solana), threshold (default 1.5, range implied), and the required at-least-one condition. This adds meaning beyond the raw 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 cross-protocol liquidation-risk check, listing specific EVM and Solana protocols. It explicitly mentions the verb 'check' and the resource 'health alerts', and distinguishes from per-protocol position tools like get_compound_positions or get_kamino_positions by aggregating across protocols.

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 requires at least one of wallet or solanaWallet, and explains partial results on failures. However, it does not explicitly state when to use this tool over individual protocol position checkers, though the cross-protocol scope is implied.

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, etc.), the description details return structure (obligation PDA, per-reserve deposits/borrows, USD values, health factor with convention explanation), and clarifies edge cases (empty list for new wallets, warnings for pause/freeze). 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?

Description is a single paragraph but front-loaded with 'READ-ONLY' and efficiently covers all key points without redundancy. Slightly dense but earns each sentence.

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 output schema, the description thoroughly explains what the tool returns, including health factor conventions, empty list handling, and warnings, making it fully contextual 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 coverage is 100% with detailed parameter description, so baseline is 3. The tool description adds some extra context (health factor and warnings) but does not significantly enhance parameter semantics 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 explicitly states it enumerates a Solana wallet's Kamino lending position on the main market, specifying both the resource (Kamino) and context (main market), which clearly distinguishes it from other position tools like get_marginfi_positions or get_compound_positions.

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 when it returns empty (wallet never used Kamino), providing implicit guidance on when to use. However, it does not explicitly state when to prefer this over alternatives, though the naming and context naturally differentiate 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 the annotations (readOnlyHint, idempotentHint), the description adds rich behavioral context: it uses the GET_APP_AND_VERSION APDU, works on dashboard or chain apps, lists example outputs for various apps, and describes the clean error behavior when no device is connected or udev rules are missing. 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 a single paragraph that front-loads the core purpose, then provides detailed examples and usage context. While it is lengthy, all information is valuable and well-organized. Could be slightly more concise but effective.

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 output schema, the description fully explains the return values (app name+version, hint, deviceConnected: false). It covers edge cases (no device, missing udev rules) and provides actionable instructions for the agent on how to interpret and use the information. Complete and self-contained.

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 no parameters, so the description does not need to add parameter information. The baseline is 4, and the description correctly omits param details.

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 probes the connected Ledger device over USB HID and reports the currently open app (name and version) plus an actionable hint. It explicitly distinguishes from sibling tools like pair_ledger_solana by positioning this as a pre-check to enable context-aware instructions.

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: call BEFORE pair_ledger_solana/pair_ledger_tron. It provides examples of how the result can be used to inform the user. It also notes that the tool never throws and returns clean error states, so the agent knows it's safe to call.

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 read-only, idempotent, non-destructive. Description adds details about cached data, security (topic verification, spoofing risks), and peerUnreachable behavior. 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?

Description is lengthy but well-structured and front-loaded. Each sentence adds necessary context for security and correct usage. Slight verbosity justified by tool's critical role.

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

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

Despite no output schema, description fully documents return format, field semantics, error conditions (peerUnreachable), and security workflow. Complete for a status tool with complex usage 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; baseline is 4. Description does not need to add param info, and it adds no param semantics (none exist).

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 reports WalletConnect session status for EVM and cached pairings for TRON/Solana, distinguishing from sibling pairing tools. It specifies return fields and when to call it.

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 guidance on when to call first (for resolving wallet references), when not to ask for addresses, security verification steps, and handling peerUnreachable. References sibling tools and tells agent actions.

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, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat that. It adds value by specifying the exact data returned (collateral, debt, health factor, LTV, liquidation threshold) and mentions the chains (Ethereum and Arbitrum). However, it does not disclose any rate limits, error behaviors, or the effect of the optional 'chains' parameter.

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 concise sentence that front-loads the key purpose and lists important details. It is efficient and avoids fluff, though a bulleted list could improve scanability. It earns its place 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 (multi-chain, multi-field positions) and absence of an output schema, the description covers the core purpose and return fields. However, it lacks details on how the 'chains' parameter interacts with the return (does querying multiple chains aggregate or separate?), default behavior, and the exact structure of the response (e.g., per-asset breakdown format). It is adequate but not fully comprehensive.

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 has 0% description coverage, so the description should compensate. It mentions 'wallet' implicitly and 'chains' by naming example chains, but it does not explain the wallet format (0x address), that chains is an array, or that polygon/base/optimism are also valid despite the description focusing on Ethereum and Arbitrum. The description adds minimal meaning beyond the schema's pattern and enum.

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 specific action (fetch all lending/borrowing positions), the protocol (Aave V3), and the target (wallet). It lists the returned fields (collateral, debt, health factor, LTV, liquidation threshold) and chains (Ethereum and Arbitrum), making it easy to distinguish from sibling position-fetching tools like get_compound_positions or get_kamino_positions.

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. While the name and sibling context imply it is for Aave V3 positions, there is no guidance on prerequisites, when not to use it, or comparisons with other position tools. Usage is implied but not explicitly directed.

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, destructiveHint, idempotentHint, openWorldHint. Description adds value by listing returned fields (token pair, amounts, fee tier, etc.), which are not in the schema. 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?

Two sentences: first states purpose, second lists outputs. Front-loaded, no unnecessary words. 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 no output schema, description adequately explains what is returned. However, it does not mention that wallet is an Ethereum address or that chains is optional. Still reasonably complete for a simple read 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 description coverage is 0%, so description must compensate. It only mentions 'for a wallet' but does not describe the wallet format or the chains enum. The schema has pattern and enum, but no additional semantics in 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 it fetches all Uniswap V3 liquidity-provider positions for a wallet, with specific verb 'Fetch' and resource 'Uniswap V3 liquidity-provider positions'. Distinguishes from sibling tools like get_compound_positions by naming the protocol.

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 Uniswap V3 positions, but does not explicitly state when not to use or suggest alternatives. However, the protocol name in the description provides clear context for when to select this tool among similar ones.

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 behavioral context beyond annotations: the data source (Esplora indexer), the output details (confirmed+mempool litoshis, LTC decimal), and the fact that format validation is the only check. Annotations already indicate read-only and idempotent, so the description enhances transparency 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 three sentences, each earning its place: first states purpose and source, second details output, third notes address formats and limitations. No extraneous information, and the core action 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?

For a simple balance retrieval with one parameter, the description is fairly complete. It could explicitly mention the return JSON structure (field names), but the lack of an output schema means the agent must infer. Still, it provides necessary context for invoking 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?

The input schema has 100% description coverage for the address parameter, detailing format and limitations. The tool description does not add meaningful semantics beyond what the schema already provides, 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 clearly states it returns the on-chain balance for a Litecoin mainnet address, specifying the data source (Esplora indexer) and output components (confirmed+mempool litoshis, LTC decimal). It distinguishes from siblings by focusing on Litecoin and listing specific address formats, and notes limitations (mainnet only, no testnet/MWEB).

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 implicitly tells when to use: for getting Litecoin balance, and it notes that the read path only validates format, so it does not confirm address usage. However, it does not explicitly compare to other get_ltc_* tools or provide alternative scenarios, but the context of sibling tools (e.g., get_ltc_blocks_recent) makes it clear this is for balances.

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, destructiveHint false, idempotentHint true, openWorldHint true. The description adds specifics: READ-ONLY, default 144 blocks (~6h), capped at 200, and internal usage context. 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 a tight three-sentence paragraph, front-loaded with 'READ-ONLY', and every sentence adds value (function, defaults, internal usage). No wasted 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 list tool with no output schema, the description adequately specifies it returns block headers newest-first, with defaults and cap. It mentions internal usage and issue reference. Minor omission: could briefly note typical fields in a block header, but not required.

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

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

The schema provides 100% coverage for the single limit parameter. The description adds reasoning for the cap (to bound HTTP fan-out on litecoinspace.org's tighter free tier), providing meaningful context 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 it fetches recent Litecoin block headers, newest-first, with default limit and cap. It explicitly mirrors get_btc_blocks_recent for LTC, distinguishing it from sibling tools like get_ltc_block_tip or get_ltc_block_stats.

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 is used internally by get_market_incident_status for LTC and mentions the cap bound due to API tier. However, it does not explicitly state when to use this tool versus alternatives like get_ltc_block_tip or get_ltc_block_stats.

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, idempotentHint, etc. Description adds configuration requirement and mirror relationship. No contradictions; it extends annotation 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?

Two concise, front-loaded sentences. First sentence states purpose and read-only nature, second adds mirror and config requirement. No redundant 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?

Lacks explicit return value description, but 'litecoind getblockstats output' is a known RPC format, providing enough context for an agent familiar with the ecosystem. Issue references are extra.

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 schema description explains hashOrHeight parameter well. Description adds no new semantic detail beyond 'mirror of BTC version', which is marginal. Baseline 3 applies.

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

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

Description clearly states it's a read-only tool for litecoind getblockstats output. Explicitly identifies as mirror of get_btc_block_stats for LTC, distinguishing it from its sibling 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?

States prerequisite (LITECOIN_RPC_URL configured) and implies usage for LTC block stats. Does not explicitly state when not to use, but the mirror reference provides guidance for selection.

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, destructiveHint=false, idempotentHint=true. The description adds value by specifying the tool is backed by a configurable indexer, notes the block time context, and references an issue explaining why the tool was missing. 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?

Description is concise and front-loaded, but includes some extraneous details (e.g., issue reference, env var name). Could be slightly more streamlined, but overall efficient 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 no output schema and no parameters, the description covers the return fields, configuration options, and behavioral context. It mentions the tool is a mirror of a Bitcoin counterpart and explains block time implications. Minor omission: does not explicitly describe output format (e.g., JSON object), but the listed fields imply structure.

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

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

Input schema has zero parameters and 100% coverage, so bar for parameter semantics is high. The description does not need to add parameter info; it appropriately focuses on output fields and configuration. Baseline 4 for zero-param tool.

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

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

Description clearly states it is a read-only tool to get the current Litecoin mainnet chain tip, mirroring get_btc_block_tip, and specifies returned fields (height, 64-hex hash, timestamp, ageSeconds, optional MTP + difficulty). It distinguishes from sibling tools like get_btc_block_tip and get_ltc_chain_tips.

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 about the tool being a mirror of get_btc_block_tip, notes the block time difference (2.5 min vs 10 min), and mentions configurability. However, it does not explicitly state when to use this tool versus alternatives, nor does it give 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 provide readOnlyHint, destructiveHint, idempotentHint. Description adds context about the underlying data source (litecoind), configuration requirement, and cost comparison. 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?

Description includes extraneous information like issue numbers and cost comparison details that are not directly needed for tool invocation. Could be more concise.

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

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

Given no parameters and no output schema, the description provides adequate context: read-only, mirror of BTC version, requires configuration, and purpose. Complete enough for a simple 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?

Input schema has no parameters, so description does not need to add parameter meaning. The description is clear about the tool's input-less nature.

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 READ-ONLY and returns the litecoind getchaintips output, mirroring get_btc_chain_tips for LTC. This specific verb+resource distinguishes it from siblings like get_ltc_block_tip.

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 mentions when to use (for indexer-independent second opinion) and that it requires LITECOIN_RPC_URL configured. It implies mirroring get_btc_chain_tips, but does not explicitly provide when-not or direct 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, idempotentHint, etc. The description adds the context of being a mirror and the need for configuration, but does not significantly expand on behavioral traits 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 with two sentences, front-loading the read-only nature and providing essential context without 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?

The description explains the source and dependencies, but given no output schema, it could elaborate on the return structure. However, it suffices for a simple, parameterless 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?

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter info, and it doesn't.

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 litecoind getmempoolinfo output, and explicitly notes it is a mirror of get_btc_mempool_summary for LTC, providing a specific verb+resource and differentiation 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?

It explicitly requires LITECOIN_RPC_URL configured and points to the alternative BTC version, giving clear guidance on when to use this tool versus its BTC counterpart.

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, destructiveHint=false, idempotentHint=true. Description adds behavioral details: snapshots most recent fetchGroupData pass, warms cache on demand, describes output fields including recovery from raw bytes. 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 thorough but slightly verbose (e.g., details about SDK version and IDL version). However, it is well-structured with purpose, return details, usage guidance, and cache behavior. Every sentence adds value, so it earns a high score.

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 (diagnostic for a specific client), empty schema, and no output schema, the description fully explains purpose, usage context, output details, and behavioral traits. It is complete and leaves no ambiguity.

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

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

No parameters exist; schema coverage is 100%. Description explicitly confirms 'No input args.' The description cannot add more meaning because there are no parameters to describe.

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 diagnostic surface for the hardened MarginFi client load, returning a list of skipped banks with detailed fields. It distinguishes itself from sibling tools like prepare_marginfi_* and get_marginfi_positions by focusing on diagnostics rather than operations or position queries.

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 guidance: call when prepare_marginfi_* reports a mint is missed. Explains tool behavior—either names the skipped bank with cause or confirms mint not in group. No mention of when not to use, but context is clear.

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

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

Annotations already declare readOnlyHint=true, etc. Description adds substantial behavioral context: probes account indices 0-3, returns per-account entries with balances, USD values, health factor with interpretation (>1 safe, Infinity when no debt), and bank-level pause warnings. Contradiction false.

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

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

Description is a single paragraph of 4 sentences. Every sentence adds value: opens with 'READ-ONLY', then describes action, scope, return details, and parallelism. Zero 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?

For a simple one-parameter read-only tool, the description covers return structure, health factor interpretation, aggregate totals, warnings field, and empty array case. No output schema exists, so the description adequately explains what is returned.

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

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

Schema coverage is 100% and the schema description for 'wallet' already includes the probing detail. The tool description repeats this without adding new meaning beyond the schema, so baseline 3 applies.

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

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

Description states specific verb 'enumerate' and resource 'MarginFi lending positions' for a Solana wallet. It clearly distinguishes from siblings by explicitly naming parallel tools (get_compound_positions, get_morpho_positions).

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 provides clear context: it is read-only, probes first 4 accounts, and returns empty array if no positions. It mentions parallels to other tools, giving implicit guidance on when to use this vs alternatives, but lacks explicit when-not-to-use.

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

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

Annotations (readOnlyHint, idempotentHint, openWorldHint) indicate safe, read-only operation. Description adds concrete behavioral details: returns flagged bit, incident flag, utilization thresholds, and per-protocol logic, 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?

Well-structured and front-loaded with purpose, but somewhat dense with repeated protocol details. Could be slightly more concise without losing clarity.

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

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

No output schema exists, but description fully explains return fields (flagged bit, incident flag, per-reserve flags, utilization, supply, borrow). Covers all protocols and edge cases adequately.

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 descriptions for all parameters. Description adds value by explaining how each enum value affects return logic (e.g., bitcoin computes hash_cliff, empty_block_streak) and wallet usage for specific protocols.

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 an 'is anything on fire' snapshot across markets, with per-protocol details (Compound, Aave, base-layer chains). It distinguishes itself from sibling get_compound_market_info by collapsing multiple calls into one.

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 use when suspecting governance pause, utilization cliff, or multi-market contagion. Contrasts with get_compound_market_info for alternative when detailed per-market info is needed.

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 adds valuable behavioral details beyond annotations: auto-discovery performance warning, fast path suggestion, and return content. Annotations already indicate read-only, idempotent, non-destructive; description enriches with operational nuance.

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 efficiently convey purpose, key behavioral nuance, and return content. No redundant or superfluous 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 no output schema, the description clarifies return categories (supplied/borrowed assets and collateral) per market. Lacks output format specifics but adequate for a query tool. No mention of limits or pagination.

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

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

Schema covers 100% of parameters with descriptions; tool description adds context about marketIds auto-discovery vs explicit fast path. However, the wallet parameter schema description uses 'execute this action' which slightly misaligns with the read-only nature.

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 fetching Morpho Blue positions for a wallet, specifying the resource (Morpho Blue) and action (fetch). It distinguishes from sibling tools like get_compound_positions by explicitly naming the protocol.

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 on when to use explicit marketIds for speed versus omitting them for auto-discovery, but does not explicitly contrast with sibling tools for mutations (e.g., prepare_morpho_*). The readOnlyHint annotation reinforces the read-only nature.

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=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description says 'Read-only' and describes a non-destructive operation. It adds context beyond annotations: data source (Reservoir), EVM-only constraint, and return field details. 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 three sentences: first lists return fields, second gives use case and source, third states constraints. It is front-loaded with key information and contains no redundant 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?

No output schema exists, but the description enumerates return fields thoroughly (name, symbol, image, description, floor ask, top bid, volume windows, owner count, total supply, royalty). It also specifies data source (Reservoir) and constraints (EVM-only, chain default). For a read-only lookup tool, this is 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 description coverage is 100%; both parameters are well-described in the schema. The description adds minor reinforcement: 'Pass the contract address on its deployed chain (defaults to ethereum).' This does not significantly expand semantic 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 retrieves NFT collection metadata including specific fields like name, symbol, image, floor ask, top bid, volume windows, owner count, total supply, and royalty. It distinguishes from siblings by indicating 'Wallet-less' and 'vitals' lookup, and explicitly notes EVM-only vs Solana.

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: use for 'what's this collection's vitals?' lookups before adding to a watchlist or evaluating exposure. It also states EVM-only in v1 and defers Solana NFTs to a different API, helping agents avoid incorrect usage. Pass contract address and default chain are mentioned.

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, idempotentHint=true. The description adds value by explaining multi-chain result merging, timestamp sorting, a cap at `limit`, and the data source (Reservoir API). 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?

Three sentences, front-loaded with the core purpose, followed by key behavioral details and a sibling reference. No wasted words; every sentence adds 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 low complexity (3 params, strong annotations), the description covers source, event types, merging, sorting, cap, EVM limitation, and relations to sibling. Lacks explicit return structure but references `get_transaction_history`'s shape, which compensates. Well-rounded for a read-only query.

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 descriptions cover 2 of 3 parameters (chains, limit) completely, and the description mostly echoes those details. For the wallet parameter, the description only says 'EVM wallet' but schema pattern already implies that. No 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?

The description uses specific verbs ('get', 'list') and nouns ('NFT activity', 'mints, sales, transfers, listings, bids, cancels') and clearly identifies the resource (wallet address across EVM chains). It distinguishes itself from the sibling `get_transaction_history` by explicitly noting it is scoped to NFT-relevant events.

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

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

The description provides clear context: it returns NFT-specific activity across EVM chains, mirrors `get_transaction_history`, and notes EVM-only with Solana deferred. It implies when to use (for NFT events) and when not (for non-EVM chains), but does not give explicit 'when not to use' or list alternatives beyond the one sibling mentioned.

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 complements annotations (readOnlyHint, destructiveHint, idempotentHint) by adding that it's a 'read-only display tool', explains the small page cap as a fabrication-resistance guard, and details the output fields. No annotation 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?

Description is well-structured and front-loaded with core purpose, then differentiates from siblings, describes source/fields, and ends with agent behavior. Every sentence adds value without redundancy.

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

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

Despite no output schema, description details the return fields (tokenId, priceEth, etc.) and constraints (EVM-only, single-token criteria, small page cap). Completely covers what an agent needs to use this tool effectively.

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 all 3 parameters. Description adds value by explaining the purpose of the 'limit' cap (fabrication-resistance) and reinforcing the contract requirement. Slightly above baseline due to added 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?

Description explicitly states it returns 'Ranked individual listings (currently active asks) for a single EVM NFT collection on a single chain, sorted floor-ascending.' It also distinguishes from sibling `get_nft_collection` by noting the latter only provides collection-level metadata, making the purpose very clear.

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?

Includes explicit when-to-use guidance (research/candidate selection) and when-not-to (execute buy via marketplace UI until prepare flow lands). Also notes EVM-only and Solana deferred, providing clear context on limitations.

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 reveals important behavioral traits beyond annotations: multi-chain fan-out with error isolation via Promise.allSettled, the meaning of totalFloorUsd as an upper-bound caveat, and per-collection aggregation. Annotations already declare read-only, so the description adds value on error handling and value interpretation.

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 overly verbose, including issue numbers, follow-ups, and deferred features that are not essential for tool usage. Key information is front-loaded but buried in technical details. It could be significantly shortened without losing clarity.

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

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

Given the tool's complexity (multi-chain, multiple parameters, no output schema), the description is fairly complete. It covers the output shape (per-collection rows, coverage flags, notes), error behavior, and parameter constraints. Missing explicit output field list, but still highly informative.

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 substantial context: explains the aggregation logic, optional filters (minFloorEth, collections), and their effects. It also mentions sources (Reservoir, Helius) and how filters behave across chains. This goes 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 NFT collections a wallet owns across EVM chains and/or Solana, with floor prices and total floor value. It uses a specific verb (List) and resource (NFT collections), distinguishing it from siblings like get_nft_collection and get_nft_history.

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

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

The description provides clear when-to-use guidance: for portfolio overview across multiple chains. It mentions required parameters (at least one wallet), warns about limitations (Solana floor pricing deferred), and notes that signing actions are handled separately. It could explicitly compare to similar tools, but the context is adequate.

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, but the description adds substantial caveats: v1 limitations (capped history, gas not subtracted, Solana swap legs skipped, Bitcoin unsupported) and truncation flag when history caps. This goes beyond basic read-only behavior.

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

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

The description is thorough and well-structured, but slightly verbose. However, every sentence serves a purpose, and key info 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?

Given no output schema, the description covers all necessary contextual info: what's included/excluded, period definitions, chain support, caveats, and truncation behavior. It is highly complete for a complex 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 detailed descriptions. The description adds context like requiring at least one address and explaining the 'inception' period's 365-day cap. It adds value but the schema already handles param meaning well.

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 specifies the tool's purpose: 'Wallet-level net PnL over a preset time window across EVM...' and provides a detailed mathematical formula. It distinguishes itself from the sibling `get_portfolio_diff` by noting when to pair them.

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 when to use ('simple how much did I make?') and when to pair with `get_portfolio_diff` for decomposition. Also lists period options and required addressing at least one chain address.

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 read-only, safe behavior. Description adds extensive behavioral detail: breakdown into price moves, deposits/withdrawals, other; v1 caveats about truncation, interest accrual handling, Solana exclusions, Bitcoin limitations. 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?

Description is front-loaded with purpose, then details parameters and caveats. Long but every sentence adds value. Could be slightly more concise, but acceptable for 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?

Comprehensive given no output schema: explains return structure, parameter behavior, and limitations convincingly. Covers all necessary context for 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% with good descriptions. Description adds extra context like 'at least one required', window rolling vs calendar, and format parameter purpose. Adds moderate value 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 decomposes portfolio changes over time, specifies verb 'decompose' and resource 'portfolio changes', and explicitly distinguishes from siblings (get_portfolio_summary and get_pnl_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?

Provides explicit when-to-use guidance: explains supported address types, window options, format control, and caveats about truncation. Differentiates from siblings, helping agent choose correctly.

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, non-destructive, idempotent, and open-world. The description adds rich behavior context: fan-out across chains, address folding for non-EVM ecosystems, response structure with totalUsd and breakdown, error degradation via coverage, and mention of follow-up phases (Solana staking). 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 long due to complexity but is efficiently structured: core purpose in first sentence, then ecosystem-specific details, then usage guidance. Every sentence provides unique value, no redundancy. Properly 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?

No output schema, but the description adequately describes return fields: totalUsd, breakdown by category/chain, raw per-protocol arrays, specific fields like tronUsd, tronStakingUsd, coverage. Also handles edge cases (multi-wallet, single wallet, error degradation). Complete given the 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 covers all 11 parameters with detailed descriptions. The tool description adds value by explaining interdependencies (mutual exclusions between single/multi address params, behavior with single wallet vs wallets array, constraints like max items for tronAddresses (10) and solanaAddresses (5)). Slightly richer than baseline 3.

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

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

The description clearly states the tool does 'one-shot cross-chain portfolio aggregation' and lists the specific protocols and assets included. It distinguishes itself from sibling tools by being the default for portfolio value questions, contrasting with per-protocol readers.

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 'Default tool for 'what's in my portfolio?' / 'total value' questions; prefer it over calling each per-protocol reader separately.' This provides clear when-to-use guidance and warns against unnecessary multiple calls, fitting the usage guidelines dimension perfectly.

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, idempotentHint, etc. The description adds critical context: the tool surfaces data, does not endorse or pick tokens, and clarifies what a high score means (contract safety, not investment upside). 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 longer than average but well-structured with clear sections (SCOPE, AGENT BEHAVIOR). Every sentence adds value, though some repetition could be trimmed. Front-loaded with 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?

The tool has one parameter, no output schema, and the description fully explains the return value (0-100 score, higher safer), the factors considered, and the intended use cases. Covers all necessary context for an agent to invoke correctly.

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

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

Input schema has zero description coverage for the only parameter 'protocol'. The description fully compensates: explains it's a DefiLlama slug, works across chains, and provides concrete examples (Solana, Tron, EVM). Makes the parameter unambiguous.

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 a 0-100 risk score for a DeFi protocol based on multiple factors (TVL, trend, age, audits, bug bounty). It specifies the protocol argument as a DefiLlama slug and gives examples across chains, distinguishing it from any sibling tool like check_contract_security or get_coin_price.

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: use for protocol due-diligence (e.g., comparing Aave V3 vs Compound V3), and explicitly warns against using for speculative token picks. Provides clear 'do NOT use' scenarios and explains what the score does and does not indicate.

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