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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description still adds real value by disclosing the fallback behavior (site-level data when a page has too few visits), the 28-day field-data window, the device split, and that no Google authentication is required. It stops short of noting latency, quota, or that only public URLs are accepted as a hard restriction.

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 outcome ('How fast a public web page loads') followed by source and option detail; both sentences carry information. The trailing 'Tools revision: d80f65c0' is noise that does not help an agent decide or call 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?

With an output schema present, return shape need not be spelled out, yet the description still characterizes the response (field data versus lab run, score, biggest fixes). Combined with annotations and the disclosed auth and fallback behavior, an agent has nearly everything needed; only rate/cost expectations are 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 0%, so the description must carry the parameter load, and it largely does: 'phones or desktops' maps onto the strategy enum, 'public web page' scopes the url, and include_seo is explicitly explained as adding Lighthouse failed SEO checks. The strategy values are not named exactly as MOBILE/DESKTOP, leaving a small inference gap.

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 measurement ('How fast a public web page loads') and names both data sources it returns (Chrome UX Report field data plus a PageSpeed Insights lab run with performance score and top fixes). An agent can immediately tell this apart from audit or reporting siblings such as site_index_audit or full_audit.

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 context is implied rather than stated: it must be a 'public web page', and 'Needs no Google sign-in' signals it can be used without account setup. It never names an alternative tool (e.g. site_index_audit or full_audit) or says when not to use it, so the routing guidance is only partial.

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