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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description consistently describes a read/audit (not a mutation). It adds valuable behavioral context beyond annotations: the GPTBot-identifying fetch to catch WAFs, the no-JS nature of AI Overview/Copilot SERPs being mentions-only, the retrievability-first blocker semantics, and per-(query×engine) billing. These are non-obvious operating characteristics.

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?

Front-loaded with the single-sentence purpose and the seo_audit routing, which is strong. But the middle is a very long run-on enumeration of every check (robots.txt, JSON-LD, headings, readability, paywall tokens, etc.) that reads as a spec dump rather than earning each phrase; it inflates the description well past what an agent needs to select and invoke the tool.

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 complex 12-parameter, open-world audit tool with no output schema, the description covers the pillars returned, blocker semantics, the citation panel behavior, and the distinction from seo_audit. Nothing essential to invoking it correctly (or interpreting that a not-indexed page caps the score) is missing.

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 description coverage is 100%, so baseline is 3; the description goes well beyond by explaining the semantics of key optional params: `queries` triggers the citation panel and is billed per (query×engine), `offsite` adds a pillar and costs 5 SERP calls, `engines` values are explained (aio/copilot/API approximations/deepseek), and `no_retrieval` is described as the strongest predictor that is on by default. This meaningfully supplements the schema.

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?

States a specific verb (audit) and resource (AI assistants' ability to read/cite a page), lists the actual engines, and enumerates the pillars measured. It explicitly distinguishes itself from the sibling seo_audit ('Use this instead of seo_audit when the question is AI answers rather than Google rankings'), so an agent can route correctly 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?

Gives clear context and the key branch: on-page only when `queries` is omitted, citation panel when `queries` is set, and it names the alternative (seo_audit) with the distinguishing condition. However, no explicit when-NOT-to-use beyond the seo_audit contrast, and no guidance on whether to pre-fetch the URL.

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