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

Annotations already cover readOnly/openWorld/idempotent, so the description's job is to add operation-specific context — and it does: it discloses the 10-40 second runtime, that the page is genuinely loaded on Google's infrastructure, and that it works on any public site. These are the exact facts an agent needs to set timeouts and expectations, none of which appear in the annotations.

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 core verb/resource in the first clause, then outputs, then the authoritative claim. Every sentence earns its place except the slightly editorial 'which is what no amount of reading a site's HTML can substitute for,' which is persuasive but adds length without new call-time information.

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-call audit tool with 100% schema coverage and rich annotations, the description covers purpose, output shape, runtime, and the key default that affects speed. There is no output schema, yet the description already summarizes the returns (scores, lab metrics, ranked fixes with savings), leaving nothing an agent needs 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 the schema already documents all five parameters with defaults and enum values. The description adds the important default-cost note that 'performance only' is the default and 'much faster,' which helps the agent reason about strategy/categories tradeoffs beyond the schema's plain default statement.

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 and resource ('Run Google's PageSpeed Insights (Lighthouse) against any public URL') and enumerates exactly what comes back — scores, lab metrics, and ranked fixes. It distinguishes itself from the sibling pagespeed_field_metrics by explicitly claiming AUTHORITATIVE status for diagnosing lab-side slowness, making the distinction clear.

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 a clear when-to-use: 'why is this page slow and what do I fix first,' and adds 'including a competitor's.' However, it never names the sibling pagespeed_field_metrics or explains when field data is preferred over lab data — which is the natural alternative for this tool.

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