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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, and the description reinforces this with an explicit 'reports and changes nothing' statement. More valuably, it discloses non-obvious behavior: contrast is measured on the rendered pages, which is why it catches light-on-light text after a colour change — context the annotations cannot convey. It stops short of noting cost/latency or result size for a full-site review.

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 front-loading is good — 'Review the draft' plus the default-focus behavior comes first — but the description is a dense ~200-word block that duplicates the parameter descriptions almost verbatim (broken links, alt text, SEO titles, form options, FAQ items appear twice). Trimming the mode enumeration to a pointer at the schema would tighten it substantially.

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?

With no output schema, the description must convey what each mode yields, and it does — problems-to-fix lists, design metrics, per-node explanation, and up to 3 next steps. Read-only safety is covered and the sibling set is unaffected. It could still say roughly how much output comes back from a full-site 'health' pass, but nothing an agent needs to call it correctly is absent.

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 75% and the focus enum is documented in detail inside the schema, so the description largely restates it. It does add two useful inferences beyond the schema: 'health' is the default, and supplying node_id implicitly selects 'explain'. That modest added value fits the baseline-3 case where structured fields do the heavy lifting.

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 states a specific verb (review) against a specific resource (the draft site) and then enumerates all four modes with what each returns, so an agent can distinguish 'health' from 'design', 'explain' and 'next' without opening the schema. The opening sentence is front-loaded and unambiguous about scope.

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?

It gives explicit triggers: run after a build, a big edit, or a set_theme colour change, and it maps the 'next' mode to the 'what should I do next?' question. What's missing is routing against siblings — it never says to prefer read_rendered_page or screenshot_page for raw inspection, or get_site for structure — but the when-to-use guidance itself is clear.

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