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.