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

Beyond the readOnly and idempotent annotations, the description discloses pricing, free-tier limits, robots.txt matching rules, and the AI crawler list. This adds meaningful behavioral and cost transparency that annotations do not cover.

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?

Four sentences, each with a distinct role: use-case question, core functionality, matching rules/missing-robots behavior, and pricing. No redundant or filler content.

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 lists what the tool reports (sitemaps, crawl-delay, AI crawlers) and explains edge cases (missing robots.txt, matching rules), which is sufficient given no output schema. The main gap is not describing the response format, but the listed data points give agents enough to know what to expect.

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?

With schema coverage at 0%, the description carries the parameter burden. It explains that a URL is checked and that the check works for any user-agent, implicitly covering the user_agent parameter, but it never explicitly maps to the parameter names or notes the default value 'MAD-Synapse'.

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 opens with the question 'May I crawl this?' which immediately states the tool's purpose: checking a URL against robots.txt. It enumerates specific outputs (sitemaps, crawl-delay, blocked AI crawlers) and names several AI crawlers, distinguishing this from generic web tools like web_read or http_probe.

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 question 'May I crawl this?' provides a clear usage context, and the note about missing robots.txt meaning everything allowed gives practical guidance. It does not explicitly name alternatives or state when not to use the tool, so it misses the full 'when-not' criterion.

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