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

With no annotations, the description does carry useful behavioral context: the upstream data source (rdap.org / Nominet) and the exact per-call cost ($0.002 USDC), plus which fields come back. It does not disclose read-only status explicitly, how unregistered or invalid domains are reported, or the response format — gaps that matter for a paid lookup with zero annotation coverage.

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 purpose and returned fields are front-loaded and the example is compact, but the trailing 'Related:' list grows into a price sheet that includes loosely related items (/company $0.25, /kyb $2.50) diluting the signal. The colon-separated fragments are terse but readable.

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 simple single-parameter read lookup with no annotations and no output schema, the description covers what is returned, the data source, and the cost — enough to call it confidently. Missing only failure-mode behavior and output encoding, which are secondary here.

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 0% and the single 'domain' property has no description, but the example {domain:"stripe.com"} demonstrates the expected format (bare registrable domain, no scheme or path). That is meaningful compensation for a one-parameter tool, though it does not say whether subdomains, IDNs, or full URLs are accepted.

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?

Opens with a specific verb+resource ('RDAP domain registration lookup') and enumerates the returned fields (registrar, registered, expires, age_days, status), which distinguishes it from dns_lookup or check_domain. The only weakness is that the differentiator siblings are referred to by path aliases ('/dns', '/check') rather than their actual tool names, forcing the agent to map them.

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 'Related:' menu signals that DNS records and domain posture are covered by other tools and prices them, which implies a routing choice. However, it never states a selection condition ('use this when you need registration dates rather than DNS/TLS'), and the alias names do not map cleanly to sibling tool names, so the guidance is inferred rather than explicit.

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