Bitview

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds accepted input formats and the underlying REST route, but says nothing about error behavior for malformed or unknown addresses, or about rate limits — the gaps that matter for an open-world read.

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 the payload summary, then format support, then a docs link and the REST route. The REST operation line is mild filler given the docs link, but everything else 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?

With an output schema covering return values and annotations covering safety, the description only needed to nail input formats and scope, which it does. The remaining hole is routing relative to validate_address and the address tx/utxo 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 description coverage is reported at 0% (the real text sits behind a $ref), so the description has to carry the burden — and it does, enumerating P2PKH, P2SH, P2WPKH, P2WSH, P2TR, P2A and P2PK hex keys at 33 or 65 bytes. That is materially more than the terse schema text, though it doesn't clarify invalid-address handling.

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 opening sentence names the resource payload ('Balance and transaction counts') for an address lookup, which is specific enough to distinguish it from the list-style siblings (get_address_txs, get_address_utxos) by implication. It stops short of explicitly naming those alternatives, so differentiation relies on inference rather than statement.

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 when-to-use or when-not-to-use guidance and no mention of the many address-related siblings, notably validate_address or the tx/utxo list endpoints. An agent must infer from the phrase 'balance and transaction counts' that this is the summary endpoint rather than the detailed one.

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/idempotent/non-destructive, so the description's added value is the 25-item cap, the default, and the silent truncation behavior for larger values ('larger values return 25'). That truncation detail is genuinely useful and non-obvious. It omits ordering/return shape, but an output schema 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?

Front-loaded with the core purpose and cap; the pagination hint follows efficiently. The trailing 'REST operation: GET /api/address/{address}/txs/chain' line largely duplicates the docs link and the endpoint named in the pagination sentence, making it the one low-value element.

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 and a small two-parameter surface, the description covers purpose, cap/default, truncation, and pagination path — everything needed to invoke it correctly. The only remaining gap (how it differs from get_address_confirmed_txs_after) is a routing concern rather than a completeness one.

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%, and the description reinforces the one ambiguous parameter by restating the 25 default/maximum and the truncation rule, which matches the schema's note. The `address` param is fully described in the schema (with examples and P2PK hex-key support), so no further compensation is needed.

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 with a scoping qualifier: 'newest confirmed transactions for an address', with the cap and default spelled out. It does not, however, distinguish itself from siblings like get_address_txs (which may include unconfirmed) or get_address_confirmed_txs_after, so an agent must infer which of the three address-tx tools to pick.

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 context is implied by 'newest confirmed' and the pagination note gives a concrete next step. But that next step is a raw REST URL rather than the sibling tool get_address_confirmed_txs_after, which appears to exist precisely for that case — the description never mentions it or when to prefer 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?

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful edge-case behavior: transactions strictly older than the cursor and an empty array when the txid is outside the address history.

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 key pagination behavior is front-loaded in the first sentence, with the documentation link and REST operation following as supporting detail. There is no wasted 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?

An output schema exists, so return values need not be described in detail. Safety is covered by annotations, and the description supplies the important pagination, cursor, cap, and empty-result 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 67%, so baseline is 3, but the description clarifies that after_txid is exclusive and that max_txs is capped at 25 by default. It also explains that an unrecognized after_txid returns an empty array, adding meaningful cursor 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?

States a specific verb and resource: get the next confirmed transactions strictly older than after_txid. The pagination framing clearly distinguishes it from the unpaginated get_address_confirmed_txs sibling, even without naming 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?

The description clearly establishes pagination context through 'next' and 'after_txid' and notes the Esplora-canonical form. It lacks an explicit statement telling the agent to use get_address_confirmed_txs for the first page or naming other 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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered; the description adds the non-obvious privacy rationale and the exact matching/hashing semantics. It omits practical behavior such as whether short prefixes return bounded result sets or how many matches a 1-nibble prefix can yield.

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 short sentences, front-loaded with the matching rule, then the privacy intent, then the follow-up endpoint and REST path. Nothing is padding.

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?

Output shape is covered by the output schema and safety by annotations, so the description only needed to explain matching semantics, intent, and the next call, which it does. The missing piece is expected result cardinality for very short prefixes.

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%, and the description restates the prefix definition already in the schema rather than adding syntax or constraints. The address_type semantics live in the AddressOutputType enum and its description, so the description adds little beyond the structured fields.

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 (find) plus the exact resource and matching rule: address type plus the first 1-16 hex nibbles of RapidHash v3 over the raw payload. This is unmistakably different from sibling get_address, which the description also names for follow-up metadata.

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?

Gives clear usage context (privacy-preserving client-side wallet discovery, avoiding transmission of raw addresses or xpubs) and routes the agent to `GET /api/address/{address}` for metadata. It stops short of an explicit when-not-to-use or a direct comparison against get_address for plain lookup, so it is short of a 5.

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 read-only, idempotent, non-destructive access, and the description adds genuinely useful behavior beyond them: result ordering (newest first) and clamping semantics (values above 50 return 50). It does not mention empty-mempool behavior, but the key call-shaping traits are covered.

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?

One tight sentence front-loads the essential scope and ordering/cap behavior; the docs link and REST route are compact and directly useful for tracing the operation. 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?

An output schema exists, so return values need no explanation, and the description covers scope, ordering, and limits. Minor gaps like behavior on an empty mempool or max_txs=0 are left unaddressed but are not blocking.

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?

Both parameters are already described in the schema (address type, max_txs cap of 50), and the description largely echoes the same default/cap information. It adds no type or format detail the schema doesn't carry, 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?

States a specific verb and resource ('Get unconfirmed transactions for an address from the mempool') with a scope qualifier ('unconfirmed' / 'mempool') that separates it from confirmed-transaction siblings like get_address_confirmed_txs. An agent can pick it without inspecting schemas.

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 mempool/unconfirmed framing implies when to use it, and 'newest first' hints at the ordering contract, but there is no explicit when-to-use statement or named alternative (e.g., get_address_txs for confirmed history). Usage is inferable 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 read-only, idempotent, non-destructive, open-world, so the burden is lower. The description still adds real behavior: result ordering, the hard 50 cap, cursor semantics that skip the mempool when a confirmed txid is supplied, and the 422 outcome for an invalid cursor.

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

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

Three sentences, front-loaded with purpose, then pagination, then a docs/reference tail. Every clause carries information an agent needs; nothing is redundant padding.

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?

An output schema exists, so return values need not be described. The description still covers cap, ordering, cursor behavior, and the error case, which is everything an agent needs to invoke a 3-parameter paginated list 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 67% and the schema already documents the 50-item cap and cursor rules, so the description mainly restates them. It earns credit by explaining the continuation workflow ('the last returned txid as `after_txid`') and how `max_txs` interacts with mempool-first ordering, which the schema does not convey.

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?

Names a specific verb and resource ('Get transaction history for an address') and pins down scope: mixed mempool + confirmed, newest first, capped at `max_txs`. The phrase 'mempool transactions first and confirmed ones filling the rest' alone distinguishes it from siblings like get_address_confirmed_txs and get_address_mempool_txs.

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?

Gives concrete continuation instructions ('pass the last returned txid as `after_txid`') and names an alternative path for confirmed-only history. It stops short of explicitly saying when to prefer the dedicated confirmed/mempool sibling tools, so the routing guidance is clear but not exhaustive.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: unconfirmed UTXOs are returned, and mempool-spent outputs are filtered out. It does not cover ordering, volume, or size of results, but the output schema carries the return shape.

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

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

Two tight sentences with the inclusion/exclusion rule front-loaded, followed by a docs link and the REST operation. The REST line is mild overhead but gives useful traceability to the upstream endpoint; nothing is padded.

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?

A single-parameter read tool with annotated safety hints and an output schema. The description supplies the semantics annotations cannot express (unconfirmed inclusion, mempool-spend exclusion), and return values need not be restated. Nothing an agent needs in order to call it correctly 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 reported as 0% at the property level, though the referenced Address definition does carry 'Bitcoin address, or the hex public key of a P2PK output' plus three examples. The description adds only the REST path template `{address}`, which confirms a single required address argument but contributes no format or validation detail 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?

States a specific verb and resource ('Get unspent transaction outputs (UTXOs) for an address') and goes on to define its exact scope: unconfirmed outputs are included, outputs spent by mempool transactions are excluded. That inclusion/exclusion contract is what separates it from siblings like get_address_txs or get_address without the agent needing to open a 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?

Usage is implied rather than stated. There is no 'use this when... use get_address_txs instead when...' guidance, and no mention of prerequisites such as address validation via validate_address. An agent can infer the use case from the resource name, but the definition does not route it among the 70+ 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description contributes nothing beyond that: it does not say how an unknown hash is handled, what the response contains, or note that this appears to be the v0/deprecated-style endpoint versus get_block_v1. With annotations carrying the safety burden, this is acceptable but adds no value.

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 lines with zero waste, so it is concise. However, it is front-loaded with a documentation URL rather than a plain-language statement of what the call returns, which is the wrong lead for an agent deciding whether to invoke it. Brevity here reflects under-specification rather than disciplined editing.

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?

An output schema exists, so return values need not be explained, but the tool sits among dozens of block-related siblings and the description does nothing to disambiguate selection. For a public blockchain API wrapper, the absence of any note on network scope, deprecation status relative to get_block_v1, or error behavior leaves the agent guessing.

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 is a single required parameter whose schema (via $defs.BlockHash) already supplies a 64-hex regex pattern, two live examples, and a description of byte order, so the parameter is well specified without the description's help. The description adds no formatting, casing, or encoding guidance beyond the schema. Baseline 3 is appropriate when the schema does the work and the prose adds nothing.

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 title 'Block information' is close to a restatement of the name, and the only concrete content is the REST path `GET /api/block/{hash}`, from which an agent must infer that this fetches a single block by hash. That inference is correct but nothing in the text distinguishes it from near-identical siblings such as get_block_v1, get_block_header, get_block_status, get_block_txid, or get_blocks. Purpose is implied by the endpoint, not stated.

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 guidance and no alternatives are named, despite at least six sibling tools that operate on blocks. The only hint that a hash (not a height or timestamp) is the selector comes from the URL template, which the agent must reverse-engineer. No exclusions, no prerequisites, no indication of which chain/network applies.

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, idempotent, non-destructive, and open-world, so safety is covered. The description adds genuine behavioral detail beyond that: the deterministic selection order and the tie-break policy, plus the concrete REST route, which reassures an agent about repeatability. No mention of rate limits or error behavior for out-of-range timestamps.

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 rule is the very first sentence, with the doc link and REST route demoted to secondary lines. Every element earns its place and nothing is padded.

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?

A single-parameter read tool with an output schema and full annotation coverage needs only the selection semantics to be callable correctly, and those are stated exactly. Return values need not be described because the output schema supplies them.

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 reported at 0%, so the description must carry the load; it does reinforce that the input is a UNIX timestamp and clarifies the inclusive boundary semantics ('at or before'). However, it doesn't restate the unit (seconds) or the non-negative bound, which live only in the schema's $defs, so it only partially compensates.

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 gives a precise verb+resource ('Find the block') and then fully specifies the selection rule: greatest header timestamp at or before the input, earliest height on ties. That level of specificity clearly separates it from height-based siblings such as get_block, get_block_hash_by_height, and get_blocks_from_height.

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 'at or before' plus tie-breaking rule tells an agent exactly which query shape this tool answers, which implicitly excludes height- or hash-addressed lookups handled by siblings. It stops short of naming an alternative tool or stating exclusions explicitly, so it lands at a clear-context 4 rather than a full 5.

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, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real context about output shape (the percentile set and rounding) that goes beyond the annotations, though it says nothing about rate limits or auth.

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-loads the operation and return set in one tight sentence, then a docs link and REST path. No filler; every element is 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?

With a full output schema and rich annotations, the description needs only to state what is fetched and how it differs from the precise variant, which it does. Minor omission of any auth/rate-limit context keeps it from a 5.

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 enum with all valid time periods is fully documented in the schema, so the schema does the heavy lifting. The description adds no meaning to `time_period` beyond what is already structured, 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?

States a specific verb and resource ('Get block fee rate percentiles') and enumerates exactly what is returned (min through max). It also distinguishes itself from the sibling get_block_fee_rates_precise by noting the whole sat/vB versus `/precise` 3-decimal variant.

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 parenthetical '(`/precise` for 3 decimals)' implicitly routes the agent to get_block_fee_rates_precise when finer precision is needed. There is no explicit when-not or prerequisite guidance, but the alternative is clearly signposted.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful context about units and decimal precision and includes the underlying REST operation, but does not mention response shape, pagination, or caching 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 and front-loaded: the first sentence states exactly what is returned, followed by a docs link and the REST endpoint. Every sentence earns its place, though the REST line is somewhat redundant for an agent that only needs the call semantics.

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

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

For a single-parameter read tool with annotations covering safety and an output schema covering return values, the description is adequate. The main missing piece is sibling differentiation against get_block_fee_rates and get_precise_fees, which matters given the dense list of similarly named tools.

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 single time_period parameter is fully documented in the schema with enum values and examples. The description only says 'for a time period' and adds no syntax or format details beyond what the schema already 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 states a specific verb and resource ('Get block fee rate percentiles') and enumerates the exact percentiles returned plus units (sat/vB, 3 decimals). This is more specific than the sibling get_block_fee_rates, but it does not explicitly state how it differs from that sibling or from get_precise_fees.

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 guidance on when to use this tool versus the closely named siblings get_block_fee_rates or get_precise_fees. The 'precise' qualifier implies a distinction, but the description never states it or gives 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the underlying REST path and docs link, which is useful for verification, but says nothing about units (sat/vB vs total BTC), aggregation method, or data granularity beyond the annotations.

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

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

One front-loaded sentence captures the purpose, followed by a docs link and REST operation line. The REST path is arguably redundant with the docs link, but overall there is very little 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?

With an output schema present and annotations covering safety and idempotency, the description need not explain return values. The metric definition ('average total fees per block') plus lookback period is sufficient to call it correctly; only the unit ambiguity slightly weakens 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?

Schema coverage is 100% — the single time_period parameter is fully enumerated with examples and a description in the schema. The description only restates the existence of a time period, adding no syntax or behavioral detail beyond the structured data, 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?

States a specific verb and resource with a quantified metric: 'average total fees per block for a time period.' This is distinguishable in wording from the fee-rate siblings (get_block_fee_rates, get_precise_fees), though the description never explicitly contrasts itself with 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?

No guidance on when to pick this over get_block_fee_rates, get_block_fee_rates_precise, get_precise_fees, or get_block_rewards. The agent is left to infer from names alone which fee/reward endpoint matches its need.

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 and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the response is plain text rather than a structured object — but says nothing about out-of-range heights, error behavior, or the underlying data source's eventual consistency.

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 payload is a single output statement front-loaded, followed by a doc link and the REST mapping. Every line is short and skimmable, though the docs link and REST operation are developer-facing filler for an agent that already has 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?

With a rich annotation set, a simple single-parameter schema, and an output schema present, the description needn't explain return values — and it doesn't. However, for a lookup by height it omits the one thing not covered elsewhere: what happens for heights beyond the chain tip or below zero.

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 reported as 0% at the property level, so the description should compensate, and it only does so implicitly via the `{height}` path template. It adds no range, no note that 0 is genesis, and no reference to the examples in the schema's Height definition.

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 the returned resource (block hash) and pins it to a specific REST operation, `GET /api/block-height/{height}`, which makes clear the input is a height and the output is a hash. It is not tautological and implicitly differentiates from `get_block` (full block) and `get_block_tip_hash` (tip), though it never names those siblings explicitly.

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

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

There is no guidance on when to use this tool versus alternatives such as `get_block`, `get_block_header`, or `get_block_tip_hash`, all of which live in the same sibling list. No prerequisites or exclusions are stated; the agent must infer the choice 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 readOnly, idempotent, non-destructive behavior, so the description's main added value is the exact output shape (hex string, 80 bytes). It doesn't mention error behavior for unknown hashes or confirm the response is a single string.

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?

One content sentence front-loads the key fact, followed by compact provenance lines. No waste, though the docs link line is arguably decorative.

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?

Output schema exists and annotations cover the safety profile, so the description only needs to state the resource and format, which it does. Minor gap: no mention of failure modes for invalid hashes.

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 reported as 0% and the description says nothing about the required 'hash' parameter, so it does not compensate. The $defs does document byte-order conventions, but that comes from the schema, not the 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?

States a specific verb and resource with a precise output format ('hex-encoded 80-byte block header'). It is distinguishable from get_block (full block) by the header-specific framing, though no sibling is named explicitly.

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

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

No guidance on when to use this versus get_block, get_block_status, or get_block_v1. The REST operation note and docs link give provenance but not selection criteria.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that by defining what the returned figure actually is (subsidy plus fees, averaged per block) and by pinning the underlying REST operation, which helps an agent reason about freshness and semantics. It says nothing about aggregation granularity or caching, which keeps it from a 5.

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 short lines, front-loaded with the metric definition, followed by the docs link and the exact REST path. Every element earns its place by helping an agent map the call or verify semantics; 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?

An output schema exists, so return values need not be described, and the annotations fully cover safety and idempotency. The description supplies the metric definition and the API mapping. The only real gap is the absence of disambiguation from adjacent reward and fee siblings in a very crowded tool namespace.

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%: the single `time_period` parameter is documented with its enum values and an example in the schema itself. The description only restates 'for a time period' and adds no format or behavioral nuance (e.g. whether 'all' is unbounded cost). Baseline 3 applies when the schema does the work.

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 metric ('Get average coinbase reward (subsidy + fees) per block') plus the scoping dimension ('for a time period'), which is precise enough to identify the resource. It clarifies the composition of the reward (subsidy + fees), which is genuinely useful definitional detail. It stops short of naming how it differs from close siblings like get_reward_stats or get_block_fees.

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 only implied: an agent can infer this is the aggregate per-block reward metric over a lookback window, versus the raw per-block fee tools. There is no explicit when-to-use, when-not-to-use, or named alternative among the several reward/fee/hashrate siblings that could plausibly be chosen 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered elsewhere. The description contributes the fixed result limit (10 blocks) and maps the tool to `GET /api/blocks`, which is modestly useful context, but says nothing about ordering, freshness, or what the 10-block window is relative to.

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

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

Extremely short and front-loaded: the substantive statement comes first, followed by a docs link and the REST path. Nothing is padded, though the docs-link and REST-operation lines are navigational filler rather than decision-relevant 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?

An output schema exists, so return values need not be described, and zero parameters mean nothing else is required to invoke it. What is missing is the sibling disambiguation that a family of this size demands; the definition is minimally adequate rather than 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 takes zero parameters, so there is no parameter semantics to explain; the baseline applies. The description adds the one constraint that would otherwise be a parameter (the implicit limit of 10), which is the only relevant thing to say.

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 the resource and the exact scope returned ("The last 10 blocks"), which is concrete enough for an agent to know what it yields. It does not, however, distinguish itself from near-identical siblings such as get_blocks_v1, get_blocks_from_height, or get_mempool_blocks, so the agent must guess which block-listing variant to pick.

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 when-to-use or when-not-to-use guidance at all. With eight-plus block-listing siblings, the absence of any routing hint (e.g. 'use get_blocks_v1 for the newer endpoint' or 'use get_blocks_from_height for pagination') is a real selection hazard.

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, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real behavior beyond that: the 10-block cap, descending order, and the two edge cases (genesis and past-tip returning not found).

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 rule and examples are front-loaded in two tight sentences; the docs link and REST operation line are minor overhead but not wasteful. Nothing essential is buried.

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

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

With an output schema present, the description needn't describe return values, and for a single-parameter read tool the explanation of range, ordering and edge cases is nearly sufficient. Only the ambiguity versus the sibling from-height tool remains unaddressed.

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 reported as 0%, so the description must carry the load, and it does: it defines the height parameter through a worked example (100 yields 100..91) and explains what height=0 means. It doesn't add format constraints beyond the schema's integer/minimum, but the semantics are covered.

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 ('Retrieve up to 10 blocks going backwards from the given height') and pins down the direction and cap. It is distinct from get_block (single block) though it does not differentiate itself from the near-identical sibling get_blocks_v1_from_height.

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?

Boundary conditions are spelled out (height=0 returns only block 0; past the tip is not found), which helps an agent avoid errors, but there is no explicit statement of when to pick this over get_blocks or get_blocks_v1_from_height. Usage is implied rather than routed.

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, non-destructive, and openWorld, so the safety profile needs no restating. The description adds that values are averages over a lookback window and maps to a REST endpoint, but says nothing about response shape, granularity of the series, or rate limits. Useful but thin beyond the annotations.

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

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

The core purpose is front-loaded in the first sentence with no padding, and the docs link plus REST operation line are compact reference aids. Slight redundancy in restating the time-period scoping, but nothing that wastes meaningful space.

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

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

With one fully described parameter, complete annotations, and an existing output schema, the description covers what an agent needs to invoke the tool correctly. The remaining gap is non-essential context such as aggregation granularity, which the output schema likely conveys.

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 single time_period parameter has a full enum listing with an example, so the schema already carries the semantics. The description only restates 'for a time period' and adds no format or interpretation detail beyond the schema. 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?

The description states a specific verb and resource ('Get average block sizes and weights') plus the aggregation scope ('for a time period'), so an agent knows this returns averaged aggregates rather than a single block. It does not contrast itself with nearby siblings such as get_block_fees, get_block_fee_rates, or get_blocks, which also return block-level metrics.

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 guidance on when to choose this over get_block_fee_rates, get_block_fees, or get_blocks, and no exclusions or prerequisites are given. The only implied usage cue is the 'time period' phrasing, which suggests trend/aggregate queries rather than point lookups.

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 a safe, idempotent read operation. The description adds useful non-obvious behavior: a block outside the best chain, including an unknown block, reports `in_best_chain: false` rather than failing. It does not discuss auth or rate limits, but those are less critical for this simple read.

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: the first sentence states the primary return semantics, and the following sentence clarifies the orphaned/unknown edge case. The docs link and REST provenance are compact and do not distract.

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 low-complexity one-parameter read tool with annotations and an output schema, the description covers the main behavior and edge case adequately. It omits explicit alternatives to sibling block tools and does not explain the hash parameter, but the schema and output schema cover much of the remaining burden.

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 `hash` parameter is only indirectly referenced through the REST path placeholder `{hash}`. The schema itself supplies the 64-hex pattern, examples, and BlockHash definition, but the description adds no meaningful guidance on the required format or meaning. With the context signal showing low schema description coverage, the description should compensate but does not.

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 read operation and its key return semantics: best-chain membership, height, next block hash, and the `in_best_chain: false` case for orphaned/unknown blocks. It clearly distinguishes status from retrieving a full block, but does not explicitly contrast itself with siblings like `get_block` or `get_block_header`.

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: check whether a known block hash is in the best chain and get its height/next hash. There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives among the many block-related 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 read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds the important behavioral scope of returning exactly the last 15 blocks and the content categories included, but it does not add further operational context such as ordering guarantees or limitations beyond that fixed window.

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-loads the key behavior: last 15 blocks with extended data. The documentation link and REST operation line are useful references but slightly redundant, keeping it just below maximally concise.

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

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

Given the tool has no parameters, a rich output schema, and explicit annotations, the description provides enough context for correct invocation. It explains the block window and extended data fields, though it could more clearly distinguish this endpoint from other recent-block siblings.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to compensate for. The 100% schema description coverage and empty input schema make the baseline score of 4 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 gives a specific verb and resource: retrieve the last 15 blocks with extended data including pool identification and fee statistics. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling block-listing tools such as get_blocks or get_blocks_from_height.

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 by saying it returns recent blocks with extended data, but it never states when to choose this over get_blocks, get_blocks_from_height, or get_blocks_v1_from_height. There are no exclusions or decision guidance for an agent selecting among many sibling block 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 readOnly, idempotent, non-destructive and open-world behavior, so the description is not burdened with safety disclosure. It adds genuinely useful behavioral detail beyond annotations: a hard cap of 15 blocks, backward traversal, and that only published blocks among the 15 heights are returned so results are fewer or empty past the tip. It does not discuss ordering of the returned blocks or pagination, but the output schema likely covers structure.

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

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

The core behavior is front-loaded in one dense sentence, followed by a docs reference and REST operation mapping. No sentence is wasted and the boundary condition is included without bloat.

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 annotations covering safety and an output schema covering return structure, the description supplies the essential calling semantics: direction, cap, and tip behavior. The notable omission is sibling differentiation, which leaves a gap in a very crowded block-related namespace.

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 height parameter is documented in the schema, yet the description adds crucial meaning: height is the ending/top height of the range, not the starting point, and traversal goes backwards. That resolves the main ambiguity an agent could have when passing the 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?

States a specific verb and resource with scope: retrieve up to 15 blocks with extended data going backwards from a given height. The 15-block cap and backwards direction are clear. However, it never distinguishes itself from near-identical siblings such as get_blocks_v1 and get_blocks_from_height, which an agent must disambiguate by schema inspection alone.

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 explicit when-to-use or when-not-to-use guidance and no alternative is named. The scope sentence implies the tool is for height-anchored backward listings, but with dozens of block-related siblings, implied usage is insufficient for reliable 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, idempotentHint, openWorldHint and destructiveHint=false, and an output schema exists, so the safety profile is covered. The description adds no behavioral context of its own — no note on network scope, freshness/latency of the tip, or failure modes — beyond pointing at external docs.

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?

It is very short with no filler, but it is structured as a docs link followed by a raw REST path rather than as a front-loaded statement of what the agent gets back. The first line is a bare URL that conveys nothing on its own.

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 read with an output schema, the minimum needed to invoke it is present. Still, the description never says in words that the return value is the tip block hash, nor distinguishes it from the sibling height tool, leaving the agent to lean entirely on the name and external documentation.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to explain. The empty schema is consistent with the described parameterless GET endpoint.

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 only restates the tool name as a REST path ('GET /api/blocks/tip/hash'), which an agent can decode to mean 'the hash of the current chain tip'. That is enough to grasp the resource, but it offers no plain-language statement and no differentiation from close siblings like get_block_tip_height or get_block_hash_by_height.

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 guidance on when to call this versus get_block_tip_height, get_block_hash_by_height, or get_block. The agent must infer usage purely from the name and URL path, with no exclusions or alternative 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond a documentation URL — no note on rate limits, freshness/latency of the tip value, or that the result is a scalar rather than a block object.

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 lines with no filler; the doc link and endpoint are front-loaded. It is efficient, though the link precedes any plain-language statement of purpose, which is slightly backwards for an agent skimming.

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 needn't be explained, and with zero parameters and rich annotations the bar is low. Still, a one-clause note clarifying that this returns the latest block height (a plain integer) would close the only real 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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description neither adds nor obscures parameter 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 gives the exact REST endpoint (GET /api/blocks/tip/height), which pins down the resource precisely, but it never states in words what the call returns (the height of the chain tip). Combined with the name it is decipherable, yet it leans on the name rather than explaining the purpose, and it does not distinguish itself from neighbors like get_block_tip_hash or get_blocks.

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 guidance on when to call this instead of get_block_tip_hash, get_blocks, or get_block_by_timestamp. The doc link is the only hint at context, and the agent must infer the use case entirely from the name.

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, openWorldHint and destructiveHint=false, so the safety profile is handled. The description adds only that the result is plain-text txid rather than JSON, which is mildly useful context but the output schema already covers the return shape.

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

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

Front-loaded with the action, then the return type, then a docs link and the REST path. Efficient, though the 'REST operation' line is largely redundant with the tool's 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?

For a two-parameter read tool with full annotations and an output schema, the description supplies everything needed to call it correctly. Nothing essential about errors, out-of-range indices, or block-not-found behavior is stated, but that is a minor 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?

Both parameters are documented in the schema via $refs (BlockHash explains double-SHA256 byte order; BlockTxIndex explains 0-based position and that 0 is the coinbase), and the description adds no syntax, format, or range detail beyond that. With the schema doing the heavy lifting, 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?

States a specific verb and resource (retrieve a single transaction ID) plus the scoping constraint 'within a block' and the index position, which distinguishes it from chain-wide index lookups like get_txid_by_index. It does not explicitly name any sibling, so it stops just short of 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?

Usage is only implied: the description tells you what it returns, from which you infer you need a block hash and index. There is no statement of when to prefer it over get_block_txs_from_index or get_txid_by_index, and no prerequisites or alternatives 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 readOnly/idempotent/non-destructive, so the description's job is to add the operational constraint it does: page size capped at 25 and `start_index` must be a multiple of 25. That is a real behavioral rule not present in the schema. It omits error behavior for non-multiple indices and rate limits, so not a 5.

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?

One front-loaded sentence carries the page size and the index constraint; the docs link and REST operation line are reference metadata that aid traceability without bloating. Slightly more than strictly necessary but nothing wasteful.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile; the description supplies the paging contract that is the main failure mode. Missing only error semantics for invalid `start_index` values and any rate-limit notes.

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 only 50%, and the description fills a genuine gap by adding the 'multiple of 25' requirement for `start_index`, which the schema only constrains to minimum 0. It adds nothing about `hash` beyond the schema's existing $defs 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?

States a specific verb and resource ('transactions' for a block, paginated from `start_index`) and the page size, so the agent knows exactly what is returned. It does not name a sibling such as `get_block_txid` to sharpen the contrast, which keeps it below 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?

No explicit when-to-use or when-not-to-use text; the agent must infer that this is the paginated enumeration path while `get_block_txid` fetches one transaction at an index. The 'multiple of 25' rule implies the paging pattern but is a constraint, not guidance about 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 read-only, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds the REST endpoint and docs reference, but leaves “extras” unexplained and gives no behavioral detail about rate limits or response shape.

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

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

The description is short, front-loaded with the core purpose, and contains no filler. The docs link and REST operation are compact and useful.

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?

An output schema exists, so return values need not be documented, and annotations cover safety. However, the description does not clarify what “extras” includes or how this tool differs from closely related block tools, leaving meaningful ambiguity for an agent choosing among siblings.

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

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

The description only says “by hash,” which identifies the parameter name but adds little semantic meaning. The context signal reports 0% schema description coverage, so the description should compensate by explaining the expected hash format, but it does not.

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: returns block details for a given hash. It is more specific than a tautology, but it does not explain what “extras” means or distinguish this tool from the sibling get_block / get_blocks_v1 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?

It provides no guidance on when to use this tool instead of get_block, get_block_header, get_block_status, or the other block-related siblings. The docs link and REST path identify the operation but do not tell an agent when this variant is appropriate.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine behavioral context beyond them: results are state-dependent on whether the transaction is in the mempool or confirmed in a block, and an unknown or orphaned transaction yields `{"ancestors":[]}` rather than an error. It omits things like whether the empty-package case is distinguishable from a malformed txid, but this is solid added value over 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?

Purpose is front-loaded in the first clause, the three state cases are compressed into one dense sentence each, and the docs link plus REST operation trail at the end where they belong. Nothing is padded.

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 handling return values and annotations handling the safety profile, the description only needs to carry the semantics of the result set, which it does via the mempool/confirmed/unknown cases. For a single-parameter read tool this is sufficient for correct invocation and interpretation.

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 reported as 0%, but the shared Txid definition carries a description plus a hex pattern and three examples, so the format is well documented structurally. The prose adds nothing about the txid beyond what the schema shows; the only semantic hint is the implicit point that the same txid returns different packages depending on its confirmation state.

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 names a specific resource (the CPFP package for a transaction) and a specific payload (ancestors, descendants, and effective package fee rate), which is far more precise than the bare name 'get_cpfp'. It does not explicitly route the agent away from the topically adjacent siblings (get_tx, get_tx_outspends, get_fullrbf_replacements), so it falls short of full sibling differentiation.

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 only implied: the state-by-state explanation (mempool, confirmed, unknown) tells the agent what it will get for a given txid but never states when to prefer this tool over get_tx or get_fullrbf_replacements. There are no explicit when-not conditions or prerequisites.

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, openWorldHint and destructiveHint=false, so safety is fully covered. The description adds only the 'current' framing (latest snapshot rather than historical series), which is modest extra value; it does not mention freshness/latency or that it hits a live upstream API despite openWorldHint.

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 lines, with the purpose front-loaded. The docs link and REST operation mapping are compact and useful for disambiguation rather than filler.

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

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

With no parameters, a rich annotation set, and an output schema present, the description need not explain return values. The only missing piece is the sibling differentiation that would let an agent pick correctly among the three difficulty-adjustment tools.

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 takes zero parameters and the schema is empty with additionalProperties=false, so there is nothing for the description to document. Baseline 4 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?

States a specific verb and resource ('Get current difficulty adjustment progress and estimates'), which is clearer than the title alone. However, it never distinguishes itself from the near-identical siblings get_difficulty_adjustments and get_difficulty_adjustments_by_period, so an agent cannot tell from the text which one returns the current epoch snapshot vs. 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?

No when-to-use guidance, no exclusions, and no reference to the two obvious alternatives despite their names being nearly identical. The word 'current' hints at a selection condition but the agent must infer 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered without prose. The description adds nothing beyond a link to external docs — no note on result volume, ordering, or whether the series is capped/paginated, which matters for an all-time list endpoint.

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 lines with no padding, and the docs link is placed first. It is efficient but nearly content-free — terseness here comes at the cost of information rather than as deliberate prioritization.

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 zero params, a rich annotation set, and an output schema, the description needs only to state scope and differentiation — and it only half does that, via the title. An external link to mempool.space docs is a weak substitute for in-band explanation of what 'all time' 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for this dimension is 4. The description correctly implies no filtering input is accepted.

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 body only restates the REST route (`GET /api/v1/mining/difficulty-adjustments`), leaving the resource meaning to the name and title. The distinguishing scope detail — 'all time' — appears in the title rather than the description, and the description never says it returns the full history of difficulty retargets as opposed to a single adjustment.

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 versus `get_difficulty_adjustment` or `get_difficulty_adjustments_by_period`, despite those siblings being directly adjacent in function. An agent must infer from the title that this is the unfiltered/all-time variant.

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 a read-only, idempotent, non-destructive, open-world operation. The description adds the REST endpoint path and documentation link, which is useful but not substantial behavioral context beyond the annotations.

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

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

The description is short and front-loaded: purpose first, then documentation link and REST operation. 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?

With a fully documented single parameter, complete annotations, and an output schema, the description is sufficient for correct invocation. The main omission is why this tool exists alongside the two similarly named difficulty-adjustment siblings.

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

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

The single time_period parameter is fully documented in the schema, including all enum values. The description only restates 'time period' without adding format, default, or edge-case details 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 states a clear verb and resource: get historical difficulty adjustments for a time period. However, it does not distinguish this tool from the closely named siblings get_difficulty_adjustment and get_difficulty_adjustments.

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 on when to use this tool instead of the singular or plural sibling tools. There are no exclusions, prerequisites, or alternative-selection hints.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the filtering criterion and response-shape note, but does not mention auth, rate limits, or pagination.

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 single sentence plus a docs link and REST operation. No redundant explanation and every sentence contributes 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?

With an output schema and rich annotations, the description supplies enough to select and invoke correctly. The only minor gap is an explicit alternative-tool pointer for the non-full-RBF case.

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?

Zero parameters, so baseline is 4. The description does not need parameter details and correctly omits them.

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 a concrete resource and precise filter: replacement trees where at least one predecessor was non-signaling (full-RBF). It distinguishes this from the broader replacement endpoint by naming the REST endpoint it mirrors and the limitation.

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 'but limited to' clause implies when to choose this over the all-replacements endpoint. However, it does not explicitly name the MCP sibling or state when not to use it, leaving a small gap.

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, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds only a docs link and the underlying REST path — nothing about cadence, history span, or approximate response size for an all-time series, which is the main behavioral risk here.

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 the purpose in one sentence, followed by a reference link and the REST operation. The docs link and REST path are supporting metadata rather than wasted prose, though they are not strictly needed for invocation.

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 zero parameters and an output schema present, the description need not explain return values. The only remaining gap is the granularity and total history span of the 'all time' series, which would help an agent judge payload size.

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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The schema's empty properties object is consistent with the description's framing as a fixed-endpoint read.

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 (get) and resource (network hashrate and difficulty data), and the phrase 'for all time' implicitly distinguishes it from the period-scoped variant. It does not explicitly name get_hashrate_by_period, so sibling separation is implied rather than stated.

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 'all time' qualifier hints at when this is appropriate versus get_hashrate_by_period, but no explicit when-to-use or when-not-to-use guidance is given. An agent must infer the routing rule from the tool name and the phrase.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that both hashrate and difficulty series are returned and that it maps to a documented REST endpoint, but says nothing about result granularity, units, or response shape beyond that.

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?

One sentence stating what is returned, front-loaded, followed by a docs link and REST operation mapping that help an agent ground the call. No filler, though the REST line is arguably metadata rather than guidance.

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?

An output schema exists, so return values needn't be described, and the sole parameter is fully documented in the schema. What's missing is enough context to place this tool among its many hashrate/difficulty siblings, which is the main gap for correct selection.

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 single time_period parameter already enumerates all valid windows with examples, so the baseline of 3 applies. The phrase 'for a time period' restates the parameter without adding semantics such as default window or resolution of returned data points.

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 plus the scope ('network hashrate and difficulty data for a time period'), which is clearer than most siblings. However, it never distinguishes itself from near-neighbors like get_hashrate, get_difficulty_adjustments_by_period, or get_pools_hashrate_by_period, so an agent must guess which of these overlapping tools to pick.

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 when-to-use or when-not-to-use guidance and never names an alternative. With at least three sibling tools covering hashrate/difficulty over periods, the choice is left entirely 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?

Adds real behavior beyond the readOnly/idempotent annotations: ordering (newest first), labeling convention (interval end), exclusion of the current partial interval, empty-list edge case, and that exchangeRates comes back empty. These are exactly the non-obvious traits an agent would otherwise have to discover by trial.

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 the core resource and ordering, then edge cases, then docs link and REST operation. Dense and mostly waste-free, though the opening sentence packs several clauses and the repeated 'USD only' point sits slightly awkwardly after the empty-list caveat.

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

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

With an output schema present, the description need not explain return shape, and it covers everything else an agent needs: scope, ordering, timestamp resolution, boundary behavior, and the currency limitation. No material gaps for a two-param read.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a step above by spelling out the timestamp semantics on boundary cases (nonempty completed close at or before it, empty list before inception) and restating the USD-only constraint beyond the 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?

States a specific verb+resource with granularity: 'Completed four-hour BTC/USD closes ... labeled by interval end, from the first priced interval (2010-08-16).' An agent can tell this is the historical 4h close series rather than a spot quote, though the nearest sibling (get_prices) is never named to make the split explicit.

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?

Gives concrete selection conditions: with no timestamp it lists all closes newest-first, with a UNIX timestamp it returns the latest close at or before it, and before the first close it returns an empty list. It does not name or exclude the sibling price/series tools, so routing is inferred 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that – no snapshot-vs-live semantics, no caching/freshness behavior, no cost or rate context for an open-world endpoint. No contradiction, but zero added value.

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?

It is short and free of padding, but the space it uses is spent on a URL and a route string rather than on the purpose sentence that should lead. Front-loading is weak: the first element is a doc link, not a statement of what the tool returns.

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?

An output schema exists, so return values need not be described, and there are no parameters to document. Still, in a 70-plus-sibling server with several mempool-scoped tools, an agent cannot tell from this text whether the call returns aggregate mempool stats or a recent-transaction list; the definition leans entirely on the external doc link.

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 takes no parameters, so the baseline is 4. The description neither helps nor hurts here; there is simply nothing to disambiguate.

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 only restates the name as a REST route ('GET /api/mempool') plus a docs link, without saying what a mempool statistic is or what the payload covers (fees, backlog, counts). It gives no basis for distinguishing this from close siblings such as get_mempool_recent or get_mempool_blocks.

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 when-to-use guidance, no exclusions, and no mention of the near-identical siblings ('get_mempool_recent', 'get_mempool_blocks') that an agent must choose between. The only signal is a link, which is not usable guidance in-context.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses that only block 0 is a real projection while blocks 1+ are a fee-tier approximation, warning the agent about data fidelity.

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 tight sentences front-load the purpose and the important block-0 caveat. The trailing docs link and 'REST operation: GET /api/v1/fees/mempool-blocks' are brief but boilerplate that adds little for an agent already given the tool 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?

An output schema exists, so return-value structure needn't be spelled out, and the description still conveys the meaning of block 0 versus later blocks. Combined with a zero-parameter, annotated, read-only operation, this is nearly complete; only explicit sibling routing 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?

The tool takes zero parameters, so the baseline is 4. Nothing in the schema needs explanation, and the description correctly does not invent parameter guidance.

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 resource ('Projected blocks') and its purpose ('for fee estimation'), plus the key structural distinction that block 0 is Core's actual next-block selection while blocks 1+ are approximations. It doesn't name which sibling to use instead (e.g., get_precise_fees or get_block_fee_rates), so sibling differentiation is implicit rather than explicit.

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?

'For fee estimation' implies the use case, and the block-0-vs-1+ note hints at when the data is authoritative versus approximate. However, there is no explicit statement of when to prefer this over the many sibling fee/block tools (get_precise_fees, get_block_fee_rates, get_mempool), leaving the agent to infer.

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, openWorldHint, and non-destructive behavior. The description adds the useful behavioral limit ('last 10') and names the REST endpoint, but does not discuss freshness, ordering, rate limits, or return format. With annotations covering safety, a 3 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 scope is front-loaded in the first sentence, followed by a docs link and REST operation. Every element earns its place and there is no padding.

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 read-only tool with an output schema and rich annotations, the description supplies everything needed to invoke it correctly: exactly what is returned and the underlying endpoint. No missing call-critical context.

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

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

The tool has zero parameters, so there are no parameter semantics to explain; baseline 4 applies. The description correctly does not invent parameter 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?

States a specific verb ('Get'), resource ('transactions to enter the mempool'), and hard scope ('last 10'). This distinguishes it from sibling tools like get_mempool (mempool state) and get_address_mempool_txs (address-scoped mempool transactions).

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

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

The description says what it returns but never states when to use it versus alternatives such as get_mempool or get_address_mempool_txs. No exclusions or prerequisite context are provided.

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

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

The annotations already establish that this is a safe, read-only, idempotent, open-world operation. The description adds useful context about the returned metrics and the underlying REST path, but does not disclose pagination, time-period controls, or output behavior beyond what annotations and the output schema provide.

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

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

The description is short, front-loaded with the core behavior, and includes the docs link and REST operation 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 single-parameter read-only endpoint with an output schema, the description is mostly complete: it states what metrics the tool returns and maps to the REST operation. Minor gaps remain around how the time period is determined, but the output schema likely covers the response shape.

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

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

There is only one parameter, slug, and the schema enumerates all valid pool identifiers with a description. The description only indirectly references it via the REST path template '{slug}' and adds no additional guidance on selecting a pool slug.

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 identifies the resource (one mining pool) and the metrics returned (block counts and mining shares by time period). This distinguishes it reasonably well from siblings like get_pool_blocks and get_pool_hashrate, though it does not use a direct verb-resource phrasing.

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 phrase 'for one pool' implies this is the single-pool aggregate-stats endpoint, distinguishing it from list-oriented siblings such as get_pools. However, there is no explicit guidance on when to use this tool versus get_pool_blocks, get_pool_hashrate, or get_pool_ranking.

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, idempotent, openWorld and non-destructive, so safety is covered. The description adds one genuinely useful behavioral fact -- results are capped at 100 blocks -- but says nothing about ordering, whether the cap is silent truncation, or how an unknown slug behaves.

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?

One precise sentence front-loads the purpose and scope, followed by a short docs link and REST path. The citation lines are boilerplate but compact; nothing is padded.

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 full annotations and an output schema, the description need only cover selection and scope, and it does both for a single-parameter list tool. Minor gaps (ordering of the 100 blocks, truncation behavior) are secondary given the output schema defines the return shape.

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

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

Only one required parameter exists and the schema's enum enumerates every valid slug, so the parameter is largely self-documenting even though stated coverage is 0%. The description's phrase "a specific pool" restates the obvious rather than explaining slug format or what happens for pool slugs not in the 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?

States a specific verb and resource ("Get ... blocks mined by a specific pool") and adds a concrete scope limit of 100 results, so an agent knows exactly what it retrieves. It does not explicitly name the sibling get_pool_blocks_from_height to differentiate itself, which keeps it from 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?

No when-to-use or when-not-to-use guidance is provided; the selection logic against siblings like get_pool_blocks_from_height or get_pool must be inferred from the word "recent" and the 100-block cap. The docs link and REST operation line supply no usage context.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real behavioral facts: a hard cap of 100 results, strict exclusivity of the height boundary, and the pagination contract — none of which are in 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?

One front-loaded sentence covering result cap, filter, and pagination, followed by a doc link and the REST operation. Every element is load-bearing; nothing is padded.

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?

Output schema exists, so return values need not be explained, and the cap, exclusivity, and pagination are all covered. The only gap is guidance on choosing this tool versus get_pool_blocks, which is left implicit.

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 reported at 0%, though the $defs do carry brief descriptions and a full pool enum. The description adds meaningful semantics for height ('strictly below', page cursor usage) but says nothing about slug beyond 'a specific pool', leaving the enum to speak for itself.

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 ('Get up to 100 blocks mined by a specific pool') plus the scoping constraint ('strictly below the given height'), which clearly separates it from the parent-range siblings get_pool_blocks and get_blocks_from_height.

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?

Gives concrete usage context for pagination ('pass the last height of a page to get the next one'), which tells the agent how to iterate. It does not explicitly exclude or name alternatives like get_pool_blocks, so it falls short of a full when/when-not statement.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the upstream REST endpoint and a docs link, which aids interpretation, but says nothing about time granularity, default range, or coverage of the returned history.

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 purpose sentence is front-loaded and the docs link plus endpoint line are compact and useful reference material. Slight overhead from formatting, but nothing extraneous.

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?

An output schema exists and annotations cover the safety profile, so the burden is lighter. Still, the existence of get_hashrate_by_period and get_pools_hashrate_by_period siblings means the description should clarify whether this returns full history at a default resolution or supports period selection.

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% at the property level; the only documentation is the $defs description of PoolSlug. The description compensates slightly by tying the slug to "a specific mining pool," but adds no examples, format rules, or note that invalid slugs fail.

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?

"Get hashrate history for a specific mining pool" gives a specific verb, resource, and scope (single pool), which implicitly separates it from the network-wide get_hashrate and the multi-pool get_pools_hashrate. It never names those siblings explicitly, so an agent must infer the distinction from the word "specific."

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 only implied by the phrase "for a specific mining pool." There is no explicit guidance on when to prefer this over get_pools_hashrate, get_hashrate_by_period, or get_pools_hashrate_by_period, which are the most plausible alternatives given the sibling list.

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, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds useful provenance (the REST operation GET /api/v1/mining/pools/{time_period} and a docs link) but says nothing about what the statistics contain, how they are ordered, or units of measurement.

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 sentences with the purpose front-loaded, followed by the docs link and REST mapping. Slightly more boilerplate than needed, but nothing is padded.

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

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

For a single-parameter, read-only tool with an output schema available, the description covers purpose and provenance adequately. The remaining gap is that an agent cannot tell from the description how this ranking differs from the other pool endpoints.

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 enum values are fully documented in the schema, so the baseline of 3 applies. The description itself never mentions time_period's accepted values or default behavior, adding nothing 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?

States a specific verb and resource ("Get mining pool statistics for a time period"), which is clear on its own. However, it gives no signal distinguishing it from the many pool-related siblings such as get_pools, get_pools_hashrate, or get_pools_hashrate_by_period, and it never says that the result is a *ranking* of pools as the tool name implies.

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 guidance on when to choose this over get_pools or get_pools_hashrate_by_period, and no exclusions or prerequisites. Usage is only inferable from the single required time_period parameter.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing behavioral — no mention of aggregation window, caching, rate limits, or whether the pool list is historical vs current — so it contributes essentially no value beyond structured fields.

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 lines with no filler and the docs link is front-loaded, which is good. However, the body is so thin that 'concise' tips into 'under-specified' — the REST path line largely restates the name and occupies space that could have gone to a one-line purpose statement.

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 parameters, a full annotation set, and an output schema, the structural burden is low, so the minimal description is almost sufficient. It still omits what the response covers (e.g., whether the pool list spans all time or a specific window) and how it relates to the several sibling pool endpoints, leaving a real gap for an open-world data 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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is reported at 100% and the empty object schema is self-explanatory.

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 itself only supplies a docs link and the raw REST path `GET /api/v1/mining/pools`; the actual 'list mining pools' intent comes from the title rather than the prose. An agent can infer the resource but gets no explicit statement of what a pool record contains or how it differs from siblings like get_pool, get_pool_ranking, or get_pools_hashrate.

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 when-to-use guidance, no alternatives named, and no prerequisites stated. The only external pointer is a docs URL, which forces the agent to leave the tool definition to decide whether this or get_pool_ranking / get_pools_hashrate is the right 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds ordering behavior ('by time and then their weekly rank') and the last-week scope, which is modest but real added 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 core purpose and ordering are front-loaded in the first sentence; the docs link and REST operation are short trailing metadata. Slight awkwardness in 'by time and then their weekly rank' but nothing wasteful.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, the mismatch between the title ('all time') and the body ('last week') leaves ambiguity about the actual time window that the description should have resolved.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and consistent with the description.

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

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

The description states a specific verb and resource ('Get weekly hashrate data ... of the mining pools') along with scope ('whole chain', 'mined in the last week'). It does not, however, distinguish itself from close siblings like get_pools_hashrate_by_period or get_pool_hashrate, and the title's '(all time)' conflicts with the 'last week' wording.

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 explicit when-to-use guidance and no mention of alternatives such as get_pool_hashrate (single pool) or get_pools_hashrate_by_period. The agent must infer applicability from the word 'weekly' 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 this as a safe, idempotent, read-only open-world operation, so the description does not need to cover those traits. It adds useful behavioral context by saying the data is for pools that mined in the last week and is ordered by time and then weekly rank. It does not cover return format, but an output schema 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 is front-loaded with the core purpose and includes the REST endpoint and docs link without excessive boilerplate. It is somewhat awkwardly phrased around weekly data and weekly rank, but it remains appropriately compact.

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

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

Given the rich annotations, full schema coverage, and an output schema, the description provides enough context for a simple read-only endpoint. The main remaining gap is sibling differentiation, which is more of a usage-guideline issue than missing core 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?

Schema description coverage is 100%, and the single time_period parameter is fully documented in the schema with its enum and examples. The description only refers generically to a time period, so it adds little semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific resource and operation: hashrate data for mining pools, scoped by a time period, ordered by time and weekly rank. It is clear enough to identify the tool, but it does not distinguish this from close siblings such as get_pools_hashrate, get_pool_hashrate, or get_pool_ranking.

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

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

The description gives no explicit when-to-use guidance and does not name any alternative tool. With many closely named sibling tools available, an agent receives no routing help about when this by-period variant should be chosen over the others.

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, idempotent, non-destructive and openWorld, so the safety profile is covered. The description still adds genuinely useful behavior beyond that: output precision (three decimals) and support for sub-sat/vB rates, which materially affects how an agent interprets the returned numbers.

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?

Purpose is front-loaded in the first clause, followed by the distinguishing precision detail. The docs link and REST operation line are compact and aid upstream mapping, though the markdown link is mild boilerplate.

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 parameters, an output schema covering return values, and rich annotations, the description only needs to add units and precision, which it does. A brief note on whether the recommendation is a live mempool estimate or a snapshot would close the remaining 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?

Zero parameters, so the baseline of 4 applies. The phrase 'by confirmation target' usefully signals the shape of the response (rates keyed per target), which is the only semantic an agent needs here.

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 resource and qualifier (recommended fee rates by confirmation target, with up to three decimal places and sub-sat/vB support), which is far more than a restatement of the name. It stops short of distinguishing this from the adjacent get_block_fee_rates and get_block_fee_rates_precise siblings, so an agent still has to infer why to pick this 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?

Usage is only implied: 'recommended fee rates by confirmation target' hints at the fee-selection use case, but there is no explicit when-to-use, no named alternative, and no statement of when the non-precise or block-based fee endpoints would be preferred.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the price is on-chain derived rather than an exchange feed, and only USD is supported, which materially affects interpretation of the result.

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?

Lead sentence front-loads what matters (what it returns, how it is derived, currency limit). The docs link and the REST operation line are mildly redundant but act as grounding metadata; nothing is padded.

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 zero inputs, a present output schema, and full annotation coverage, the description only needs to convey meaning and constraints, which it does. Only the missing routing versus get_historical_price keeps it from a 5.

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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly does not invent parameter discussion and instead spends its words on output meaning and constraints.

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 ('Returns bitcoin latest price') plus a meaningful qualifier ('on-chain derived, USD only'). The word 'latest' implicitly separates it from the sibling get_historical_price, so an agent can distinguish it 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?

Usage is only implied by the word 'latest' and the USD/on-chain constraint; there is no explicit statement of when to prefer this over get_historical_price. The agent can infer the split, but the description never names the alternative or sets the condition.

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, openWorldHint=true, and destructiveHint=false. The description adds useful behavior beyond annotations: a cap of 25, most-recent ordering, and a pointer to the entry shape, though it does not describe empty/error 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 and front-loaded with scope, cap, and recency. The docs link and REST operation reference are useful context rather than filler.

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

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

With an output schema, full annotation coverage, and zero parameters, the description supplies the remaining essentials: the 25-item cap, recency, global mempool scope, and return-entry shape. Nothing critical for calling it correctly 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?

The tool has zero parameters, so the baseline of 4 applies. The description correctly does not invent parameter details because 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?

States a specific verb and resource: returns recent RBF replacement trees, with a clear scope of across the whole mempool. It does not explicitly name or differentiate from sibling tools such as get_tx_rbf or get_fullrbf_replacements, so it is clear but not fully sibling-differentiated.

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 no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer from 'across the whole mempool' that this is the global recent-list endpoint rather than a per-transaction RBF view.

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, idempotent, non-destructive, so safety needs no restating. The description adds genuine context beyond them: the result is an aggregate over a rolling window of recent blocks and covers three specific metric families. Missing only practical behavior such as cost/pagination or a max block_count.

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 sentence is front-loaded and covers purpose plus returned fields in one line. The trailing docs link and REST operation line are supplementary rather than wasteful, though the raw endpoint string adds little for an agent already holding this 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?

Given an output schema (return values need no explanation), rich annotations, and a fully documented single parameter, the description covers what is needed to call it correctly. The only gap is the absence of any note on valid ranges or expected call cost for large block_count values.

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 has full schema coverage with a description, a minimum, and an example. The description's 'last N blocks' merely restates what the schema already says about block_count, adding no format or boundary detail. Baseline 3 applies when the schema carries the parameter burden.

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 (get mining reward statistics) and enumerates the returned metrics (total rewards, fees, transaction count) over the last N blocks. The 'last N blocks' aggregation scope implicitly separates it from per-block siblings like get_block_rewards, but it never names an alternative explicitly.

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

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

Usage is only implied: the phrase 'for the last N blocks' signals this is an aggregate window query rather than a single-block lookup. There is no explicit guidance on when to prefer this over get_block_rewards or get_block_fees, and no stated limits on block_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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only that output can be JSON or CSV, which merely echoes the format enum in the schema; it says nothing about volume, pagination, or the cost of wide ranges.

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 sentences plus a route line, with the ranged-row behavior front-loaded and zero filler. The REST operation line is useful for agents mapping to the underlying API.

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?

Six parameters, half of them undocumented in the schema, an output schema present, and a crowded set of get_series_* siblings — yet the description explains neither the series/index semantics nor why this variant should be chosen. It is too thin for the surface area.

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%, but the description does real work by explaining that the range can be expressed as positions, dates, or timestamps, which is exactly the anyOf meaning of start/end. It stops short of covering series name, index aggregation, or how limit interacts with end.

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 says it returns "Rows selected by a range of positions, dates or timestamps, as JSON or CSV," which conveys a ranged-read of series data, and the REST route GET /api/series/{series}/{index} pins the resource. However, it never says what a "series" value actually is, and it draws no distinction from close siblings like get_series_bulk, get_series_latest, or get_series_len.

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 when-to-use guidance at all — no statement about choosing a bounded range versus the bulk, latest, or count variants that sit right next to it in the tool list. The agent must infer selection from the 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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the return shape ('array of SeriesData objects') and the underlying REST operation, which is useful context beyond the annotations, though it doesn't mention pagination or error 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 tight sentences plus the REST line; the core purpose and the sibling routing are front-loaded with no wasted 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 an output schema present, return values needn't be explained, and the description correctly signals the array-of-SeriesData result. The remaining gap is parameter-level guidance for the series list and limit interplay, which the 50% schema coverage doesn't fully cover.

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 only 50%, so the description needs to compensate. It gestures at 'filtering by index and date range' (start/end/index) but says nothing about the comma-separated `series` list format, its 32-name/2048-byte budget, `limit`, or `format` — all left to the schema. Adequate but leaves a gap at this coverage level.

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 multiple series in a single request') and explicitly contrasts with the sibling get_series for single-series use. An agent can distinguish this bulk variant from get_series without opening either 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?

Explicitly routes single-series callers to `get_series` instead, which is a concrete alternative. It doesn't spell out other exclusion conditions (e.g., when to prefer get_series_latest or search_series), but the primary branching decision is 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 that the tool is read-only, idempotent, open-world, and non-destructive. The description adds useful context about what is returned, but it does not describe authentication, rate limits, or other behavioral traits beyond the annotations.

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

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

The description is two short sentences and front-loads the actual behavior. There is no wasted wording, and the REST endpoint is supplementary but compact.

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

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

For a no-parameter, read-only count endpoint with annotations and an output schema, the description is mostly complete. It could better clarify how this count relates to nearby series-listing or length tools, but no critical calling 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?

The tool has zero parameters, so there is no parameter semantics burden in the description. The empty input schema makes the baseline score 4 appropriate.

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

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

The description states a specific verb and resource: it returns the number of series available per index type. It is clear what the tool does, though it does not explicitly differentiate itself from nearby siblings such as list_series, search_series, or get_series_len.

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. The REST operation line is implementation detail, not usage guidance, and it does not explain when a count is preferable to listing or searching series.

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, idempotent, non-destructive, so safety is covered. The description adds real behavioral detail beyond them: which returned fields are optional (description and unit may be absent) and that the decoded series name is capped at 1024 UTF-8 bytes, which matters for how the call can be made.

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?

One dense sentence front-loads the useful content (what is returned) before the constraint and REST path. The REST operation line is minor filler but non-redundant; nothing is repeated from schema or annotations.

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

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

With an output schema present, the description needn't detail return shape, yet it usefully previews the fields and flags which are optional. Annotations cover the safety profile. For a single-parameter read tool this is essentially complete, short of guidance on behavior for unknown series names.

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 schema itself carries pattern (^[a-z0-9_]+$) and examples, so the naming format is discoverable. The description compensates partially with the 1024-byte decoded-name limit, but adds nothing about resolution behavior when a series does not 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?

States a specific verb ('Returns') and enumerates exactly what metadata comes back for a series: description, indexes, nullable indexes, value type, unit. This is clearly distinct from value-fetching siblings like get_series or get_series_latest, though the description never names those siblings to make the distinction explicit.

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 explicit when-to-use guidance or exclusion versus get_series, get_series_latest, list_series, or search_series. The scope ('for the specified series') implicitly signals this is a per-series metadata lookup, but the agent must infer the choice from the return fields listed.

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