We Built a CrUX MCP Server — Real Core Web Vitals Field Data, Directly in Claude Code

01The PSI Paradox

Every SEO team knows the situation: PageSpeed Insights shows 94 on Mobile — all green. Two weeks later, Search Console flags a Core Web Vitals warning for the same page.

No bug. No error. That’s the difference between lab data and field data.

PageSpeed Insights is indispensable for diagnosis and optimisation — but it is not what Google uses for its ranking algorithm. For that, you need CrUX.

02What CrUX Actually Measures

CrUX (Chrome User Experience Report) is Google’s collection of field data from real Chrome users (Real-User Monitoring, RUM) — aggregated over 28 days — used to assess Core Web Vitals at URL or origin level. Users who have opted into performance reporting contribute automatically, without any personally identifiable data being collected.

Three properties make CrUX relevant for SEO:

• 28-day rolling window. The current dataset always covers the last 28 days. No cut-off date, no monthly report — rolling, continuous.
• p75 — not the average. Google assesses the 75th percentile, not the median: 75% of users experience this metric at least as well, 25% experience it worse. Ignoring that bottom quartile produces false-positive assessments.
• Form factor split. CrUX can be queried separately for Mobile, Desktop, and Tablet. The aggregated “ALL” view often hides completely different problems for mobile and desktop users.

The five CrUX metrics:

LCP, CLS, and INP are the three Core Web Vitals — all three must be “good” for an origin to pass CWV.

03The Stack

The MCP server is written in Python, runs locally, and is wired into Claude Code. The core framework is FastMCP — the same foundation as our Keyword and GSC servers.

A typical call:

seo_crux_query("https://example.com", form_factor="PHONE")

Returns: p75 values for all available metrics, good/NI/poor rating, histogram buckets (share of users in each bucket), and a cwv_pass flag. If the origin lacks sufficient traffic, the API returns 404 — the most honest answer CrUX can give.

04Two Brands, One Pattern

Two eCommerce brands, both mobile-heavy. Both failing CWV. And both with completely different problems — depending on the device.

Brand A (Snapshot · 2026-05-30 → 2026-06-26)

The aggregated “ALL” shows LCP at 2,891 ms — Needs Improvement. Unremarkable. Only the form factor split reveals: mobile fails on LCP, desktop fails on CLS — two different root causes, two different optimisation tracks.

Brand B (Snapshot · 2026-05-30 → 2026-06-26)

Brand B is significantly more critical: LCP, INP, and TTFB are Poor on Mobile. Desktop fails on CLS at 0.39. A TTFB of over 3 seconds on Mobile points to a fundamental server speed or CDN issue — all other metrics suffer as a consequence.

05The History Behind the Numbers

A snapshot shows the current state. CrUX history shows why the current state exists.

Brand A — Recovery with Silent Regression

Between December and April, LCP improved by 33% — from Poor to nearly Good. Since April the value has been drifting back with no visible triggering event. The classic silent regression: no deployment, no obvious change — but something shifted.

Brand B — No Recovery in Sight

Brand B was still in the NI range in December — 25 weeks later LCP is Poor and getting worse. The TTFB history shows the same pattern: from 2,259 ms in December to 3,052 ms in May. No corrective action visible.

06What Google Actually Measures for Ranking

The CWV report in Google Search Console is not an approximation of CrUX data — it is CrUX data. Core Web Vitals aren’t the only ranking factor. But they are a measurable part of Page Experience — and the only one Google backs with real user data.

Three practical implications:

• The 28-day lag is real. An optimisation that goes live today takes 28 days to be fully visible in the CrUX window. A PSI improvement is measurable immediately; a CWV improvement in Search Console only appears fully after a month.
• CWV is binary. Either all three metrics (LCP, CLS, INP) are “good” — or the origin fails. NI on one metric = fail. There is no “close enough”.
• Form factor matters. Google’s mobile-first indexing means mobile CrUX data carries the most weight. Brand A and Brand B fail primarily because of their mobile scores — even where desktop partially fares better.

07In Client Work

The CrUX server is the ninth module in our MCP stack. When it comes before PSI, when PSI comes first:

1. Search Console flags a CWV warning → CrUX first: what does Google see right now? Which metric, which device?
2. Split CrUX by form factor → Query mobile and desktop separately. The aggregated view isn’t wrong, it just hides the detail.
3. Query CrUX history → When did this problem develop? Was it a deployment event or a silent regression?
4. PSI for root cause analysis → What exactly is causing the LCP problem? Which element? Which resource type? PSI answers this instantly; CrUX doesn’t.
5. Deploy the fix, verify via PSI → Immediate lab-based feedback.
6. Wait 28 days, re-query CrUX → Has the ranking signal improved?

The module set

08Why It Matters