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

With no annotations, the description carries the burden and delivers: no API key, no account, $0.005 per call paid over x402 in USDC, and the data source (last 20 blocks of real fee history). It does not describe the shape of the returned tiers or what happens if chain is omitted, which is the remaining gap.

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-loaded with the activation condition, followed by exclusions and then cost/auth in a single dense block. Every clause carries information an agent needs; nothing is restated from the schema.

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?

For a one-optional-parameter, no-output-schema tool, this covers trigger, exclusions, cost, auth, and computation source — enough to call it correctly. The only shortfall is the undocumented default/omission behavior for chain.

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 100% and the single chain parameter already lists base|ethereum|polygon|arbitrum|optimism in the schema. The description adds nothing about the parameter itself — notably not whether chain can be omitted or what the default is — so this lands at the high-coverage baseline.

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+resource (suggest EIP-1559 fee caps) with concrete scope: base fee plus maxFeePerGas/maxPriorityFeePerGas at slow/normal/fast, derived from the last 20 blocks. It explicitly distinguishes itself from evm_gas (legacy price) and evm_estimate_gas (per-call pricing), so an agent can route without opening a 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?

Explicit when-to-use (building an EIP-1559 transaction and needing caps that actually get mined) and explicit when-not-to-use, naming both siblings by their alternative routes. No inference required.

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