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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious traits: a 15-second cache and the $0.001-per-call price via x402 USDC on Base or Solana, which materially affects how an agent should batch or repeat calls.

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 classification question leads, followed by exact output fields, usage triggers, then operational details (cache, price). Slightly redundant phrasing between the opening question and the field enumeration, but every clause carries information.

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?

With no output schema, the description compensates by listing the returned fields and the account-type taxonomy, which is what an agent needs to interpret results. Cost and caching are also disclosed; only the payment parameter and per-chain failure behavior remain unaddressed.

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 only 33%, so the description has to carry weight. It does usefully enumerate chain values (Base, Ethereum, Arbitrum, BSC, Polygon, Optimism, Avalanche) and the 'all' scope for the undescribed chain parameter, but says nothing about the payment 'tx' parameter beyond what the schema already states, and the address format relies on the schema pattern.

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 question the tool answers ('wallet or contract?') and enumerates the outputs it returns: wallet vs contract vs EIP-7702 delegated account, bytecode size, nonce, native balance. This implicitly separates it from the sibling evm_balance (balance only) and wallet, though no sibling is 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?

'Use before sending funds or to sanity-check a counterparty' gives a concrete decision context, and the scope 'for one address on one or all EVM chains' frames the calling pattern. It stops short of explicit exclusions or naming evm_balance/evm_call as alternatives for narrower queries.

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