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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool splits a hostname into labels, but does not describe the output format (e.g., array of strings, object), error handling, or which of the multiple input parameters is actually used. The presence of many seemingly unrelated parameters (ref, city, json, etc.) without explanation adds confusion about the tool's real behavior.

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 that contains no filler or redundant wording. It efficiently encapsulates the tool's core function and a key limitation. The structure is ideal for a tool description.

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?

Given the absence of an output schema and the ambiguity around input parameters, the description is incomplete. An agent cannot determine which parameter to pass or what the result will look like. The tool is simple, but the description lacks essential context about input and output expectations, making it insufficient for confident invocation.

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 schemas' parameter descriptions are generic and not tailored to this tool—e.g., 'host' is described as 'Public hostname', which is vague, and other parameters like 'ref' or 'city' appear arbitrary. The tool description does not clarify which parameter is relevant for the splitting operation, nor does it add meaning to the parameters. With 9 parameters and no guidance on their roles, the description fails to provide semantic clarity beyond the already present (and confusing) schema descriptions.

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 function: 'Split a hostname into labels'. This is specific and unambiguous, and the clause 'without WHOIS or ownership data' distinguishes it from tools that provide richer domain information. The purpose is immediately 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 implies usage for splitting hostnames, but does not explicitly state when to prefer this tool over related tools like 'normalize-url' or 'browser-url-ok'. The phrase 'without WHOIS or ownership data' hints at what it does not do, but no direct alternative is named. Guidance is implicit rather than explicit.

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