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

Annotations already declare openWorld=true and idempotent=true, but the description adds real operational context the annotations lack: an explicit monetary cost (0.005 test USDC on eip155:84532) and the retry discipline for the idempotencyKey. This meaningfully helps an agent understand the paid, retry-safe nature of the call. It stops short of describing return contents or failure modes.

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 resource and chain lead, followed by cost and retry guidance. Slightly terse given how much semantic payload is left out, but nothing is wasted.

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?

It covers cost, network, and idempotency, which are the non-obvious parts. But with no output schema and an undescribed params argument, an agent still lacks the semantics of what it must pass and what feeHistory will return, leaving a moderate completeness gap.

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

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

Schema coverage is only 50%: idempotencyKey is well documented in the schema, and the description's 'preserve for retries' line merely restates that. Meanwhile the required params argument — which encodes block count, newest-block tag/hex, and reward percentiles — is undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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

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

States a concrete verb+resource ('Read eth_feeHistory') and pins the network (eip155:1), so the target chain is unambiguous. However, it only echoes the RPC method name and never explains what fee history returns, nor differentiates it from sibling gas-related methods like eth_gasPrice or eth_maxPriorityFeePerGas.

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 and no exclusion against the many similarly-scoped eth_* siblings. The only routing-ish content is the cost note, which does not help an agent decide between this and eth_gasPrice/eth_blobBaseFee.

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