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

With no annotations provided, the description carries the full transparency burden. It does disclose that the tool scans all supported TLDs/registries unless filtered, and that results are detailed. However, it does not state whether this is a read-only operation, what the detailed result structure contains, whether defaults apply, or any rate-limits or side effects—leaving meaningful behavioral gaps.

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 compact and front-loaded with the core action, then immediately provides required and optional parameter examples. Every sentence earns its place; there is no filler or repetition of schema fields.

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?

The description covers purpose and all parameters with examples, which is enough to make a basic call. However, there is no output schema, and 'detailed results' is too vague about the return shape, availability semantics, or default behavior, so an agent cannot fully anticipate the response before invoking the tool.

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 must compensate. It does add semantics by marking keyword as required, registries/tlds as optional, and providing concrete comma-separated example values for each parameter. This gives an agent a better understanding than the bare schema alone, though exact registry/TLD enumeration and dot conventions are not specified.

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 a specific verb ('Check'), resource ('keyword availability'), and scope ('across all supported TLDs and registries'). It also signals 'detailed results', which helps differentiate it from the sibling checkKeywordAvailabilitySummary. This is a clear, actionable purpose statement.

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?

No guidance is given about when to choose this tool over checkDomainAvailability, checkHostAvailability, or checkKeywordAvailabilitySummary. The description only explains required and optional parameters, not the use case or exclusions. An agent must infer the appropriate context from the tool name and sibling list.

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