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

Annotations cover the safety profile (destructiveHint=false, idempotentHint=true), and the description adds genuinely useful context not in the structured data: the chain (eip155:1), the exact per-call cost (0.005000 test USDC on eip155:84532), and the retry/idempotency-key handling. This explains why readOnlyHint is false despite the 'Read' verb, resolving an apparent tension rather than contradicting 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?

Three short, front-loaded sentences with no filler. The core identity comes first, then cost, then retry handling, which is a sensible ordering for an agent to scan.

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?

Payment, chain, and idempotency handling are covered, and no output schema means return values need not be explained. But the positional params (hash and boolean) are left opaque and no sibling routing to getBlockByNumber is provided, leaving a real gap for an eth_getBlockByHash call.

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

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

Schema coverage is 50%; the idempotencyKey has a full schema description and the description reinforces its retry/persistence semantics. However, the required params array (a block hash plus a boolean, presumably full-transactions) is completely undocumented in both schema and description, so an agent gets no help on the two positional arguments it must supply.

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?

"Read eth_getBlockByHash" essentially restates the tool name rather than explaining what the operation does or returns. It never states that it fetches block data keyed by a block hash, nor distinguishes itself from the sibling ethereum_eth_getBlockByNumber, which is the immediately competing choice.

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

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

The only actionable guidance is 'Preserve the private idempotencyKey for retries,' which is a narrow retry instruction. There is no indication of when to use this tool versus getBlockByNumber or any other block-reading sibling, and no prerequisites beyond the cost note.

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