Skip to main content
Glama

Quattr

site_health_cwv_check

Read-only

Check Core Web Vitals health: per-vital grades (good / needs-improvement / poor), distributions across pages, and the worst LCP pages for a date range. Uses QWA Growth Trends defaults (Web + google/organic) for UI-parity. Snapshot mode selects QWA's latest fully populated daily Performance, Accessibility, Best Practices, and SEO headline; trend mode uses QWA's authoritative day/week/month/quarter bucket aggregates and, with include_lighthouse_scores, returns those Lighthouse diagnostics in every bucket. Never construct a Lighthouse trend by stitching snapshot calls because snapshot headline aggregation is not the QWA period-bucket calculation. Supports an exact page filter, a page-path contains filter such as /blog/, and an exact QWA content-category filter without first enumerating every page. LCP and INP use the same seconds-based values shown by QWA; CLS is unitless. Lighthouse score fields remain raw 0–1 values in the analytics payload; metricSemantics gives the required QWA presentation rule: multiply by 100, round to a whole score point, and do not append %. Every successful response includes dataCoverage, explicit pagePopulation semantics, and aggregationMetadata that forbids unsupported weighting or representativeness inferences. For QWA page-total comparisons, use pagePopulation.qwaDisplayedPages (the period union when comparison_range is present), not the backward-compatible selected-row pageCount. Use for "any Core Web Vitals regressions?" or page-speed questions. Optionally split mobile vs desktop, surface the broader Lighthouse scores (SEO / accessibility / best-practices), compare to a prior period, or return a per-page scorecard.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date_range": "<date_range>"
    },
    "name": "site_health_cwv_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNo"site" for the rollup only; "pages" to include the weakest pagespages
deviceNoRestrict to one device (mobile / desktop).
sourceNoWhere Google search performance data is read from. Use "bigquery" ONLY when the user explicitly asks for BigQuery as the source AND describe_data_sources reports it available from live customer configuration — it returns far more granular per-query data (privacy-suppressed impressions appear under "[anonymized by google]").default
categoryNoExact QWA content-category label. Applied inside every analytics query leg. This is category equality, not a page-path match.
date_rangeYesExplicit date range, e.g. "2026-05-01 to 2026-05-31". Both endpoints are INCLUSIVE — the END day is covered (a 7-day range = 7 days). Quattr weeks run Sunday–Saturday; for "last week" use the most recent complete Sun–Sat span.
granularityNoReturn a native QWA TIME SERIES bucketed by day / week / month / quarter — per-bucket RAW metric aggregates (LCP/INP seconds, CLS unitless, Lighthouse scores 0–1), NOT graded into good/needs-improvement/poor. Present score fields as QWA whole score points (value × 100, rounded, without %), as specified by metricSemantics. Set include_lighthouse_scores=true for monthly SEO/accessibility/best-practices and the other Lighthouse diagnostics. Mutually exclusive with comparison_range (and skips the worst-pages / grading logic).
page_filterNoOptional page scope. Applied inside every analytics query leg; do not enumerate all pages and filter client-side.
date_range_modeNoREQUIRED when granularity is set. Use "calendar" for YTD or another explicit calendar period: keep the requested start and return only complete buckets inside it. Use "rolling" for "last N days/weeks/months/quarters": preserve N complete buckets by shifting the full window backward when needed.
split_by_deviceNoAlso return a per-device breakdown (mobile vs desktop), each separately scored.
comparison_rangeNoA prior date range — returns per-vital deltas vs the selected range (period-over-period).
include_scorecardNoReturn the per-page CWV scorecard (all 4 vitals per returned page), not just the weakest pages. pageEvidence reports whether the full page population fit within the governed result limit.
include_lighthouse_scoresNoAlso surface 8 ungraded Lighthouse diagnostics: raw 0–1 SEO, accessibility, best-practices, and mobile scores plus TTI, TBT, FCP, and Speed Index timing averages in seconds. Present score fields as QWA whole score points (value × 100, rounded, without %), as specified by metricSemantics. With granularity, adds all 8 values to every native trend bucket; do not synthesize a trend from repeated snapshot calls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), but the description adds substantial behavioral context: snapshot vs trend aggregation semantics, the metricSemantics presentation rule, pagePopulation.qwaDisplayedPages vs pageCount, dataCoverage/aggregationMetadata guarantees, and the no client-side filtering constraint. This goes well beyond what the structured fields disclose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the key warning about not stitching snapshots. It is long and dense for a single description, but nearly every sentence carries mode-specific or semantic guidance that an agent needs for a 12-parameter tool, so the length is largely earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 12-parameter tool with no output schema, the description fills all critical gaps: output semantics (dataCoverage, pagePopulation, aggregationMetadata), presentation rules, and mode behavior. An agent has enough to call it correctly without opening additional docs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real cross-parameter meaning: units (LCP/INP in seconds, CLS unitless), mutual exclusivity of granularity and comparison_range, and the snapshot-vs-trend selection logic. It slightly exceeds the schema rather than merely restating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Check Core Web Vitals health' with concrete outputs (per-vital grades, distributions, worst LCP pages for a date range). The scope (QWA Growth Trends defaults, mobile/desktop split, trend vs snapshot) is clear, but it never names or contrasts the close siblings cwv_breakdown or page_traffic_cwv, leaving the agent to infer when this is preferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage cues ('Use for "any Core Web Vitals regressions?" or page-speed questions') and useful prohibitions ('Never construct a Lighthouse trend by stitching snapshot calls'). However, it provides no explicit routing against sibling tools such as cwv_breakdown or page_traffic_cwv, so alternative selection is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources