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

With no annotations, the description carries full responsibility. It discloses the cost ($0.09 via x402), the output contents (base-fee trend, percentiles, utilization, recommended fees with reasoning), and supported chains. It does not mention error cases or side effects, but as a read-only data tool, none are expected. This is solid transparency.

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 three sentences, information-dense with no filler. It front-loads cost and main purpose, then details deliverables, and ends with a clear differentiator. 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?

No output schema exists, but the description clearly enumerates the outputs: base-fee trend, percentiles, mean utilization, and recommended maxFeePerGas/maxPriorityFeePerGas with reasoning. It also lists supported chains. This is sufficient for an agent to understand what the tool returns and its scope, though it lacks error/edge-case details.

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%: chain and blocks are described. The description reinforces these by mentioning 'N blocks' and listing chain values, but adds little beyond the schema for these. The x_payment parameter is undocumented in schema; the description provides context by stating the price and x402, giving a partial hint. However, it does not fully explain how to use the parameter, so it does not fully 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?

The description clearly states the tool's function: providing EIP-1559 fee history with base-fee trend, priority-fee percentiles, utilization, and recommended fee parameters. It distinguishes itself from a simple gas-price tool by explicitly contrasting with a single gas number: 'A single gas number cannot tell you whether fees are rising; this can.' This precise resource and purpose differentiation earns full marks.

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 when to use it: when fee trends are needed rather than a one-off gas price. It also lists supported chains, which helps with selection. However, it does not explicitly name alternative tools or provide exclusion criteria, so it is clear context but not explicit alternatives.

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