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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral context: 'Cannot spend money', returns 404 for reserved/premium names, only checks registration not site status ('registered' vs 'active' or 'dormant'), and warns that a clean result says nothing about name quality. No contradiction with annotations.

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 long but front-loaded with the key directive 'THE LAST GATE, NOT THE FIRST STEP'. Each sentence adds distinct value: usage timing, scope, caveats, and limitations. It is more verbose than necessary but not repetitive; the structured flow from purpose to interpretation to exclusions is effective.

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 tool with one parameter and no output schema, the description is exceptionally thorough. It covers what the tool does (checks registration), what it returns in different cases (404 for reserved/premium, 'registered' not active/dormant), how to interpret results (clean result says nothing about quality), prerequisites (names from suggest_names or scan_namespace), and usage timing. Nothing an agent needs for correct invocation is missing.

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%, so the description must compensate. It adds the 10-domain limit ('up to 10 domains') and clarifies the parameter is a list of domain names for registration checking. While it doesn't specify array format explicitly, the single obvious 'domains' parameter is adequately contextualized given the description's focus on domain checking.

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 clearly states the tool's purpose: 'Real-time authoritative registration check' and 'It answers only "is this registered"'. It distinguishes itself from siblings by positioning as 'THE LAST GATE, NOT THE FIRST STEP' and explicitly stating it does not evaluate name quality or price, unlike suggest_names or score_name.

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?

Explicitly specifies when to use: 'immediately before you recommend buying anything' and 'any time an earlier answer said "unknown", "pending" or "unprobed"'. It also gives exclusions: does not fetch the site, so not for active/dormant; does not tell price or buyability. It even describes behavior for unvetted names ('If none of the names you pass have been seen by suggest_names or scan_namespace, the response says so').

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