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

Well beyond the annotations, which only declare readOnly/openWorld/non-destructive, the description discloses the 28-day aggregation window, the 75th-percentile basis, rating buckets, the URL-level vs origin-level fallback for low-traffic URLs, and caching behavior. This is unusually complete, with the only gap being no mention of error behavior for URLs absent from CrUX entirely.

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 one-line purpose, then organized into scannable paragraphs covering return values, the origin fallback caveat, and cache sharing. Every sentence carries actionable information with no filler.

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?

An output schema exists, so return values need not be re-explained, and the description still adds the interpretive layer (percentile, rating buckets, fallback). For a two-parameter read tool, nothing an agent needs to call it correctly 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 coverage is 100% and both parameters are documented, so the schema carries the semantics. The description reinforces the "public URL" constraint and clarifies that results are split at URL and origin level, but it never explains the strategy parameter's device-class effect beyond what the schema already says.

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 and resource ("Get Chrome User Experience Report (CrUX) field data for a public URL") and immediately scopes it to real-user metrics over 28 days. It also distinguishes itself from the lab-measurement sibling by contrasting real-user data against "a single Lighthouse lab run."

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?

Explicitly frames the selection condition: use this to answer "what do my actual users see?" rather than lab data, which implicitly routes the agent away from pagespeed_insights for field metrics. It also notes the shared 24h cache, telling the agent that calling both tools is cheap rather than redundant.

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