Check domain availability + price

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

Annotations cover read-only and open-world behavior, and the description adds real value beyond that: the availability source (RDAP via IANA bootstrap) with a WHOIS fallback, and the important caveat that price is only returned 'where a verified public source has it', i.e. pricing can be absent. It stops short of mentioning rate limits, auth, or handling of lookups that fail both paths.

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, front-loaded with what the tool returns, then the calling modes. The technical parenthetical is compact and 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?

Three parameters, no output schema, and no parameter descriptions, so the description is the only prose. It covers sources and the pricing caveat but says nothing about the shape of the response (per-domain availability status, how unavailable/invalid results appear) or whether the two input modes are mutually exclusive.

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 0%, so the description carries the burden, and it does explain the two calling modes (full domains vs. name plus tlds). It does not restate the concrete limits (40 domains, 12 tlds) or the character patterns, which the agent can only learn from the raw JSON Schema.

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+resource (check availability for domains) plus an explicit secondary output (first-year and renewal list price), and names the mechanism (registry RDAP with WHOIS fallback). It does not explicitly position itself against siblings like domain_lookup or tld_pricing, so the agent must infer the boundary.

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?

'Pass full domains, or a name plus tlds' describes how to fill the schema, not when to choose this tool over domain_lookup or tld_pricing. No conditions, exclusions, or alternatives are stated.

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