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

With no annotations, the description carries the full burden, and it does this well by disclosing the network (Ethereum mainnet), the price, the payment rail and chain (USDC on eip155:8453 via x402), the exact payment field (params._meta["x402/payment"]), and the raw HTTP endpoint. It also notes that the reverse lookup performs a forward-match check, a non-obvious behavioral trait. It stops short of stating what happens when no record or no reverse record exists, which matters for a resolver.

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 and front-loaded: the purpose and the two modes come first, then network, price, payment mechanics, and endpoint. Every clause carries operational information and there is no filler.

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?

Payment, network, and both call modes are covered, but with no annotations and no output schema the definition should say more about outcomes: what is returned when a name has no reverse record, whether a forward-match failure is an error or a boolean field, and which of the three loosely specified parameters is authoritative. Adequate to invoke the tool, not adequate to predict its responses.

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%: name and address are already described in the schema, so the description adds little for them. The undescribed enum parameter 'chain' (ethereum|base) is only obliquely addressed by mentioning Ethereum mainnet for resolution and Base for payment, leaving it genuinely ambiguous whether chain selects the resolution network or the payment network. It also does not say what happens if both name and address are supplied, even though zero parameters are required.

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 ('ENS resolution') and immediately splits the two modes: .eth name to address (forward) or address to primary .eth name (reverse). This is enough to distinguish it from the other chainread siblings, which cover balances, tokens, blocks, and transactions rather than name resolution.

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 tells the caller which input produces which output ('give a .eth name... or give an address'), which is genuine usage routing between the two modes. It does not, however, state exclusions or alternatives, for example that token or address metadata lookups belong to chainread__token or chainread__balance.

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