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

Beyond the annotations (readOnly, openWorld, non-destructive), it discloses that results are cached for 1 hour, that the checks are deterministic with no AI model and no account, that null status means the site gave no answer, that errors come back as one plain sentence, and that reports are retained 30 days. It also states the privacy/recording model (domain and path recorded, never query string, IP or page text), which is exactly the kind of context annotations cannot carry.

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 capability is front-loaded in the first sentence and the exclusion list follows logically, with no filler or marketing language. It is dense and long, however, and the result-shape information is split between the inline '(url, status, contentSignals)' style listing and the later 'Returns JSON: summary..., reportUrl... and result' sentence, which creates mild redundancy.

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?

There is no output schema, so the description correctly carries the return shape itself, naming the result keys (robotsTxt, aiCrawlers, sitemaps, agentFiles, markdownVersion, findings), the agentFiles outcome enum, and the top-level summary and reportUrl. Caching, error format, and data-retention notes round out everything an agent needs to call it and interpret the answer.

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 baseline is 3, and the description earns an increment with 'Only the origin of the URL is used' — telling the agent that the path in the input does not affect the fetch, a behavior the schema does not convey. The later note that the path is recorded but the query string is not reinforces this, though the interaction between those two statements takes a careful read.

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 a specific verb and resource: 'Reads a site's own files', then enumerates exactly which files (robots.txt, Content-Signal lines, sitemaps, llms.txt, /.well-known agent files, Markdown home page). It also draws a boundary against unrelated capabilities (rankings, keyword volumes, backlinks, AI answer mentions), though it never names a sibling tool it might be confused with, which keeps it at 4 rather than 5.

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?

'Use it to see whether AI crawlers may read the site and what it offers agents' gives a clear task-level context, and the exclusion sentence tells the agent what this tool will not answer. What is missing is an explicit routing statement — siblings like can_ai_fetch and check_agent_readiness overlap conceptually, and the description does not say when to prefer them.

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