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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond them: the 5-page crawl cap, that requests are read-only, that artifacts are generated only for failed checks, and that unknown values are emitted as visible placeholders rather than omitted. It stops short of describing response shape or runtime failure modes.

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?

It is a single dense paragraph with the what-it-does clause front-loaded and the artifact list immediately after, so an agent scanning the first sentence gets the core purpose. Every clause carries information, though the sentence runs long and could be split for faster parsing.

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 generation tool with no output schema, the description enumerates the returned artifacts and their intended placement, plus how unknown data is handled — enough to call it and interpret results. What remains thin is the response envelope itself (where files appear, error behavior when a site is unreachable), which is a modest gap given no output schema exists.

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% with a fully documented nested facts object, so the baseline would be 3. The description earns above baseline by explaining how facts interact with the crawl: values are taken from the site's own pages first, facts override them, and unknowns become visible placeholders — semantics an agent could not infer from the per-field descriptions alone.

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 uses a specific verb+resource ('Checks one public website ... returns ready-to-apply fixes') and enumerates the concrete artifacts produced: Organization JSON-LD, llms.txt, an AI-crawler robots.txt section, meta description and Open Graph tags. It does not explicitly name or contrast with sibling tools scan_website or compare_scan, so the boundary between 'scan' and 'get fixes' is only implied by the phrase 'what the check found'.

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?

Usage is implied rather than stated: 'for what the check found' and 'files are made only for checks that failed' suggest this follows a scan, but the description never tells the agent to run scan_website first or when to prefer compare_scan. There are no explicit when-not-to-use conditions, though the 'one public website, up to 5 pages' scoping gives a practical boundary.

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