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

With no annotations provided, the description carries the full behavioral burden. It discloses one key behavioral fact: the result is a duration (days) since registration, which implies reading a registration date from some source. It does not disclose whether data is live or cached, how unregistered or privacy-redacted domains are handled, or the output value's format — though the presence of an output schema mitigates the format gap.

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?

A single eight-word sentence in label:value format with zero filler; every word carries semantic weight. The primary noun phrase is front-loaded, and the size is appropriate for a one-parameter, zero-required-parameter tool. Nothing is wasted or repeated beyond the harmless title echo.

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?

Complexity is very low (one optional parameter) and an output schema exists, which reduces the burden on the description. Still, with no annotations, the description alone must cover behavioral context, and it omits parameter semantics and sibling differentiation. It is minimally adequate for a trivial utility but leaves clear gaps an agent must infer past.

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% and the single parameter 'q' is never explained in the tool description. Its meaning (the domain to check) is strongly implied by the tool's purpose, but there is no format guidance — e.g., whether 'example.com' vs 'www.example.com' is expected, or whether a full URL is accepted. Since this is the only parameter, the gap is small in count but total in coverage.

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 states the resource (domain) and the result ('Days since registration') in an expandable label:value format that goes beyond the title. The '(phishing signal)' framing adds intended use context. It distinguishes from siblings only implicitly — computing an age metric is clearly different from whois/whois_check (full records) or regdomain (registrable-domain extraction) — but no sibling is named.

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?

There is no guidance on when to use this tool versus the many domain-related siblings (whois, whois_check, rdap_domain, regdomain), and no exclusions or alternatives are mentioned. The only hint is '(phishing signal)', which implies a security-investigation context but does not direct selection.

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