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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered; the description usefully adds that only passive GETs are made and that the page is fetched repeatedly under six separate User-Agents to catch CDN/firewall blocks. It also discloses the return shape ("a 0-100 score and fixes"), which matters because no output schema exists, though it says nothing about latency or request volume despite the multi-fetch behavior.

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 core purpose is front-loaded in the first clause, which is good, but the remainder is one enormous run-on sentence packing a long enumeration of bots and artifacts. The detail is substantive rather than filler, yet a structured list of check categories would scan far better than the comma-spliced chain.

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?

For a single-parameter, read-only audit tool with no output schema, the description covers what is inspected, the method (passive GETs, multi-User-Agent loads) and the shape of the result. It stops short of stating runtime expectations or how the result differs from the sibling seo_check output, which keeps it from being fully complete.

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?

There is a single required parameter with 100% schema description coverage, so the schema already carries the syntax and examples (bare domain or full URL). The description only restates "public URL" without adding accepted formats, redirect handling, or normalization rules, so baseline 3 applies.

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?

Opens with a specific verb and resource: "Checks whether AI crawlers and AI search tools ... can read and cite a public URL." The enumerated checks (robots.txt for named bots, llms.txt, JSON-LD, agent readiness) make the AI-crawler focus distinctive enough to separate it from seo_check or security_headers_check without opening the schema.

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 scope line "Passive GETs of public URLs only" sets a clear boundary on what may be checked, and the mention of firewall/CDN blocks explains the value of the multi-User-Agent probing. It never explicitly routes the agent to bulk_check for many URLs or to seo_check for general SEO, so the alternatives remain implied rather than stated.

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