Get domain

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond them by disclosing the required API-key scope (domains:read) and naming the returned fields (nameservers, pending action), which helps an agent decide whether a call is permitted.

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 short sentences, front-loaded with what is fetched and followed by the auth requirement. No filler or restated title content.

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 single-read tool with no output schema and a fully documented single parameter, naming the returned fields and the required scope is close to sufficient. A brief note on error behavior for non-owned/invalid IDs would make it fully complete.

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?

Only one parameter, and the schema already documents it at 100% coverage ('Owned domain ID from list_domains'). The description adds nothing about the identifier beyond what the schema states, so the baseline 3 applies.

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 (Get) and resource (one owned domain) plus the payload scope (current nameservers and any pending domain action). It is immediately distinguishable from the sibling list_domains, which returns many domains.

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 description adds an auth condition (requires domains:read when using an API key) but never states when to reach for this tool versus list_domains or the other domain-inspection siblings. Usage is only implied by the 'one owned domain' scoping.

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