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

With empty annotations, the description carries the transparency burden. It discloses useful operational context: pooled/batch behavior, plan requirement, and per-domain quota consumption. However, it stays silent on per-domain failure behavior, result aggregation, authentication, and error handling, leaving the behavioral picture incomplete.

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?

Two sentences with no filler: the first names the operation and scope, the second adds the non-obvious constraints about plan and quota. The content is front-loaded and easy to parse.

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 3-parameter tool with fully documented schema, this is broadly complete: it identifies the data source, normalization, batch context, and quota implications. The remaining gaps are non-blocking, such as explicit single-vs-bulk routing and error behavior, and no output schema is expected.

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 input schema covers all three parameters at 100%, so the baseline is 3. The description adds only the quota-per-domain consequence for the domains parameter and does not meaningfully enrich the whois or follow semantics, which the schema already documents well.

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 opens with a concrete verb and resource ('Look up normalized RDAP registration data') and immediately states the batch scope ('several domain names in one pooled call'), which distinguishes it from the singular domain-lookup sibling. The tool's role is unmistakable.

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 'several domain names in one pooled call' phrasing gives a clear trigger for using this tool, and the Pro/Business plan plus quota statement provides an important decision constraint. It does not explicitly say to use domain-lookup for a single domain or list exclusion cases, so it stops short of full alternative routing.

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