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

With no annotations, the description carries the full burden. It usefully discloses the API-key fallback chain (GOOGLE_API_KEY or PAGESPEED_API_KEY) and the shape of the result, but says nothing about runtime behavior such as audit latency, quota/rate limits, or failure modes when a page is unreachable.

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 opening sentence states the core action, the second lists outputs, and the Args block is compact and scannable. It is slightly padded by enumerating return metrics even though an output schema exists, but nothing is wasted or buried.

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 three-parameter read-style tool with an output schema, the definition covers purpose, all inputs, and credential handling, so an agent can invoke it correctly. What is missing is decision context relative to the sibling CrUX tools and any note on expected latency or error behavior.

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 0%, so the description must carry all parameter meaning, and it largely does: url is documented with a concrete example, strategy lists both accepted values with its default, and api_key explains the optional env-var fallback. The only gap is that the schema has no enum enforcing 'mobile'/'desktop' and the description does not say what happens on an invalid value.

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 opens with a specific verb+resource ("Run a Google PageSpeed Insights lab audit") and scopes it as synthetic Lighthouse data with named metrics, which is enough for an agent to know what it produces. It never names the sibling tools (get_crux_metrics, get_crux_history), so the lab-vs-field distinction is only implied, not stated.

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?

There is no when-to-use or when-not-to-use guidance, and no routing hint toward or away from the CrUX siblings. The word "synthetic" hints that this differs from real-user field data, but the description never tells an agent which to pick for which question.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool checks PyPI, implying a read-only network operation, but does not disclose caching, side effects, failure behavior, or what 'force' changes.

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 description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to conveying the tool's exact purpose.

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?

The tool is simple and the output schema exists, so return details need not be in the description. However, the description omits any explanation of the 'force' parameter and provides no usage context, leaving meaningful gaps.

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 0% for the single 'force' parameter, and the description does not mention or explain it at all. The description therefore fails to compensate for the undocumented parameter.

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 (Check) and resource (PyPI latest version of core-web-vitals-mcp), so an agent can immediately understand the tool's purpose. It does not, however, explicitly differentiate itself from any sibling tool.

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?

There is no guidance on when to use this tool, when not to use it, or which alternatives exist. The purpose implies a context, but usage is left entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that network endpoint testing occurs and that credentials are validated, which hints at the operation's nature, but it never states whether the tool is read-only, whether it makes live external calls, or what side effects (if any) it has. A diagnostic tool with zero annotation coverage deserves more safety profile context.

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 description is brief and front-loads the three core actions before the Args section. The Python-style 'Args:' block is slightly awkward but compact, and no sentence is wasted.

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 needn't be explained. However, for a credential/diagnostic tool with no annotations, the description leaves key operational questions unanswered: whether it is safe/read-only, and what happens when api_key is null.

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 0% and there is one parameter, so the description must compensate. The Args note does clarify that api_key is optional and is used to 'test directly', adding real meaning over the bare schema — but it doesn't explain the default behavior when the key is omitted (which credentials are tested instead).

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 names three concrete diagnostic actions — validating Google Cloud API credentials, testing endpoint reachability, and checking test beds — which is far more informative than the opaque name 'doctor'. Siblings (Crux metrics, PageSpeed, skills) are unrelated, so no sibling differentiation is required, but 'check test beds' is vague about what a test bed actually is.

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?

There is no guidance on when to run this diagnostic versus other tools, what triggers it, or what prerequisites exist (e.g. which ambient credentials are used when api_key is omitted). The description only states what it does, leaving the agent to infer that this is a troubleshooting tool.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful behavior — 28-day window, 25+ weekly collection periods, the exact metric set returned, and the API-key fallback chain (GOOGLE_API_KEY / CRUX_API_KEY) — but says nothing about quotas, rate limits, error/empty-data behavior, or when history is unavailable for a low-traffic origin.

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 API and scope in the first sentence, followed by the return shape, then a compact Args block. No filler, though the Args list slightly restates parameter names already visible in the schema.

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 described, and both parameters are covered including the auth fallback. The remaining gap is deciding between this and get_crux_metrics plus operational caveats like rate limits or missing-data cases.

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 0%, so the description must compensate, and it largely does: it explains url_or_origin accepts either a full page URL or an origin domain with an example, and clarifies that api_key is optional by describing the environment-variable fallback. It stops short of format/filtering details for url_or_origin (e.g., protocol requirements).

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 (Query) and resource (Chrome UX Report History API) and scopes it to 28-day historical field metric trends with named metrics (LCP, INP, CLS, FCP, TTFB). This implicitly separates it from the get_crux_metrics sibling, but it never explicitly contrasts the two, so an agent must infer which one returns snapshots vs. history.

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 only implied: 'historical field metric trends' suggests reaching for this when a timeseries is wanted rather than a single snapshot, but there is no explicit when-to-use, when-not-to-use, or named alternative (get_crux_metrics) to route between them. No prerequisites (e.g., that a URL/origin must have sufficient CrUX traffic) are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that api_key falls back to GOOGLE_API_KEY/CRUX_API_KEY environment variables and that results are 75th-percentile field ratings, but it omits failure modes (URLs with insufficient real-user data), rate limits, and confirmation that the call is a non-mutating read.

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-loads the purpose and return values, then a clean Args block with one line per parameter. No filler sentences; only minor verbosity in restating the metric list in two places.

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-value detail is a bonus rather than a requirement. Required and optional parameters are fully covered, and the only real gap for an agent calling this correctly is undocumented error behavior for low-traffic URLs.

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 0%, so the description must compensate, and it largely does: it documents all three parameters with a concrete URL example, root-origin vs page-path semantics, the accepted form_factor values ('ALL_FORM_FACTORS', 'PHONE', 'DESKTOP', 'TABLET' – none of which are enums in the schema), the default, and api_key resolution order.

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: queries the CrUX API for real-user field metrics, and enumerates the exact metrics returned (LCP, INP, CLS, FCP, TTFB, overall CWV assessment). An agent knows precisely what this produces, though it never names or contrasts itself with the sibling get_crux_history.

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 only implied by the phrase 'real-user field metrics' – an agent can infer this is the tool for current CrUX data, but the description never states when to prefer it over get_crux_history or audit_pagespeed, nor any prerequisite (e.g. URL must have sufficient traffic for CrUX data).

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' and 'playbook' imply a non-destructive lookup, and the examples hint at content type, but there is no statement about what happens on an invalid name, whether content is static/cached, or any permission requirements.

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?

Purpose and examples are front-loaded in one sentence, and the argument note is brief. The 'Args:' block largely restates the schema parameter name, which is minor boilerplate rather than genuine waste.

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-parameter read tool with an output schema already covering the return payload, the description supplies the essentials: what is read, examples of valid inputs, and where to discover names. Only the invalid-input behavior is unaddressed.

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 0% for the single 'name' parameter, so the description must compensate. It does add value by supplying three concrete valid example values and pointing to skills_list for the full set, but it gives no format rules (casing, hyphenation, prefixing).

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 (Read) and resource (Core Web Vitals optimization playbook) and grounds it with concrete playbook identifiers ('lcp-optimization', 'inp-debugging', 'cls-remediation'). It is clearly distinguished from siblings like get_crux_metrics and audit_pagespeed, which gather data rather than return written guidance.

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 explicitly routes the agent to skills_list to discover valid names, which is the key prerequisite for invocation. However, it never states the trigger condition (e.g., 'use before attempting CWV optimization' or 'when audit_pagespeed reports a failing metric'), leaving when-to-use implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the content domain (Core Web Vitals playbooks covering LCP, INP, CLS), which is useful, but says nothing about read-only safety, whether the list is static or versioned, or how results are ordered.

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?

A single front-loaded sentence that identifies the verb, the resource, the domain, and the covered metrics with zero wasted words.

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 zero-parameter list tool with an output schema, the description supplies enough to call it correctly and know what domain it returns. It could be marginally stronger by noting that skill_read is the follow-up for fetching a specific playbook.

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?

The tool takes zero parameters and schema description coverage is 100%, so there are no parameter semantics to explain. Baseline 4 applies.

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 ('List') and resource ('playbooks') scoped to Core Web Vitals diagnostics and remediation, with concrete examples (LCP, INP, CLS). The distinction from the sibling skill_read is implied by the list/read pairing but never made explicit in the text.

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?

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative skill_read for retrieving a specific playbook. The discovery intent is only faintly implied by the verb 'List'.

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