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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the behavioral note 'Works offline,' which is useful beyond annotations. However, it does not elaborate on return format or edge cases, though the output schema mitigates that. This aligns with the calibration example where a small extra context earned a 3.

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

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

The description is concise and front-loaded. The core purpose and offline capability appear in the first sentence, followed by a clear Args list with examples. Every sentence serves a purpose, with no fluff or repetition.

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

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

For a simple conversion tool with an output schema present, the description covers all necessary information to invoke it correctly: parameters, allowed unit values, and an example. It does not discuss invalid inputs or precision, but these are minor and not critical for a basic conversion. The offline note is a helpful addition. It is sufficiently complete.

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

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

Schema coverage is 0% and the schema provides only titles with no descriptions. The description fully compensates by explaining each parameter: it gives an example for 'amount' and enumerates allowed values for 'from_unit' and 'to_unit' (btc, mbtc, bit, sat). This adds meaning the schema lacks, making it easy for an agent to supply correct values.

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 a specific verb and resource: 'Convert between Bitcoin units.' This distinguishes it from sibling tools focused on validation, derivation, or transaction queries, leaving no ambiguity about its function.

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

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

Usage is implied rather than explicit. The description says it converts units, so an agent can infer when to use it, but there is no mention of alternatives or when not to use it. It does not provide any exclusion or comparison with sibling tools, so it lacks explicit routing guidance.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds meaningful behavioral context: it works offline, cannot sign or broadcast, and shows signing status. This helps the agent set expectations without overstepping.

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 compact and front-loaded, leading with the core action and outputs, then adding usage context, offline/capability constraints, and parameter explanations. Every line earns its place.

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

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

Given the simple schema, annotations, and presence of an output schema, the description covers everything needed: what the tool does, its safety guarantees, its limitations, and its parameters. No critical gap remains.

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 the description carries full responsibility for parameter meaning. It clearly explains that 'psbt' is base64-encoded and that 'network' only affects address rendering, which is genuinely useful 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 states a specific verb ('Decode') and resource ('PSBT') and clarifies the key outputs: destinations, fee, and signing status. This clearly distinguishes it from sibling tools like decode_raw_transaction and decode_wif.

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 frames the use case: 'check where funds are going before signing in your wallet.' It does not name alternatives or exclusions, but the context is specific enough for an agent to select this tool correctly among the decode/derive 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 mark this as read-only and non-destructive. The description adds useful behavioral context: it works offline and focuses on showing destinations. It also clarifies the network parameter's role in address rendering, going beyond the schema's bare type information.

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 short and front-loaded with the core action and output. It includes only necessary details, with parameter explanations separated cleanly. Every sentence adds value and there is no repetition of schema fields.

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 read-only decoder with an output schema present, the description covers the essential inputs and behavioral context. It does not explain error cases or exact network value formats, but these are not critical given the simple parameter list and output schema availability.

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 the description must compensate. It does: raw_tx is explained as 'the raw transaction hex' and network as 'Override the server's network for address rendering.' While brief, this provides meaningful semantics for both 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 uses a specific verb and resource: 'Decode raw transaction hex, showing destinations.' It clearly identifies the input format and output focus, distinguishing it from sibling tools like decode_script, decode_wif, and decode_psbt.

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 'Works offline,' which gives some context about when it is appropriate to use. However, it does not explicitly explain when to choose this over related decoders or mention any exclusions, leaving usage guidance mostly 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that by stating 'Works offline' and clarifying that network only affects address rendering. 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 compact and front-loaded: a one-sentence purpose, a one-sentence behavioral note, and a minimal Args block. Every line earns its place, and there is no redundant framing or fluff.

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

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

For a two-parameter read-only tool with an output schema, the description covers the operation, offline behavior, and both parameters sufficiently. The only notable gap is the lack of explicit guidance on selecting this tool over sibling decode tools, but that is a minor omission given the clear scriptPubKey focus.

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 has no property descriptions (0% coverage), so the description must compensate. It does so by explaining script_hex as 'the hex-encoded script' and network as an override for address rendering. This adds real meaning beyond the bare schema, though accepted network values are not enumerated.

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

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

The description states a precise verb and object: 'Decode a scriptPubKey to its type and address.' This clearly identifies the resource and expected output. It also distinguishes the tool from sibling decoders like decode_wif, decode_psbt, and decode_raw_transaction by specifying scriptPubKey as the input.

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

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

The description clearly implies when to use it: when an agent has a hex-encoded scriptPubKey and needs its type and address. It also notes that the operation works offline, which is useful context. It does not explicitly name alternatives or exclusion criteria, but the resource-specific language is enough for basic routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds genuine behavioral context by stating 'Works offline' and 'The private key is not echoed back', and it discloses the MCP_BITCOIN_ALLOW_MNEMONIC=true requirement. No contradiction with annotations exists.

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 front-loads the purpose, then gives a requirement and a short argument list. Every sentence is informative and there is no redundant text. The structure is clear, though the requirement line could be slightly expanded.

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

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

Given that an output schema exists and annotations cover the read-only safety profile, the description covers the essential invocation details: purpose, offline behavior, a required environment flag, and both parameters. It does not spell out error behavior or allowed network values, but these are not essential for a correct call. Overall it is complete enough for a small 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 description coverage is 0%, but the description's 'Args:' section compensates by explaining both parameters: 'wif' is the WIF-encoded private key, and 'network' overrides the server's network for the call. This clarifies the meaning of the default null for network, which the schema leaves implicit. The explanations are terse but add real value over property titles.

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

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

The description states a specific operation ('Show the public key and addresses') on a specific resource ('a WIF private key'), which clearly distinguishes it from sibling decoders like decode_raw_transaction or decode_script. The phrase 'Works offline' adds a useful constraint. No ambiguity remains about what the tool does.

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

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

The description gives a clear context: the tool decodes a WIF private key to its public key and addresses, and it works offline. However, it never says when to prefer this over alternatives (e.g., derive_addresses, get_address_from_pubkey) or when not to use it. The only operational guidance is the environmental prerequisite, so usage selection relies on inference.

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

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

Annotations already indicate read-only and non-destructive behavior, and the description adds valuable context: it works offline, xpub paths need no special permission, mnemonic usage requires MCP_BITCOIN_ALLOW_MNEMONIC=true, and count is capped at 500. 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 well-organized: a front-loaded one-sentence summary, then permission/usage notes, then a clear Args block. Each line earns its place and the length is justified by the eight parameters.

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

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

Given the tool's complexity—8 parameters, BIP-39 passphrases, BIP-44 account/change semantics, and network overrides—the description is highly complete. It explains all parameters, security prerequisites, and operational constraints, while return behavior is covered by the output schema.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it succeeds: every parameter is explained with meaningful semantics (source formats, passphrase scope, address type list, change meaning, count cap, network override).

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

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

The description clearly states that the tool derives addresses from an xpub or seed phrase, with a specific verb and resource. It does not explicitly contrast itself with siblings like derive_xpub or derive_from_path, so it earns a 4 rather than a 5.

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

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

The description gives useful guidance about preferring xpub/ypub/zpub and the permission requirement for mnemonics, but it does not explain when to choose this tool over siblings such as derive_from_path or get_address_from_pubkey. Usage context is implied rather than explicitly contrasted.

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 and non-destructive, which the description reinforces by describing a deterministic derivation that works offline. It additionally discloses an environment requirement (MCP_BITCOIN_ALLOW_MNEMONIC=true) and clarifies that it operates on a master seed, which the schema alone does not convey. The description does not contradict 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 compact multi-line block that front-loads the key action and purpose. It then lists parameters efficiently. Some redundancy exists (e.g., 'works offline' could be inferred, but it does add safety context).

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 (5 parameters, 0% schema coverage) and the presence of an output schema, the description fully covers what the tool does, key constraints (works offline, env requirement), and parameter semantics. It does not state the return format, but with an output schema present, that is not required. It also distinguishes from siblings.

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

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

Schema coverage is 0% (no property descriptions), so the description must carry all meaning. It explains the role of each parameter: mnemonic as the master seed, index for derivation, passphrase as optional, child_mnemonic_words for selecting seed phrase length or raw entropy, and num_bytes for entropy length. This adds significant value beyond the bare 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?

States a specific verb ('Derive'), resource ('child seed or entropy from a master seed'), and the exact standard (BIP-85). Clearly distinguishes from sibling tools like 'generate_mnemonic' (which creates new seeds) and 'derive_from_path' (which derives at a generic BIP-32 path).

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

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

Explains when to use this tool for BIP-85 derivation and distinguishes between child seed phrase and raw entropy via the parameters. However, it does not explicitly state when NOT to use it or mention alternatives; the sibling list is large, but the description implies usage for BIP-85, which is distinct.

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 annotations already provide readOnlyHint=true and destructiveHint=false Schwell. The description adds meaningful behavioral guarantees beyond those: 'Works offline' and 'Private keys are never returned.' These are valuable context that helps an agent set expectations and reassure the user about security.

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 compact and well-organized: a one-sentence purpose, two brief behavioral notes, then a clear args list. Every line adds information, with no filler or repetition.

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

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

Given the output schema exists, return values do not need to be explained. The description covers the operation's purpose, offline/security behavior, and all parameters with enough detail for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It compensates well by documenting all four parameters: source types, path format with an example, passphrase applicability, and network override behavior. This meaningfully exceeds what the bare schema provides.

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

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

The description clearly states the action ('derive') and the resource ('one key at an arbitrary BIP-32 path'), plus the distinctive output scope ('in every address format'). It is specific enough to understand the core function, though it does not explicitly differentiate itself from sibling tools like derive_addresses or derive_xpub.

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

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

No guidance is given for when to prefer this tool over alternatives. The description does not mention derive_addresses, derive_xpub, or any conditions that would make this tool the right choice, leaving usage context to inference.

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 readOnlyHint annotation, the description adds that the operation works offline and requires a specific environment flag. It also communicates a safe workflow pattern (derive once, reuse the xpub), which is useful behavioral context not present in annotations.

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

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

The description is compact and well-structured: a one-line purpose, a short requirement note, a workflow sentence, and a bulleted parameter list. Every sentence earns its place and the most important constraints are front-loaded.

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

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

Given the output schema exists and annotations cover safety, the description is complete: it states prerequisites, purpose, usage pattern, and all parameter semantics. Nothing critical is missing for an agent to decide when and how to invoke this tool.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining every parameter: mnemonic, standard with allowed BIP values, passphrase optionality, account index, and network override. This gives the agent enough semantic detail to construct correct calls without opening the schema.

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

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

The description uses a specific verb ('Extract') with a clear resource ('account xpub/ypub/zpub from a seed phrase') and immediately distinguishes the tool by noting it works offline. It clearly separates this from sibling derivation tools like derive_addresses or derive_from_path by focusing on the seed-phrase-to-xpub output.

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

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

The description gives clear usage context: run once offline, capture the xpub, then keep later queries watch-only. It also states the required MCP_BITCOIN_ALLOW_MNEMONIC=true prerequisite, though it does not explicitly name alternatives or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a useful behavioral note that a backend is required, and clarifies that network overrides the server's network. It does not describe error behavior (e.g., what happens if target_blocks is out of range) or the nature of the estimate, but the output schema likely covers return structure. Overall, adequate given the annotations.

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

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

The description is two compact sentences followed by a clean Args block. The purpose is front-loaded, and the parameter documentation is structured and scannable. Every sentence earns its place with no filler.

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

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

The tool is simple: two optional parameters, both documented, and an output schema exists to explain return values. The description is complete for making the call correctly. It is missing only usage context relative to sibling tools, but that gap is already accounted for in the usage guidelines dimension.

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%, but the description fully compensates by documenting both parameters: target_blocks includes its range (1 to 1008) and purpose, and network explains it overrides the server's network. This adds meaningful semantics beyond the schema, which only contains titles and defaults.

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

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

The description opens with a specific verb and resource: 'Estimate the fee rate to confirm within a number of blocks.' This clearly states what the tool does and its core parameter. However, it does not distinguish itself from sibling tools like get_recommended_fees or get_fee_histogram, which also involve fee estimation, so it misses the differentiation criterion.

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 almost no guidance on when to use this tool versus alternatives. 'Needs a backend' is a prerequisite, not a usage condition. It never mentions get_recommended_fees or get_fee_histogram as alternatives or states under what circumstances an agent should pick this tool instead.

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 the tool as read-only and non-destructive. The description adds meaningful behavioral context beyond annotations: it works offline, requires a specific environment variable, returns the phrase into the conversation/transcript, and carries security caveats. This is helpful transparency, though not exhaustive about internal generation 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?

Front-loaded purpose, then concise caveats and parameter documentation. Every sentence adds value, with no filler or redundant restatement of the tool name.

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

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

With one optional parameter and an output schema present, the description covers prerequisites, security behavior, and valid arguments. Nothing critical is missing for an agent to understand how to call 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 provides no description for word_count (0% coverage), so the description fully compensates by enumerating valid values (12, 15, 18, 21, 24) and stating the default. This is essential for correct invocation and goes far beyond the bare 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?

States a specific verb ('Generate') and a specific resource ('BIP-39 seed phrase'), making the tool's purpose immediately clear. It also distinguishes itself from the sibling validate_mnemonic by focusing on creation rather than validation.

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 context: use when a new mnemonic is needed, it works offline, and MCP_BITCOIN_ALLOW_MNEMONIC=true is required. It does not explicitly name alternatives like validate_mnemonic for when-not-to-use this tool, but the warning about not using the result for real funds adds an important usage boundary.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the useful behavioral fact that the tool works offline and that pubkeys may be compressed or uncompressed, but it does not disclose error behavior or output format, which is partly covered by the output schema.

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

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

The core purpose is front-loaded in one sentence, and the Args block is compact and directly aligned with schema properties. Every line adds relevant information with no filler.

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

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

For a simple read-only conversion tool with an output schema, the description covers the essential inputs and offline behavior. It does not fully explain what 'all' produces or which network values are valid, but the output schema and parameter defaults mitigate the gap.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains pubkey as hex-encoded and compressed/uncompressed, enumerates address_type options including 'all', and clarifies network as an override of the server's network. Network values and the meaning of 'all' remain somewhat underspecified.

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

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

The description states a specific verb and resource: convert a hex public key to an address. It clearly conveys the tool's core function, though it does not explicitly distinguish it from sibling derivation tools like derive_addresses or derive_xpub.

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

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

No when-to-use versus alternative guidance is provided, and no sibling tools are mentioned. 'Works offline' is the only contextual hint, but it does not help an agent choose this tool over similar derivation or conversion 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?

With readOnlyHint and destructiveHint already covering safety, the description adds useful behavioral context: it returns both confirmed and unconfirmed balance, and it requires a backend. These details go beyond the annotations and help set expectations about dependency and output scope.

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 brief and front-loaded with the core purpose, and the Args list is clear. However, the phrase 'Needs a backend' is vague and not elaborately useful, slightly reducing the overall value of the 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 the tool's low complexity and the presence of an output schema, the description provides enough information for an agent to invoke it correctly: purpose, parameter semantics, and a backend prerequisite. It does not address usage alternatives, but that gap is already captured in usage_guidelines.

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 the description's Args section carries the burden. It clearly explains that address is a Bitcoin address and that network overrides the server's network, adding meaning beyond the bare type definitions. It lacks specifics like network format or allowed values, so it is not a 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 states a specific verb ('Get'), resource ('an address'), and output ('confirmed and unconfirmed balance'), which clearly distinguishes it from sibling tools like get_utxos or get_tx_history. It explicitly mentions both balance types, making its function 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 offers no guidance on when to use this tool versus alternatives. The only usage-related note, 'Needs a backend,' is a prerequisite rather than a selection criterion, and it does not explain what a backend means or when this tool is preferable to other get_* 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?

The annotations already establish this as read-only and non-destructive. The description adds useful operational context beyond that: the tool requires a backend, and the network parameter can override the server's network. These are behavioral details not present in the structured metadata.

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 compact and front-loaded with the core purpose, followed by a short prerequisite and clear per-parameter explanations. Every sentence earns its place; there is no redundant content.

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 two-parameter read-only tool with an output schema, the description covers the essentials: purpose, parameter semantics, and a key prerequisite. It does not explain return values, but the output schema handles that. The only minor gap is that 'backend' is not clarified further, though this may be a system-level concern.

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 the description carries full responsibility for parameter meaning. It explains that 'block' can be a block hash or a height number, and that 'network' overrides the server network. This is significant added value beyond the bare schema types.

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

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

The description states a specific action ('Fetch a block header') and the two accepted identifiers ('by hash or height'). This clearly distinguishes it from siblings like get_block_height (which likely returns the current height) and get_transaction. The verb and resource are 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 only a vague prerequisite ('Needs a backend') and no guidance on when to choose this tool over alternatives. It does not mention get_block_height or get_transaction, which are the natural siblings to compare against. An agent would have to infer usage context from the tool name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting that a backend is required and that the network parameter overrides the server's network for this call only. This goes beyond the structured annotations without contradicting them.

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

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

The description is extremely compact and front-loaded: the purpose is stated in the first sentence, and the only parameter is explained in one line. There is no redundant phrasing or unnecessary detail. Every sentence earns its place.

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

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

For a simple read-only getter with one optional parameter and an output schema, the description covers the essential invocation context. 'Needs a backend' signals a real prerequisite, though it is slightly vague about what happens if no backend is available. Overall, an agent has enough information to call the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the 'network' parameter. It does so by stating 'Override the server's network for this call', which adds meaningful semantics beyond the raw string/null schema. It does not enumerate accepted network values, but for a single optional parameter this is adequate.

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

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

The description states a specific verb ('Get') and resource ('current chain tip height'), making the tool's core purpose unmistakable. This clearly distinguishes it from sibling tools like get_block, which retrieves a specific block, and other chain data tools. The wording is direct and not a tautology.

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

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

The description implies the tool is used when the current chain tip height is needed, and it notes a prerequisite ('Needs a backend'). However, it does not explicitly contrast this tool with alternatives such as get_block, nor does it state when not to use it. The usage context is mostly inferred from the purpose rather than clearly prescribed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the note 'Needs a backend', which is useful context beyond annotations, but doesn't explain what happens if backend is unavailable or any other behavioral traits like rate limits.

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

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

The description is concise with two short sections. It front-loads the main purpose and then describes the parameter, though the 'Needs a backend' note is placed somewhat awkwardly after the first sentence, but overall efficient.

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

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

Given it has an output schema, return values are covered. But for a read-only tool with one optional parameter, it misses clarifying the network parameter's format and any backend requirements. It's adequate but not thorough.

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 the description must explain the network parameter. It says 'Override the server's network for this call', which clarifies its purpose, but doesn't state valid values, defaults, or format, leaving significant ambiguity.

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

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

The description states it 'get the mempool fee distribution', which is a clear verb and resource. However, it doesn't differentiate from sibling tools like estimate_fee or get_recommended_fees which also deal with fees, so the purpose is clear but not distinguished.

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

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

No guidance on when to use this tool versus alternatives like estimate_fee or get_recommended_fees. The only hint is the need for a backend, which is terse and not elaborated, so usage context is minimal.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the backend requirement and the unconfirmed-transaction scope, which is useful, but does not explain behavior for missing entries or error cases. 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 short and front-loaded with the main purpose, followed by a clean args list. The phrase 'Needs a backend' is slightly cryptic but does not bloat the text.

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

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

Given the low complexity, output schema presence, and annotations, the description covers the essential semantics of both parameters and the tool's role. The only mild gap is the unclear 'Needs a backend' phrase, which is not fully elaborated.

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%, but the description compensates well: txid is specified as a 64-hex-character transaction ID, and network is explained as an override for the server's network. This adds meaningful meaning beyond the bare schema types.

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

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

The description states a clear verb and resource: 'Get mempool details' for 'an unconfirmed transaction'. This distinguishes it from aggregate mempool tools like get_mempool_info by focusing on a specific transaction entry, though it does not explicitly name alternatives.

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 gives context clues: the tool is for unconfirmed transactions and 'needs a backend'. However, it does not say when to choose this over siblings like get_transaction or get_raw_transaction, nor does it mention any exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a useful dependency ('Needs a backend') and the network-override behavior, but it does not explain failure behavior or what happens if no backend is available. The added behavioral context is modest but not absent.

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

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

The description is front-loaded with the core purpose, then adds a necessary prerequisite and a one-line parameter explanation. Every sentence earns its place, and there is no filler or repetition.

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

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

There is an output schema, so return values do not need to be described. For a simple one-optional-parameter read tool, the description covers the purpose, the prerequisite, and the parameter semantics. The only notable gap is guidance on how to handle a missing backend or why this tool is preferable to mempool/fee siblings.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning. It does: 'network: Override the server's network for this call' explains what the parameter actually does beyond the bare anyOf string/null schema. It could enumerate valid network values, but this is a meaningful compensation for the schema gap.

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 a specific verb ('Get') and a clear resource ('mempool size, vsize and minimum fee rate'). This is distinct from the sibling get_mempool_entry, which targets individual mempool entries, so an agent can tell them apart without opening the schema.

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 only usage hint is 'Needs a backend.' It does not say when to prefer this over related siblings like get_mempool_entry, estimate_fee, or get_fee_histogram, nor does it state any exclusions or conditions beyond backend availability.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the backend requirement and notes the network override behavior, which is useful context. However, it does not disclose what happens on invalid txids, backend absence, or network mismatch, so it only partially exceeds annotation coverage.

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 short and front-loaded with the core action, followed by a concise parameter list. The 'Needs a backend' note is slightly terse but still earns its place. No redundant or filler sentences are present.

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, has an output schema, and annotations cover the read-only nature. The description covers prerequisites and parameter basics, but it leaves out acceptable network values and error behavior, and it offers no routing guidance among the many transaction-related siblings. This is adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does: txid is defined as a 64-hex-character transaction ID, and network is defined as an override for the server's network. This adds real value beyond the bare schema, though valid network values are not enumerated.

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

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

The description states a specific verb and resource: 'Fetch a transaction's raw hex', which clearly distinguishes it from siblings like get_transaction or decode_raw_transaction by emphasizing the raw hex output. It could more explicitly contrast with those siblings, but the core purpose is 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 gives no guidance on when to use this tool versus alternatives such as get_transaction or decode_raw_transaction. The only contextual note, 'Needs a backend', is a prerequisite rather than a usage guideline. An agent is left to infer the appropriate 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?

The annotations already signal a safe read-only call, so the description does not need to repeat safety. It adds useful context: the call requires a backend and the optional network parameter overrides the server's network. These are modest but genuine behavioral details, so a mid score is appropriate.

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 short, front-loaded with the primary function, and contains no filler. The args section is compact and directly maps to the schema.

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 one-parameter, read-only tool with an output schema and annotations, the description covers purpose, prerequisite, and parameter semantics. It lacks sibling-routing guidance, but that does not block correct invocation, so it is largely complete.

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

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

Schema coverage is 0%, but the description explicitly explains the only parameter: 'network: Override the server's network for this call.' This adds real meaning beyond the bare string/null schema and is sufficient for a single optional parameter.

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

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

The description opens with a concrete verb and object – 'Get economy, normal and priority fee rates' – so an agent immediately knows the tool returns categorized recommended fee rates. This distinguishes it from generic siblings like estimate_fee or get_mempool_info, though it does not explicitly name the closest alternative.

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?

There is no statement of when to choose this tool over sibling tools such as estimate_fee or get_fee_histogram. The only guidance is 'Needs a backend', which is a prerequisite rather than a usage rule, so the agent gets little help with routing.

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 this as read-only and non-destructive; the description does not contradict them. It adds the operational context that a backend is required and that fetching and decoding happen together, but it does not disclose failure modes or further behavioral details.

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 compact and front-loaded: a purpose statement, a one-sentence prerequisite, and a concise Args block. Every line contributes useful information with no filler.

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

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

For a two-parameter read-only tool with an output schema, the description covers the operation, both parameters, and the backend prerequisite. It is slightly incomplete in not guiding the agent toward sibling tools such as get_raw_transaction or decode_raw_transaction, but nothing essential for invoking the tool is missing.

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

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

Schema description coverage is 0%, and the description fully compensates by documenting both parameters: txid must be a 64-hex-character string, and network overrides the server's network. This goes well beyond the schema's bare string/null types.

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?

States a specific verb and resource: 'Fetch and decode a transaction by txid.' This clearly identifies the operation and distinguishes it from siblings like get_raw_transaction or decode_raw_transaction, which focus on raw or decoded-only views.

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 when a decoded transaction is needed and gives the prerequisite 'Needs a backend.' However, it does not explicitly mention when to prefer this over sibling tools or when not to use it, leaving alternative selection to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds non-obvious behavior: results are newest-first and pagination is cursor-based via next_cursor/after_txid. It also warns that a backend is required. 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 compact: a one-line purpose, a pagination note, and a flat Args list. It avoids irrelevant detail, though 'Needs a backend' is terse and could be slightly clearer.

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?

All invocation-critical details are present: required address, maximum limit, cursor paging, and network override, while the output schema covers return shape. The vague 'backend' prerequisite and lack of valid network values keep it from being fully 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?

Schema description coverage is 0%, and the description fully compensates by explaining all four arguments: address to look up, limit up to 100, after_txid as a continuation cursor, and network as a server override. This adds essential meaning beyond the bare schema titles.

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

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

The description opens with a specific verb and resource ('Get an address's transaction history') and adds ordering ('newest first'), making the result unambiguous. It does not explicitly contrast with sibling tools like get_transaction or get_utxos, but the history focus is clear enough.

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 operational guidance such as cursor pagination and the backend requirement, but it does not explicitly state when to use this tool versus alternatives like get_balance or get_transaction. Usage context is implied by the wording rather than stated with exclusions or fallback instructions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'Needs a backend' prerequisite, which is a useful behavioral note, but it does not disclose other traits like pagination, error conditions, or network override implications.

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 exceptionally concise: a single-purpose line plus a clean parameter list. No wasted words, and the key purpose is front-loaded.

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

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

With an output schema present, return values don't need description. The description covers the tool's purpose, parameters, and a prerequisite. It could mention potential edge cases or limitations, but it is sufficient for a straightforward read-only list operation.

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 explicitly explains all three parameters in the Args section, compensating for the 0% schema description coverage. It clarifies the meaning of address, min_confirmations, and network beyond the bare schema definitions.

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

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

The description states a specific verb ('List') and resource ('an address's unspent outputs'), making the purpose clear. It doesn't explicitly name a sibling alternative, but the function is distinct from tools like get_balance or get_tx_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 mentions a prerequisite ('Needs a backend'), which is useful context, but it does not explain when to use this tool versus alternatives or when to avoid it. It gives no exclusions or comparison 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 declare this as read-only and non-destructive. The description adds value by indicating that the tool evaluates 'reachability,' which implies it may perform network probes or live checks rather than just returning stored configuration. This is a useful behavioral nuance beyond the annotation flags.

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, well-structured sentence that front-loads the action and object, then adds the relevant output dimensions. Every word contributes meaning, with no fluff or redundancy.

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

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

For a zero-parameter listing tool with a readOnlyHint, a false destructiveHint, and an output schema, the description is nearly complete. It clearly states what is listed and the key attributes returned. It could go slightly further by noting that this is the preferred way to enumerate backend status versus checking a single backend with ping, but the current coverage is strong.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. The input schema is already complete with an empty properties object, giving a baseline of 4. The description does not need to explain any 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 uses a specific verb ('List') and a clear resource ('configured backends'), and it further specifies what is returned: reachability and capabilities. This is distinct from sibling tools like ping or get_balance and leaves no ambiguity about the tool's 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?

The description implies this is the go-to tool for an overview of configured backends and their state, but it does not explicitly state when to use it instead of related tools such as ping for reachability checks. No alternatives or exclusions are named, so guidance is only 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is well covered. The description adds useful operational context—this is a health/reachability check and an initial diagnostic step—but does not disclose details like the exact shape of the reachability report, which the output schema can carry.

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 short, purposeful sentences. The core purpose is front-loaded, and the usage guidance is tacked on without any filler or redundant restatement of the tool name.

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 parameterless, read-only, health-check tool with an output schema present, the description covers what it does, its scope, and when to invoke it. No critical operational gap remains for an agent to call it 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 tool has 0 parameters and the schema reflects that, so the description has no parameter semantics to add. The 0-param baseline of 4 applies; there is nothing undocumented that the description would need to compensate for.

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 a specific verb ('Check') and resource ('server health and which backends are reachable'). It is not a tautology of the name 'ping' and it differentiates this tool from sibling 'list_backends' by focusing on reachability/health rather than just listing backends.

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

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

The description gives explicit situational guidance: 'Start here when other tools report backend errors.' This tells the agent when to use the tool, though it does not enumerate when-not conditions or explicitly compare against alternatives like list_backends.

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 establish that this is read-only and non-destructive. The description adds meaningful behavioral context by stating it works offline and that it determines network membership, which goes beyond the structured 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 compact: a clear purpose sentence, an offline behavior note, and concise parameter definitions. Every sentence adds value and the most important information 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 two-parameter tool with annotations and an output schema, the description is largely complete. It covers purpose, offline capability, and parameter semantics; only minor details like supported network values or address formats are missing, but these are not critical given the output schema.

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

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

With 0% schema description coverage, the description carries the burden of explaining parameters. It explains the network parameter clearly as an override to the server default, and identifies address as the input to check, though it does not specify address format expectations.

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 purpose: validating an address and identifying its network. This distinguishes it from sibling validate_mnemonic, which targets a different input 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 notes that the tool works offline, which provides some usage context, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. The differentiation from validate_mnemonic 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=true and destructiveHint=false, so safety behavior is covered. The description adds meaningful behavioral context beyond annotations: it works offline and performs three specific checks (word count, wordlist, checksum), which helps an agent predict the tool's 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 short, front-loaded with the core purpose, and every line adds value. The 'Args' section is compact and directly supplements the schema without unnecessary filler.

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

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

For a one-parameter validator with an output schema and annotations already covering side effects, the description is complete: it states the exact validation scope, offline operation, and argument format. No critical information is missing.

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

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

Schema description coverage is 0%, so the description must explain the parameter. It does by defining 'mnemonic' as 'the space-separated seed phrase to check,' which adds format and role beyond the raw schema field name.

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 a specific verb ('Check') with a concrete resource ('BIP-39 phrase') and explicitly names the validation dimensions: word count, wordlist, and checksum. This clearly distinguishes it from siblings like generate_mnemonic and validate_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?

The description provides useful usage context by stating 'Works offline' and by specifying exactly what kind of phrase it validates, so an agent can infer when to choose this tool. It does not explicitly name alternatives or state when not to use it, but this is straightforward for a one-purpose validator.

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