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

Beyond the annotations, the description discloses quota cost (4 API requests = 4 quota units of 150/min), the exact number and type of records returned (all-devices + phone/desktop/tablet), per-metric p75/rating, traffic_share semantics, and no_data behavior for insufficient data. This is rich behavioral context with no contradictions.

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 four sentences long, front-loaded with the core purpose, then packing quota, output structure, no_data semantics, and defaults without waste. Every sentence contributes essential 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?

With no output schema, the description carries the full burden of explaining return values. It does so clearly: aggregated record plus per-device records, p75+rating per metric, traffic_share, and {no_data: true} for sparse devices. The behavior is fully specified for practical use.

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 schema has 100% coverage with detailed parameter descriptions, so the baseline is 3. The description adds value by specifying the default metrics ('Default metrics: the three Core Web Vitals') and reinforcing the mutual exclusivity of origin/url. It does not need to repeat schema details, but the added default behavior justifies a 4.

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 clearly states the tool 'Compares real-user performance across device classes for an origin or URL', with a specific verb ('compares') and resource ('device classes'). It distinguishes itself from siblings by focusing on phone/desktop/tablet breakdown, reinforced by the title.

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?

The description gives clear context on what the tool does and explicitly states 'Provide exactly one of `origin` or `url`', which is a key usage constraint. It also notes that tablet often returns no_data, guiding user expectations. However, it does not explicitly name alternative tools or state when to prefer this over them, so it falls short of a 5.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral details beyond those: it makes 2 API requests, returns p75 + rating per metric, and discloses that either side can return no_data. This gives the agent practical expectations without contradicting 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?

The description is concise at three sentences, with each sentence delivering useful information (purpose, API-request count, no_data behavior, default metrics, required params). It is front-loaded with the core comparison purpose. The only slight issue is the potentially misleading 'default metrics' phrase, but structurally it is tight.

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?

There is no output schema, so the description carries the burden of explaining return value semantics. It does state 'p75 + rating per metric' and covers the no_data edge cases, which is good. However, it omits details about how metrics and form_factor interact, and the contradictory default-metrics comment creates ambiguity. For a moderately complex comparison tool, this is adequate but not fully complete.

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%, so baseline is 3. The description adds emphasis that both origin and url are required (unlike other tools), which is helpful. However, it also states 'Default metrics: the three Core Web Vitals,' which directly contradicts the schema's instruction that omitting metrics returns all available metrics. This inconsistency confuses the parameter semantics and reduces the score.

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 uses a specific verb ('compares') and clearly identifies the two resources ('site-wide origin record' vs 'one specific page'). It also distinguishes from sibling tools by noting that both origin and url are required here, unlike the other tools. This makes the tool's unique purpose immediately evident.

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?

The description provides clear context by explaining the comparison goal ('tell whether a page is faster or slower than the site average') and useful caveats around no_data. However, it does not explicitly name alternative tools or state when not to use this tool, though the 'unlike the other tools' hint partially addresses this. This is strong but not fully explicit.

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?

Annotations already indicate a safe read operation (readOnlyHint, idempotentHint, non-destructive), but the description goes far beyond by disclosing exact output format (p75, ratings, densities summing to ~1.0), thresholds, passes_core_web_vitals definition, failure mode ({no_data: true}), and data quirks (redirects, key normalization, sparse tablet/single-page data). This is rich behavioral context beyond 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?

The description is dense but every sentence earns its place: a one-line purpose, then metric/threshold details, then edge cases and input constraints. It is front-loaded and free of filler, achieving high information density without bloat.

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?

There is no output schema, but the description fully defines what the agent will receive: which metrics, thresholds, ratings, densities, pass criteria, and the no_data response. It also covers input selection and data caveats, making it self-sufficient for correct invocation despite the absence of an output schema.

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 input schema already provides 100% coverage with detailed field descriptions for url, origin, and form_factor, including mutual exclusivity and canonical key guidance. The description adds minimal parameter-specific value beyond reinforcing these points; extra details like timing units and CLS unitless concern the output, not the parameters.

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 one-call Core Web Vitals assessment for an origin or URL over the latest 28-day window, clearly identifying the resource and scope. It further distinguishes itself from siblings by detailing the snapshot metrics (p75, ratings, densities) and pass/fail logic, which differs from trend or comparison tools.

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 provides clear operational context: exactly one of origin or url, when to fall back from url to origin, and optional form_factor usage. It does not explicitly name alternative sibling tools or state when not to use this tool, but the 28-day snapshot framing implies its use case, and the origin/url guidance is strong.

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?

Annotations already declare the tool safe (readOnly, idempotent, non-destructive). The description adds substantial behavioral detail: exactly 1 API request, 28-day rolling window semantics, ineligible week skipping, Monday data updates, and a {no_data: true} response payload. This is high-value context beyond what annotations provide.

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 dense but well-organized paragraph. It front-loads the core purpose, then packs essential details about response shape, defaults, data freshness, and constraints. No word is wasted; every clause earns its place.

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?

Given 5 optional parameters and no output schema, the description fully compensates by specifying the response structure ('points' array, 'delta' with direction), the no-data payload, update cycle, and per-parameter guidance embedded in the schema. The tool is complex, and the description makes it self-sufficient.

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%, with each parameter already fully described in the input schema (mutual exclusion, defaults, enum restrictions, formatting rules). The description mostly adds output interpretation ('lower is always better', 'ineligible weeks are skipped') rather than parameter-level meaning, so it does not raise above the high-coverage baseline.

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, action-oriented statement: 'Weekly p75 trend for an origin or URL from the CrUX History API (1 request).' This clearly names the resource (CrUX History API), the scope (origin or URL), and the granularity (weekly p75), which distinguishes it from siblings like get_core_web_vitals or compare_form_factors.

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 provides clear usage context: 'Provide exactly one of origin or url', fallback guidance for no_data, a note on update cadence, and parameter caps. It does not explicitly name alternative sibling tools or state 'use this instead of X', so it misses the top tier for alternative differentiation, but the context is strong.

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?

Annotations already declare read-only/idempotent behaviors. The description adds substantial context beyond annotations: update schedule (Mondays ~04:00 UTC), 28-day rolling windows, data structure (histogramTimeseries, percentilesTimeseries), null/NaN handling, and 404→{no_data:true}. No contradictions.

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?

Three dense sentences front-load the purpose. Every clause adds value: raw format, cadence, period count, data shape, edge cases, and sibling pointer. No filler or redundancy.

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?

This is a complex raw-timeseries tool with 5 parameters and no output schema. The description covers output structure, series alignment, non-numeric values, no-data response, and alternative tool, making it complete enough for correct selection and invocation.

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 baseline 3 applies. The description mentions 'origin or URL' and 'collection periods' but does not add parameter-specific semantics beyond the schema's already thorough descriptions.

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 uses a specific verb and resource: 'Returns the weekly CrUX timeseries for an origin or URL'. It clearly identifies the raw API nature and distinguishes from siblings by explicitly recommending get_cwv_trend for a cleaned p75 trend.

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?

An explicit alternative is provided: 'Prefer get_cwv_trend for a cleaned p75 trend', implying this tool for raw timeseries. It also gives practical usage caveats like no-data fallback to origin and update cadence, clarifying when to use.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes well beyond that by detailing the response structure (histogram bins, percentiles, fractions), data types (integer ms, string-encoded double for CLS), invariants (collectionPeriod always 28 days), normalization behavior, and the surprising '404 as {no_data:true}' convention. No contradiction with 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?

Seven sentences, each earning its place: purpose, response structure, type details, invariants, normalization, no-data handling, and alternative tool guidance. Front-loaded with the core purpose, no fluff or repetition, and logically organized.

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 compensate, and it does thoroughly: it covers the response object's shape (histogram, percentiles, fractions), field types, edge cases (urlNormalizationDetails, no_data), and usage context (origin vs URL, fallback). This is more than sufficient for an agent to invoke the tool and interpret results correctly.

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%—each parameter (url, origin, metrics, form_factor) already has detailed descriptions covering mutual exclusivity, redirect behavior, fragment stripping, and device-class caveats. The tool description itself adds no parameter-specific meaning, so the baseline of 3 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?

The description opens with a specific verb and resource ('Returns the latest 28-day rolling CrUX record'), clarifies it is the raw API response, and explicitly contrasts it with get_core_web_vitals ('ready-made assessment' vs 'full histograms/fractions'), making it clearly distinct from siblings.

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 directly names the alternative tool get_core_web_vitals and states when to prefer one over the other. It also adds practical guidance about no-data answers (404 as {no_data: true}) and the daily update cadence, helping agents decide when to use this tool and how to handle expected outcomes.

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