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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the upstream data source with a fallback path, the fact that errors are not charged, the x402 price and settlement chain (USDC on Base, Base-only payments), and the ~1-minute refresh cadence with the note that more frequent calls return identical values. The 'descriptive, not a forecast' framing also correctly sets expectations about the response's nature.

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 purpose, then usage, invocation, returns, provenance, and cost – a logical order with no filler sentences. The single return-value sentence is dense and enumerates six fields, but since no output schema exists that enumeration is load-bearing rather than padding.

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 zero-parameter, no-output-schema tool, the description covers everything an agent needs: what it returns field by field, units (gwei, ETH, USD), sourcing, staleness, cost, and payment chain. Safety semantics are already handled by annotations, so nothing material is missing.

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 tool takes zero parameters, so the schema carries no semantic load and the baseline is 4. The description affirmatively states 'Call GET with no parameters', which removes any doubt about whether arguments are expected, but adds nothing further since there is nothing further to add.

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 resource and scope: 'Gas price and gas fee estimate (Base, Ethereum)'. An agent can immediately distinguish this from sibling chain-data tools like tx_status, tx_guard, or balance without opening a schema, and the networks covered are named explicitly.

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 clear triggering context ('Use before sending a transaction on Base or Ethereum to choose fees and timing') plus invocation guidance ('Call GET with no parameters'). It does not name adjacent alternatives such as tx_guard or tx_status, so no exclusions are offered, but the when-to-use signal is unambiguous.

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