Which integrations are available for this server?

Provides tools for querying the Chrome UX Report API to retrieve real-user Core Web Vitals metrics (LCP, INP, CLS) for origins or URLs, view historical trends, and compare competitors.

How do I use crux-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@crux-mcp Compare Core Web Vitals for example.com vs competitor.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

crux-mcp

by miguelrisero

Overview Schema Related Servers Score Discussions

Python

Remote

crux-mcp

Python 3.10+ License: MIT PyPI MCP

An MCP server for the Chrome UX Report — real-user Core Web Vitals for any origin or URL, straight from the dataset Google uses for its page experience signal.

Lab tools like Lighthouse tell you how a page performed on the machine that ran the test. CrUX tells you how it performs for the people actually visiting it, as the p75 across 28 days of real Chrome traffic. When the two disagree, the field data is the one that counts.

> How are our Core Web Vitals doing on mobile?

  largest_contentful_paint   1642 ms   good
  interaction_to_next_paint   145 ms   good
  cumulative_layout_shift      0.01    good
  core_web_vitals_pass: true

Why this exists

CrUX is free and public, but awkward to reach from an agent:

It is API-key only. It rejects OAuth and service-account credentials with a bare 400 INVALID_ARGUMENT, so it cannot reuse the credentials your Search Console or GA4 servers already have. That failure mode gives no hint about the real cause.
The raw response is a nest of histogram buckets. You want "is LCP good", not histogram[0].density.
The history endpoint returns two parallel arrays that you have to zip yourself before anything can chart it.

This server handles all three, and tells you plainly when CrUX simply has no data for what you asked.

Related MCP server: Elevate Analytics MCP

Install

Requires Python 3.10+. No cloning needed — uvx runs it on demand.

Claude Code

claude mcp add crux --scope user -e CRUX_API_KEY=your_key_here -- uvx crux-mcp

Or keep the key out of your MCP config entirely by sourcing it from a shared secrets file at launch — worth doing if you already keep credentials in one place:

claude mcp add crux --scope user -- sh -c \
  'set -a; . "$HOME/.secrets/mcp-keys.env"; set +a; exec uvx crux-mcp'

Claude Desktop / Cursor / Windsurf

Add to your MCP config (claude_desktop_config.json, .cursor/mcp.json, …):

{
  "mcpServers": {
    "crux": {
      "command": "uvx",
      "args": ["crux-mcp"],
      "env": { "CRUX_API_KEY": "your_key_here" }
    }
  }
}

VS Code

code --add-mcp '{"name":"crux","command":"uvx","args":["crux-mcp"],"env":{"CRUX_API_KEY":"your_key_here"}}'

From a clone

git clone https://github.com/miguelrisero/crux-mcp && cd crux-mcp
pip install -e .
CRUX_API_KEY=your_key_here crux-mcp

Getting an API key

Two minutes, free, no billing account required.

Open the Google Cloud Console and pick or create a project.
APIs & Services → Library, search Chrome UX Report API, click Enable.
APIs & Services → Credentials → Create credentials → API key.
Copy the key into CRUX_API_KEY.

Restrict the key while you are there — Edit API key → API restrictions → Restrict key → Chrome UX Report API. An API key is a bearer credential: anyone holding it can spend your quota. Restricting it to this one read-only API means a leak is close to harmless.

Quota is generous (roughly 150 queries/minute) and CrUX is read-only public data, so there is nothing to bill and nothing to leak about your users.

Verify it works:

curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$CRUX_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"origin":"https://www.google.com","formFactor":"PHONE"}' | head -20

CrUX exposes public aggregate data, so it authenticates the caller rather than a user, and Google implements that with API keys only. Passing a service-account bearer token returns:

400  Request contains an invalid argument.

with no mention of authentication — the same error you get for a malformed body, which makes it easy to misdiagnose. If you see that 400 on a request you are sure is well-formed, you are almost certainly authenticating the wrong way.

Tools

Tool	What it answers
`crux_record`	How does this origin or page perform for real users right now?
`crux_history`	Is it getting better or worse? Up to 25 weekly points.
`crux_compare`	How do we stack up against competitors?

All three take form_factor: PHONE (default), DESKTOP, TABLET or ALL.

Every tool is annotated readOnlyHint, idempotentHint and openWorldHint, so clients that surface capability hints can show these as safe to call without confirmation.

`crux_record`

Pass either origin (whole site) or url (one page).

{
  "key": { "origin": "https://www.betterpic.io" },
  "collection_period": { "lastDate": { "year": 2026, "month": 8, "day": 10 } },
  "metrics": {
    "largest_contentful_paint": {
      "p75": 1642,
      "assessment": "good",
      "distribution": { "good": 0.81, "needs_improvement": 0.13, "poor": 0.06 }
    },
    "interaction_to_next_paint": { "p75": 145, "assessment": "good" },
    "cumulative_layout_shift": { "p75": "0.01", "assessment": "good" }
  },
  "core_web_vitals_pass": true
}

assessment uses the published thresholds. core_web_vitals_pass is true only when LCP, INP and CLS are all good. Pass raw=true for the untouched API response.

`crux_history`

Returns weekly p75s already zipped to their week-ending dates — drop straight into a chart or a Grafana series. Narrow to one metric with metric="largest_contentful_paint".

{
  "weeks": ["2026-07-27", "2026-08-03"],
  "metrics": {
    "largest_contentful_paint": [
      { "week_ending": "2026-07-27", "p75": 2600, "assessment": "needs-improvement" },
      { "week_ending": "2026-08-03", "p75": 2100, "assessment": "good" }
    ]
  }
}

`crux_compare`

origins: "https://www.betterpic.io,https://www.aragon.ai,https://www.headshotpro.com"

One row per origin with the three Core Web Vitals and a pass flag. Origins with no CrUX record are reported explicitly rather than dropped, so a missing competitor never silently looks like a win.

Metrics available

largest_contentful_paint, interaction_to_next_paint, cumulative_layout_shift, first_contentful_paint, experimental_time_to_first_byte, round_trip_time, and others Google adds over time. The first three are the Core Web Vitals that feed the page experience signal.

Known limits — read before trusting a blank result

CrUX only covers destinations with enough traffic. A URL with too few visitors has no record at all. This is the single most common surprise: your homepage will have URL-level data while most blog posts only roll up to the origin. When a url query comes back empty, retry with origin.
Data is a 28-day rolling p75, updated daily but always trailing. It will not show you the effect of a deploy you shipped this morning.
History is weekly and capped at 25 points, roughly six months.
ALL is not a form factor, it means "do not filter". The server translates it by omitting the field, which is what the API expects.

Try it without an MCP client

The MCP Inspector runs the server standalone and lets you call each tool by hand — the fastest way to confirm a key works:

CRUX_API_KEY=your_key npx @modelcontextprotocol/inspector uvx crux-mcp

Development

git clone https://github.com/miguelrisero/crux-mcp && cd crux-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

pytest          # no API key needed, the suite is offline
ruff check .

The client is deliberately dependency-free beyond mcp — plain urllib, no requests. Tests cover threshold boundaries, form-factor handling, string-vs-numeric p75 (CLS arrives as a string), and the summarisers, all without touching the network.

Who built this

Built at BetterPic while auditing our own Core Web Vitals. The CrUX API kept being the thing we wanted an agent to reach, and nothing exposed it.

Made by the team behind Patricia, which does this kind of SEO analysis as a product, and Runflow.

Licence

MIT — see LICENSE.

Available Tools

3 tools

crux_compareCrUX: compare originsA

Read-onlyIdempotent

Compare Core Web Vitals across several origins — yours against competitors.

origins is a comma-separated list, e.g. "https://www.betterpic.io,https://www.aragon.ai,https://www.headshotpro.com". Returns one row per origin with the three Core Web Vitals and whether it passes. Origins with no CrUX record are reported rather than dropped silently.

ParametersJSON Schema

Name	Required	Description	Default
`origins`	Yes
`form_factor`	No		PHONE

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the tool read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral details: returns one row per origin, includes pass/fail status, and reports origins without CrUX records rather than silently dropping them. This goes beyond annotation cues.

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

Conciseness5/5

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

The description is compact and well-structured: it opens with purpose, then explains input format, and closes with output behavior. Every sentence carries meaningful information without redundancy or fluff.

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

Completeness4/5

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

With an output schema present, the description need not explain return structure. It adequately covers purpose, input format, and edge-case handling for missing data. A brief mention of form_factor would improve completeness, but the current level suffices for a moderately simple comparison tool.

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

Parameters3/5

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

The description thoroughly explains the 'origins' parameter with a comma-separated format and a concrete example, which is critical since schema descriptions are absent. However, 'form_factor' is not documented in the description, and the schema only provides a default. Partial compensation for a 0% schema coverage.

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

Purpose5/5

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

The description clearly states the tool compares Core Web Vitals across multiple origins, using a specific verb ('compare') and resource ('Core Web Vitals'). This distinctly separates it from siblings like crux_record (single origin) and crux_history (time series).

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?

The phrase 'several origins — yours against competitors' implies the intended comparison use case. It does not explicitly name alternative tools or exclusion conditions, but the contrast with sibling tool names and the context of competitor benchmarking provide strong guidance.

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

crux_historyCrUX: weekly trendA

Read-onlyIdempotent

Weekly Core Web Vitals trend, up to 25 points, for charting or regression checks.

Same origin / url / form_factor rules as crux_record. Pass metric to return just one series, e.g. largest_contentful_paint, interaction_to_next_paint, cumulative_layout_shift, first_contentful_paint, experimental_time_to_first_byte.

ParametersJSON Schema

Name	Required	Default
`url`	No
`metric`	No
`origin`	No
`form_factor`	No	PHONE

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds useful behavioral details: a maximum of 25 data points, weekly granularity, and that passing a metric returns a single series. This enriches the agent's understanding 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.

Conciseness5/5

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

The description is compact and front-loaded, with the core purpose in the first sentence and additional parameter details in the second. Every sentence earns its place, with no redundant or extraneous information.

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

Completeness4/5

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

Given the presence of an output schema and standard parameters, the description covers the essential aspects: what the tool returns (trend over time), key constraints (25 points), and how to filter by metric. It relies on the 'same rules as crux_record' reference, which is a minor gap but acceptable given sibling tool availability.

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

Parameters3/5

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. It thoroughly explains the 'metric' parameter with concrete examples, but only references 'same rules as crux_record' for url/origin/form_factor, requiring the agent to consult a sibling tool for full semantics. This is helpful but not fully self-contained.

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

Purpose5/5

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

The description clearly states the tool's function: 'Weekly Core Web Vitals trend, up to 25 points, for charting or regression checks.' It uses a specific verb (trend) and resource (Core Web Vitals), and distinguishes itself from siblings by focusing on history/trend rather than single records or comparisons.

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?

The description provides clear context for when to use the tool ('for charting or regression checks') and notes the same filtering rules as crux_record. However, it does not explicitly indicate when NOT to use it or directly compare with crux_compare, leaving some room for interpretation.

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

crux_recordCrUX: current Core Web VitalsA

Read-onlyIdempotent

Current p75 Core Web Vitals for an origin or a single URL.

Pass EITHER origin (e.g. https://www.betterpic.io — covers the whole site) OR url (one page). form_factor is PHONE, DESKTOP, TABLET or ALL. Returns each metric's p75 with a good / needs-improvement / poor assessment, plus an overall core_web_vitals_pass. Set raw=true for the untouched API response.

ParametersJSON Schema

Name	Required	Default
`raw`	No
`url`	No
`origin`	No
`form_factor`	No	PHONE

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about the return format (p75 with assessments, core_web_vitals_pass) and the raw=true option, which are not stated in the schema. No contradictions found.

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

Conciseness5/5

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

The description is two compact paragraphs with a clear opening statement followed by necessary parameter and output details. Every sentence adds value, with no filler or repetition, and it is appropriately front-loaded.

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?

Given the 4 optional parameters and existing output schema, the description covers all key aspects: how to specify origin vs url, form_factor options, raw flag, and what the response contains. It is sufficient for correct invocation without additional external documentation.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining all four parameters: origin/url mutual exclusivity, form_factor allowed values, and raw behavior. It adds meaning beyond the schema's type/default details.

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

Purpose5/5

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

The description clearly states the tool returns 'Current p75 Core Web Vitals for an origin or a single URL' with a specific resource (CrUX data) and scope (origin or URL). It distinguishes itself from siblings via 'current' and explicit mention of the metrics and pass/fail assessment.

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

Usage Guidelines3/5

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

The description gives clear guidance on parameter usage ('Pass EITHER origin OR url') and form_factor values, but does not explicitly mention when to use this tool versus alternatives like crux_history or crux_compare. Usage context is implied ('current') but not contrasted with siblings.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct use case: crux_record for current snapshot, crux_history for trends, crux_compare for multi-origin comparison. No overlap in purpose or output.

Naming Consistency5/5

All tools share the crux_ prefix followed by a clear descriptive word (record, history, compare). The naming pattern is consistent and predictable.

Tool Count5/5

With only three tools, the server is tightly scoped to Core Web Vitals data retrieval. Each tool covers a distinct need and none feel redundant or extraneous.

Completeness5/5

The server provides the essential CrUX operations: current performance, historical trend, and cross-origin comparison. No obvious gaps exist for its stated purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

State of Web Vitals A
io.github.corewebvitals
Core Web Vitals metrics by CMS, CDN, and framework — free remote MCP, no auth.
Monitoring Observability
32
coredash
io.github.corewebvitals
Real User Monitoring for Core Web Vitals. Query LCP, INP, CLS field data from real visitors.
Monitoring Observability
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3

Related MCP Servers

PageSpeed Insights MCP Server
Developer Tools Monitoring Observability
ruslanlap
A
license
A
quality
A
maintenance
16-tool MCP server for Google PageSpeed Insights & Chrome UX Report APIs. Analyze, compare, and optimize web performance directly through Claude, Cursor, or any MCP-compatible AI client.
Updated 2 days ago (2026-08-31 18:01 UTC)
6
56
Apache 2.0
Elevate Analytics MCP
Marketing Search Monitoring
sunilshrestha1982
F
license
Not graded
quality
C
maintenance
Production-ready MCP server integrating Google Search Console, GA4, and PageSpeed Insights for SEO and analytics intelligence, enabling natural-language queries to Google analytics data.
Updated a month ago (2026-07-21 09:36 UTC)
page-speed-insights-mcp
Sivakumar-intoaec
F
license
Not graded
quality
C
maintenance
An MCP server that wraps the Google PageSpeed Insights API to analyse web performance, providing tools for scores, Core Web Vitals, opportunities, diagnostics, and batch analysis.
Updated a month ago (2026-07-24 07:23 UTC)
GSC MCP Server
Search Monitoring
wyattxmgmt
A
license
A
quality
C
maintenance
MCP server for Google Search Console, enabling chat-based queries about search performance, sitemaps, and URL indexing status via natural language.
Updated a month ago (2026-08-07 04:09 UTC)
7
132
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/miguelrisero/crux-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server