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

Annotations only cover readOnly/openWorld, but the description adds substantial non-obvious behavior: a hard quota (3 free calls/day across all tools), a price ($0.0025 USDC), two payment rails, the exact in-band payment parameter (params._meta["x402/payment"]), and the data provenance ('Public RPC data only'). Those are exactly the facts an agent needs before invoking a metered call, and none are inferable from annotations.

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?

Dense but every sentence carries information; nothing is padding. The only structural flaw is ordering: the description leads with pricing/quota rather than what the tool does, so the purpose arrives after the billing block instead of being front-loaded.

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?

Complete for a metered read tool: input semantics, both chains, output contents, payment assertion behavior, and cost/quota are all covered, and an output schema exists so return shapes need not be spelled out further.

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%, so the baseline is 3; the description earns an extra point by explaining that expect_to + expect_token + expect_amount work together as a payment assertion ('confirms a payment arrived'), which is more than the schema's per-field notes convey. It also clarifies that expect_token accepts a symbol or an address and defaults to USDC, reinforcing the enum-ish behavior for a free-text field.

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 and resource ('Base or Ethereum transaction hash -> plain JSON') and enumerates exactly what the output contains: status, block time, confirmations, from/to, value, gas/fee incl. Base L1 fee, method selector and all ERC-20/ERC-721 transfers. It also names the sibling tools it is not (wallet-profile, contract-abi, token-risk), 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?

An explicit 'When to use' clause gives the primary case (understand one transaction) and the concrete decision case (verify a USDC/ETH/ERC-20 payment before delivering goods). It then names three alternatives with their distinct scopes, which is exactly the when/when-not/alternatives pattern.

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