Google CrUX MCP

io.github.A1-x-TechPublished by GitHub account A1-x-Techv1.2.1Updated Nov 1, 2026

Real-user Core Web Vitals from the Chrome UX Report (CrUX) API for any origin or URL.

VerifiedSTDIODesktop onlyWeb Search & ScrapingData & Analytics

Overview

AI-generated overview

Read-only MCP server that pulls real-user Core Web Vitals from Google's Chrome UX Report (CrUX) API for any public origin or URL.

What you can do
  • Assess Core Web Vitals (LCP, INP, CLS plus FCP and TTFB) with p75 values and good/needs-improvement/poor ratings for an origin or URL
  • Compare device classes (phone, desktop, tablet, all devices) including each device's traffic share
  • Compare a single page against the site-wide origin average
  • Show weekly p75 trends from the CrUX History API, with deltas and direction
  • Return raw latest or historical CrUX records with histograms, percentiles and density fractions
When to use it
Useful when you want an assistant to check whether a public site or page passes Core Web Vitals on real Chrome user data, compare mobile versus desktop, see whether a page is slower than its site average, or review performance trends over recent weeks.
Requirements
Runs locally over stdio via npx, so Node.js 20+ is needed. Requires a Google Cloud API key with the Chrome UX Report API enabled, passed as CRUX_API_KEY; no billing account is needed. Optional CRUX_API_BASE, CRUX_TIMEOUT_MS and CRUX_MAX_RETRIES settings. Network access to the CrUX API.
Before you install
CRUX_API_KEY is stored in the client configuration and sent in the request URL, so treat it as a password and restrict it to the Chrome UX Report API. The server sends anonymous telemetry (install and version data, tool names, call outcomes, and on failure a redacted error excerpt); set ASKADS_TELEMETRY=0 to opt out. Data is read-only and cannot change sites or rankings. Quota is 150 requests per minute per project, and compound comparisons spend several units.

Installation

In SourceWeft

  1. Open Google CrUX MCP in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[A1] Google CrUX MCP

English | Русский

[npm] [Glama] [CI] [License: MIT]

A1 Google CrUX MCP brings real-user Core Web Vitals data into an AI app. Check whether a public site or page passes LCP, INP and CLS, compare mobile with desktop, and see how the metrics changed over time.

It reads Google’s Chrome UX Report dataset — field data collected from Chrome users, not a synthetic speed test or a way to change your site.

  • 6 read-only tools. Core Web Vitals assessment, device comparison, origin-versus-page comparison, 40-week trend and raw latest or historical records.
  • Real-user data. It is the same CrUX field data used by PageSpeed Insights and Google’s Core Web Vitals signals.
  • Clear availability boundary. Only public origins and URLs with enough real-user traffic have data; no_data is a valid result.
  • Known quota cost. CrUX allows 150 queries per minute per project. Device comparison makes four API calls; origin-versus-page makes two.

Start with a read-only question:

Does https://example.com pass Core Web Vitals on mobile?

Connect the server · Explore use cases · Open technical documentation

See it work in a minute

You: Does https://example.com/pricing pass Core Web Vitals on mobile?

Assistant: Shows p75 LCP, INP and CLS, their good/needs-improvement/poor ratings and the overall result. Nothing changes.

You: Compare this page with the site average and show how mobile differs from desktop.

Assistant: Compares the origin and URL, then device groups and their traffic shares. All six tools read the public CrUX dataset only.

Contents

Quick start

You need Node.js 20+ and a Google Cloud API key with Chrome UX Report API enabled.

  1. Create a restricted API key.
  2. Add the server to your AI app.
  3. Ask the read-only question above.
Codex

In Settings → MCP servers, select Add server, choose STDIO, enter the command npx -y mcp-google-crux@latest and environment variables CRUX_API_KEY, then select Save and Restart.

bash
codex mcp add google-crux --env CRUX_API_KEY=your_key -- npx -y mcp-google-crux@latestcodex mcp list

Codex MCP documentation

Claude Code
bash
claude mcp add --env CRUX_API_KEY=your_key --transport stdio --scope user google-crux -- npx -y mcp-google-crux@latestclaude mcp list

Claude Code MCP documentation

Claude Desktop

The current official path is Settings → Extensions. For a custom desktop extension, open Advanced settings → Extension Developer → Install Extension…, select a .mcpb file and follow the prompts.

This repository currently publishes an npm stdio package and does not contain a .mcpb bundle. For Claude Desktop builds that still support local configuration, use the following JSON stdio configuration as a fallback:

{"mcpServers":{"google-crux":{"command":"npx","args":["-y","mcp-google-crux@latest"],"env":{"CRUX_API_KEY":"your_key"}}}}

In those builds, save it to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows.

Claude Desktop MCP documentation

Cursor

Add {"mcpServers":{"google-crux":{"type":"stdio","command":"npx","args":["-y","mcp-google-crux@latest"],"env":{"CRUX_API_KEY":"your_key"}}}} to ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows. Cursor MCP documentation

VS Code

Run MCP: Open User Configuration and add:

json
{"servers":{"google-crux":{"type":"stdio","command":"npx","args":["-y","mcp-google-crux@latest"],"env":{"CRUX_API_KEY":"${input:crux_api_key}"}}},"inputs":[{"type":"promptString","id":"crux_api_key","description":"Google Cloud API key","password":true}]}

Check it with MCP: List Servers. VS Code MCP documentation

What you can ask it to do

  • Does this public origin or URL pass Core Web Vitals?
  • Compare phone, desktop, tablet and all-device results.
  • Is this page faster or slower than the site average?
  • How did LCP, INP and CLS change during the last 25 weeks?
  • Show the raw CrUX histograms and percentiles for a technical review.

How to read CrUX data

CrUX reports a rolling 28-day window, updated daily. Historical data is weekly and updates on Mondays. The key value is p75: 75% of observed visits are at or below it. get_core_web_vitals interprets metric thresholds for you; raw record tools expose full histograms and density fractions.

No data does not mean the site is broken. It means Google has no sufficiently large public Chrome-user sample for that origin, URL or device group. Tablets and individual URLs often have no data.

Getting access

  1. In Google Cloud Console, create or select a project; no billing account is needed for CrUX.
  2. Enable the Chrome UX Report API.
  3. Create an API key in APIs & Services → Credentials.
  4. Restrict the key to Chrome UX Report API and pass it as CRUX_API_KEY.

The key is stored in the MCP client configuration and is sent in the API request URL, so treat it as a password.

Configuration

VariableRequiredDescription
CRUX_API_KEYYesGoogle Cloud key with Chrome UX Report API enabled.
CRUX_API_BASENoAPI base URL override.
CRUX_TIMEOUT_MSNoPer-request timeout; default 30000 ms.
CRUX_MAX_RETRIESNoRetries for 429, 5xx and network failures; default 3.

Data, limits and background work

  • Read-only public dataset. The server cannot alter sites, Search Console, CrUX records or Google rankings.
  • Quota-aware retries. It retries 429, 5xx and network errors with backoff. Keep compound comparisons in mind when budgeting the 150 queries per minute project quota.
  • No background monitoring. The server works only while called. If your AI app supports scheduled tasks, it can create a recurring performance report.
  • Anonymous telemetry. It sends installation and version data plus tool names, never API keys, queried URLs, results, arguments or prompts. For each tool call it also sends the outcome and, on failure, an excerpt of the error text with e-mails, addresses, tokens, numbers of 4+ digits and quoted text replaced by #; a value from your request can appear in it if the error text contains it. Set ASKADS_TELEMETRY=0 to opt out.

Technical documentation

Support

Found a bug or need a scenario? Create an issue or write in Telegram.


[Две Моны дают пять]

You made it to the end!

Source: README.md at commit cd4ade6

Tools

6

get_core_web_vitals

Core Web Vitals assessment

One-call Core Web Vitals assessment for an origin or URL over the latest 28-day window. Per metric (LCP, INP, CLS + diagnostic FCP and TTFB): p75, rating (good | needs-improvement | poor, web.dev thresholds: LCP ≤2500ms/>4000ms, INP ≤200ms/>500ms, CLS ≤0.10/>0.25) and the good/needs_improvement/poor user-experience densities (~sum 1.0). `passes_core_web_vitals` is true when all three CWV rate good. Timings are ms; CLS is unitless. Returns {no_data: true} when the origin/URL has insufficient traffic in CrUX. Provide exactly one of `origin` or `url`.

Parametersurloriginform_factor

compare_form_factors

Phone vs desktop vs tablet

Compares real-user performance across device classes for an origin or URL: one aggregated all-devices record plus phone, desktop and tablet records (4 API requests = 4 quota units of the 150/min budget). Per device: p75 + rating per metric; `traffic_share` gives each device's fraction of page loads (from the unfiltered form_factors metric). Devices without enough data come back as {no_data: true} — expected for tablet almost always. Default metrics: the three Core Web Vitals. Provide exactly one of `origin` or `url`.

Parametersurloriginmetrics

compare_origin_vs_url

Origin vs specific page

Compares the site-wide origin record against one specific page (2 API requests): p75 + rating per metric for each, so you can tell whether a page is faster or slower than the site average. Either side can come back {no_data: true} (single pages often lack data; redirecting homepages can lack origin data while pages have it). Default metrics: the three Core Web Vitals. Both `origin` AND `url` are required here (unlike the other tools).

Parametersurlrequiredoriginrequiredmetricsform_factor

get_cwv_trend

Core Web Vitals trend

Weekly p75 trend for an origin or URL from the CrUX History API (1 request). Per metric: `points` — array of {period_end, p75, rating}, one per week (each week is a 28-day rolling window ending on period_end; ineligible weeks are skipped), and `delta` — first vs last p75 with direction improved | regressed | stable (lower is always better). Default metrics: the three Core Web Vitals; `weeks` caps the history depth (1..40, default 25). History data updates on Mondays. Returns {no_data: true} when CrUX has no data. Provide exactly one of `origin` or `url`.

Parametersurlweeksoriginmetricsform_factor

query_record

Latest CrUX record (raw)

Returns the latest 28-day rolling CrUX record for an origin or URL (raw API response, updated daily ~04:00 UTC). Per metric: `histogram` (3 bins good/needs-improvement/poor with `density`), `percentiles.p75`, and for enum metrics `fractions`. Timings are integer ms; cumulative_layout_shift p75 is a string-encoded double (e.g. "0.05"). `collectionPeriod` always spans 28 days. `urlNormalizationDetails` appears if the URL was normalized (e.g. fragment stripped). A no-data answer (HTTP 404) is returned as {no_data: true} — not an error. Prefer get_core_web_vitals for a ready-made assessment; use this for full histograms/fractions.

Parametersurloriginmetricsform_factor

query_history_record

CrUX weekly timeseries (raw)

Returns the weekly CrUX timeseries for an origin or URL (raw API response, updated Mondays ~04:00 UTC): up to 40 collection periods, each a 28-day rolling window. Per metric: `histogramTimeseries` (bins with `densities` arrays), `percentilesTimeseries.p75s` and `fractionTimeseries`; all series align with `record.collectionPeriods`. Ineligible periods appear as null p75s and "NaN" densities — tolerate non-numeric entries. A no-data answer (HTTP 404) is returned as {no_data: true}. Prefer get_cwv_trend for a cleaned p75 trend.

Parametersurloriginmetricsform_factorcollection_period_count

Version history

3
  1. v1.2.1LatestOct 31, 2026
  2. v1.2.0Oct 31, 2026
  3. v1.1.0Sep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts