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

Beyond the readOnly/openWorld annotations, it discloses the exact evidence sources checked, the full verdict vocabulary with the meaning of the ambiguous readable_not_for_index state, the limitation that user-agent/IP firewall blocks are invisible, that checks are deterministic with no model and no account, and that reportUrl is retained 30 days. It also discloses its recording/privacy behavior (domain and path only, never query string, IP or page text), which an agent would otherwise have no way to know.

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?

Purpose and trigger are front-loaded in the opening two sentences, and the length is justified by the absence of an output schema. The middle section is dense but readable; the only minor inefficiency is that return-shape detail and scope-boundary detail are interleaved rather than grouped.

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 no output schema, the description correctly takes on the return-value burden, spelling out summary, reportUrl (with 30-day retention and null case) and the result.bots verdicts plus robotsTxtAllows and pageDirectives. Combined with annotations covering the safety profile, an agent has everything needed to select and call this tool and interpret the response.

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 both parameters (url as an absolute http/https page URL, bot as a single robots.txt product token defaulting to all tracked AI crawlers) are already fully documented in the schema. The description reinforces the 'one page' semantics and that result.bots enumerates every crawler, but adds no format, validation or defaulting detail beyond the structured fields.

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 first sentence gives a specific verb (checks), a precise resource (whether AI crawlers may read one page) and enumerates the exact evidence sources: robots.txt, robots meta tags, X-Robots-Tag header and HTTP status. The 'one page' scope implicitly separates it from site-level siblings like check_robots_sitemap_llms_txt, but no sibling is ever named, so differentiation is inferred rather than stated.

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?

It gives an explicit trigger condition ('Use it when the person asks whether ChatGPT, Claude, Perplexity or Google can see a page, or whether blocked crawlers explain why the site is missing from AI answers') and clear exclusions: firewalls that block by user agent or IP are not visible, and rankings, keyword volumes, backlinks and AI-answer mentions are out of scope. It stops short of naming which sibling tool should be used instead for those out-of-scope questions.

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