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

With no annotations, the description carries the full burden, but it only reveals the basic action and a single non-goal. It does not describe behavior for invalid input, how irrelevant parameters are treated, or what a typical response contains.

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 a single, compact sentence with no filler or redundancy. It front-loads the action and object while adding a useful exclusion, making it highly concise.

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 tool has nine optional parameters and no output schema, but the description does not clarify how parameters map to the operation, which are ignored, or what a successful result looks like. This leaves too much ambiguity for confident use.

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?

Although schema descriptions cover all parameters, most are unrelated to splitting a hostname (e.g., git ref, city, RSS feed, JSON) and appear generic or mismatched. Only 'host' aligns clearly with the tool purpose, and no parameter is identified as the primary input.

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 identifies the action as splitting a hostname into labels and explicitly excludes WHOIS or ownership data. It does not mention output format, but the core purpose is understandable.

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 gives no guidance on when to choose this tool over siblings like normalize-url or fetch-status. It also does not explain which of the nine optional parameters should be supplied or how the tool should be invoked.

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