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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses real behavioral limits: robots.txt and Content Signals are authoritative while network-level Cloudflare blocking is 'von außen nicht sicher feststellbar' (surfaced in notes), and a spoofed User-Agent probe can be rejected even when the real bot passes. It also gives interpretation semantics (missing/4xx = everything allowed, unreachable/5xx = everything blocked per RFC) that an agent could not infer on its own.

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?

Structure is excellent and front-loaded: purpose question, method, motivation, then parameters, then caveats, then return shape. It is long, though – the exhaustive bot list and the multi-line Rückgabe block partly duplicate what the output schema already conveys, which keeps it from a 5.

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 read-only, open-world diagnostic with 4 optional params and an existing output schema, the description covers everything an agent needs: what is checked, defaults and fallbacks, how to phrase results honestly (live probe caveat), and how to interpret missing vs unreachable. No material gap in calling it correctly remains.

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 0%, so the description carries the full load and does: url accepts a domain or URL with a documented fallback to the workspace's Search Console property / WordPress URL; paths defaults to ['/'] with max 10 and an example; check_live is boolean, default off, with an explanation of what it actually performs; workspace is a slug needed only when url is omitted. All four parameters gain meaning beyond the bare type declarations.

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 opening question plus 'Prüft robots.txt (nach RFC 9309), Cloudflare-Signale und die Robots-Angaben der Startseite für 16 Bots' names a concrete verb (prüft) and resource (robots.txt, Cloudflare signals, page robot directives) and enumerates exactly which bot groups are covered. This is unmistakably a crawler-permission audit, distinguishable from sc_url_inspection or bing_crawl_issues.

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 'Anlass' paragraph gives an explicit trigger context (Cloudflare blocking AI-training/agent crawlers by default since 15.09.2026, pages can silently become invisible to ChatGPT/Claude), which tells an agent when this tool is the right choice. It also warns that check_live is 'NUR EIN INDIZ' and should never be reported as 'Bot ist gesperrt'. It stops short of naming an alternative sibling tool for a narrower/broader check, so 4 rather than 5.

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