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

The description discloses that a network fetch occurs and that only group counts are returned, but it does not mention error behavior, handling of missing or malformed robots.txt, timeouts, rate limits, or any side effects. With no annotations, this minimal transparency is insufficient.

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 very short and free of fluff, which is good, but it omits critical information about parameter usage and output format. It is structured as a single sentence but lacks the substance needed to be fully useful.

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 no output schema, and the description does not explain the structure of the returned group counts, how counts are grouped, or which parameter is required to specify the target robots.txt. With nine optional and apparently unrelated parameters, the description is far from complete for an agent to call this tool correctly.

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 every parameter has a description, the descriptions are generic and largely unrelated to inspecting robots.txt. For example, 'url' is described as 'HTTPS URL to normalize or cite' rather than as the robots.txt location, and parameters like 'city', 'query', and 'zone' have no clear connection to the tool's purpose. The schema is a mismatched grab bag, so the descriptions add little meaningful semantics.

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 clear action ('Fetch a public robots.txt') and specifies the output ('return group counts only'), but it does not clarify which input parameter provides the URL or how the other parameters relate to the tool. The name helps, but the description alone leaves the selection ambiguous.

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 on when to use this tool versus the many sibling tools, such as fetch-status, normalize-url, or web-fetch. There is no mention of appropriate conditions, alternatives, or context, leaving the agent to guess.

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