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

The description adds substantial behavioral context beyond the annotations: it explains that reverse names are confirmed by forward resolution, that unset records are distinguished from unavailable reads, that results are cached for 60 seconds, and that unsupported off-chain resolver reads are unavailable. These details are exactly what an agent needs to interpret results correctly.

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 description is three compact sentences with no wasted text. It leads with the when-to-use condition and then layers behavioral details in a logical order.

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?

Given the rich schema and read-only annotations, the description is largely complete for invoking the tool correctly. It does not explicitly describe the return shape or payment flow, but it does state the key output distinction between unset records and unavailable reads.

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 description coverage is 100%, so the schema already documents the chain enum, input examples, payment payload, and holder pricing. The description does not add parameter-specific syntax or constraints beyond what the schema provides, so the baseline score of 3 is appropriate.

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?

The description names the exact resource and operation: forward or reverse ENS resolution, and Basenames resolution on Base. It is specific enough that an agent can distinguish this tool's purpose immediately, and it does not overlap with any listed sibling.

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 phrase 'Use when an agent needs forward or reverse ENS resolution' gives a clear triggering condition and the supported chains. It lacks explicit when-not guidance or named alternatives, but no sibling tool appears to overlap with this resolution capability.

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