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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=false; the description adds genuinely non-obvious context the annotations cannot: per-call pricing ($0.002 via x402 USDC or card key), the first 25 calls free, failed calls free, and why repeats are not free. That last point explains the idempotentHint=false flag rather than merely restating it. It stops short of describing response shape or latency, which keeps it at 4.

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 purpose and return values, then usage, then commercial terms; nothing is truly wasted since the billing note affects repeat-call behavior. The second half is a dense run-on packing ingestion method, free tier, failure policy and refund semantics into one clausal chain, which costs some scanability.

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?

No output schema exists, so the description carries the return burden itself and does so fully (gas price, base fee, priority fee, transfer cost, in gwei). For a zero-argument, read-only oracle call the definition supplies everything needed to invoke and interpret 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?

The description says 'Takes no input,' but the schema defines an optional `only` parameter for trimming top-level result keys; that phrasing is mildly misleading and the description never explains the filtering behavior. Schema description coverage is 100%, so the agent can still recover the meaning from the schema, holding this at the baseline 3 rather than lower.

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 ('Current gas price on Ethereum'), lists the exact values returned (gas price, base fee, suggested priority fee in gwei, cost of a 21,000-gas transfer), and differentiates itself from eth_receipt, the sibling for historical fees. An agent can identify this among the ~200 network-prefixed siblings 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?

Gives an explicit when-to-use ('before sending a transaction or to decide whether to wait') and names the alternative plus its selecting condition ('for the fee a past transaction actually paid use eth_receipt'). This is exactly the when/when-not/alternative structure the rubric reserves for a 5.

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