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

Annotations already establish this is a read-only, closed-world call, and the description adds substantive context beyond that: what each entry contains (completeness flag, missing required fields, default roles, registration handle) and the prerequisite ordering. It does not mention whether results are paginated or how many contacts are typically returned, but the key behavioral traits are covered.

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?

Three sentences, each earning its place: identity of the resource, contents of each returned entry, and the mandatory call ordering. The prerequisite warning is front-loaded at the end where it is most likely to be read as a rule.

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?

With zero parameters and an output schema present, the description only needs to explain the workflow role and the shape of the result, and it does both. The return fields (completeness, missing fields, roles, handle) are summarized so the agent knows what to do with the output before ever parsing the schema.

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 tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies there is no filtering input by saying it lists the authenticated customer's handles wholesale.

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 gives a specific verb and resource ('List the authenticated customer's registrant/contact handles for domain registrations') and scopes it to the authenticated customer, which distinguishes it from the broader list_contacts sibling. It stops short of explicitly naming how it differs from list_contacts, so it is clear but not fully sibling-differentiated.

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?

'Always call this before attempting a domain registration' gives a hard prerequisite tying it to register_domain, which is genuinely actionable. It does not say when to call it outside the registration flow or why list_contacts would not be the right choice, so it is clear context without explicit alternatives/exclusions.

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