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

No annotations are provided, so the description must fully disclose side effects and behavior. It does note that the tool 'discards' some parameters (ref, city, feed, json, query) and 'no disk access' for path, but it doesn't mention that the robots.txt content is not returned, only counts. It also doesn't state any caching, rate limits, or network behavior, leaving the agent uncertain about side effects.

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 sentence, concise and to the point. It front-loads the action and output, and does not waste words. It could be more structured (e.g., bullet list of effects) but it earns its place.

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?

With 9 parameters and only 0 required, the description is very incomplete. It does not explain which parameter is the primary target (URL? host?), whether any parameter is ignored for the core function, and what the output format looks like. Given the high complexity (many parameters, many are discarded), the description should clarify the effective input for the robots.txt fetch. This is a significant gap.

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 coverage is 100%, so the schema describes each parameter's role. The description adds no parameter-level detail beyond that; 'url' and 'host' are both listed but not disambiguated (which is used to fetch robots.txt?). The description mentions 'group counts only' which implies a focus on the response, but not tied to specific parameters. Baseline 3 is appropriate since the schema carries the detail.

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 action ('Fetch a public robots.txt') and a specific output ('return group counts only'). However, it does not clarify which parameter supplies the URL (likely 'url' or 'host'), and the name 'inspect-robots' is somewhat generic. It is distinguishable from siblings like 'fetch-status' but not from a generic web fetch tool without more context.

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 over siblings like 'web-fetch' or 'fetch-status'. The description does not mention any alternatives or conditions, so an agent may not know that this tool is for lightweight robots.txt inspection (e.g., for compliance or quick checks) versus a full fetch.

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