Which integrations are available for this server?

Integrates with Google PageSpeed Insights API to analyze web page performance, providing performance scores, lab metrics (FCP, LCP, Speed Index, TBT, CLS, TTI, TTFB), high-impact audits, and compact diagnostics for render-blocking resources, unused JS/CSS, image optimization, and main-thread work, along with actionable recommendations.

How do I use web-performance-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., "@web-performance-mcp Analyze the performance of https://example.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.

web-performance-mcp

by teles

Overview Schema Related Servers Score Discussions

TypeScript

Remote

web-performance-mcp

MCP server for compact web performance analysis with the official Google APIs:

PageSpeed Insights API v5
Chrome UX Report API

It does not run Lighthouse locally and does not use Puppeteer, Playwright, Chrome DevTools Protocol, or a local browser.

Quick Start With npx

After the package is published to npm:

npx -y web-performance-mcp

The server reads GOOGLE_API_KEY from the environment. It also loads a .env file from the current working directory, so MCP clients can keep secrets in the project they are analyzing.

Create .env in your project:

GOOGLE_API_KEY=your-google-api-key-here

Related MCP server: MCP Server Pagespeed

Codex MCP Configuration

Use npx directly:

[mcp_servers.webPerformance]
command = "npx"
args = ["-y", "web-performance-mcp"]
cwd = "/path/to/project-with-env"
startup_timeout_sec = 30
tool_timeout_sec = 180

cwd should point to the project that contains .env.

You can also pass the key through MCP env config:

[mcp_servers.webPerformance.env]
GOOGLE_API_KEY = "your-google-api-key-here"

Prefer .env or shell environment variables for local use so secrets do not end up in shared config.

Required Google APIs

Create a Google Cloud API key and enable:

PageSpeed Insights API
Chrome UX Report API

Restrict the API key to only these APIs.

Tools

`analyze_pagespeed`

Analyze one URL with PageSpeed Insights.

{
  "url": "https://www.example.com/",
  "strategy": "mobile",
  "categories": ["performance"]
}

Returns:

performance score;
lab metrics: FCP, LCP, Speed Index, TBT, CLS, TTI, TTFB;
high-impact audits;
compact diagnostics for render-blocking resources, unused JS/CSS, image optimization, and main-thread work;
recommendations.

`analyze_pagespeed_batch`

Analyze up to 10 URLs with concurrency control.

{
  "urls": [
    "https://www.example.com/",
    "https://www.example.com/blog/"
  ],
  "strategy": "mobile",
  "categories": ["performance"],
  "concurrency": 2
}

`get_crux_url`

Query Chrome UX Report data for a URL.

{
  "url": "https://www.example.com/"
}

Returns LCP, INP, CLS p75 and good/needs improvement/poor distributions when CrUX has enough real-user data.

`get_crux_origin`

Query Chrome UX Report data for an origin.

{
  "origin": "https://www.example.com"
}

`compare_web_performance`

Combine PageSpeed and CrUX for several URLs and prioritize likely problems.

{
  "urls": [
    "https://www.example.com/",
    "https://www.example.com/blog/"
  ],
  "strategy": "mobile",
  "categories": ["performance"],
  "concurrency": 2
}

Response Shape

Responses are intentionally compact. The server does not send the raw PageSpeed or CrUX API payload back to the model.

CrUX tools return available: false when Google has no field data for the URL or origin.

API errors are returned as compact MCP errors for timeout, quota, permissions, invalid URLs, and incomplete API responses.

Local Development

corepack enable
pnpm install
cp .env.example .env
pnpm build
pnpm test
pnpm start

Use the local checkout in Codex:

[mcp_servers.webPerformance]
command = "node"
args = ["/Users/teles/dev/web-performance-mcp/dist/index.js"]
cwd = "/path/to/project-with-env"
startup_timeout_sec = 30
tool_timeout_sec = 180

Publishing to npm

The npm package name is:

web-performance-mcp

The name is currently available if npm view web-performance-mcp returns 404 Not Found. During npm publish, however, a 404 Not Found usually means the workflow cannot create or access that package name with the current npm authentication.

One-Time npm Setup

Create or log in to your npm account.
Publish the package once with an npm account that can create unscoped public packages, or configure npm Trusted Publishing for the GitHub repository before the automated release runs.
For Trusted Publishing, configure this package on npmjs.com with:

Provider: GitHub Actions
Organization or user: teles
Repository: web-performance-mcp
Workflow filename: release.yml
Allowed action: npm publish

Keep the GitHub Actions workflow permissions:

permissions:
  contents: write
  id-token: write

Trusted Publishing requires npm CLI 11.5.1+ and Node.js 22.14.0+. The release workflow uses Node 24.

If the release workflow fails while publishing with npm error 404 Not Found - PUT https://registry.npmjs.org/web-performance-mcp, confirm that the package exists under your npm account or that Trusted Publishing is configured for exactly teles/web-performance-mcp and workflow filename release.yml.

Release Flow

This repository uses zero-release.

Commits should follow Conventional Commits:

feat: add new tool
fix: handle CrUX permission errors
docs: improve npx setup

Preview the next release locally:

pnpm release:dry-run

Check release readiness:

pnpm release:doctor

Push to main to publish:

git push origin main

The workflow runs tests, builds the package, updates CHANGELOG.md and package.json, creates a GitHub release, and publishes to npm with the npm plugin.

Manual Publish Fallback

If you do not want to use Trusted Publishing yet:

corepack enable
pnpm install --frozen-lockfile
pnpm test
pnpm build
npm login
npm publish --access public

Use zero-release for normal releases once npm Trusted Publishing is configured.

Security

Never commit .env or real credentials.
Restrict GOOGLE_API_KEY to PageSpeed Insights API and Chrome UX Report API.
The API key is never printed by the server.
The server does not execute browser automation.

License

MIT

Available Tools

5 tools

analyze_pagespeedC

Analisa uma URL com PageSpeed Insights API v5 e retorna scores, metricas de laboratorio, auditorias de maior impacto e recomendacoes compactas.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL http/https a analisar.
`strategy`	No		mobile
`categories`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, and description lacks behavioral traits such as authentication, rate limits, or read-only nature. Only states outputs, not side effects or prerequisites.

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?

Single sentence conveying purpose and outputs efficiently. Front-loaded with key action, though could benefit from bullet points for readability.

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

Completeness2/5

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

No output schema exists, yet description omits response structure or example. For a tool returning complex data, this leaves ambiguity.

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

Parameters2/5

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

Schema description coverage is 33% (only url described). Description does not elaborate on parameters like strategy or categories beyond the schema enums and defaults, missing chance to add value.

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?

Description clearly states it analyzes a URL with PageSpeed Insights API v5 and returns specific outputs (scores, lab metrics, audits, recommendations). While it differentiates from siblings like analyze_pagespeed_batch by being single-URL, it does not explicitly contrast.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. With sibling tools like batch and comparison, explicit usage context would help.

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

analyze_pagespeed_batchC

Analisa ate 10 URLs com PageSpeed Insights API v5, com limite de concorrencia, e retorna uma comparacao compacta.

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes	Lista de ate 10 URLs http/https.
`strategy`	No		mobile
`categories`	No
`concurrency`	No	Numero maximo de URLs consultadas em paralelo.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must disclose all behavioral traits. It mentions concurrency limits and API version, but fails to mention authentication requirements, rate limits, error handling, or any side effects. The return format is only vaguely described as 'compact comparison'.

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

Conciseness3/5

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

The description is a single sentence in Portuguese, which is concise but lacks structure. It front-loads the key purpose but omits important details. It could be more informative without becoming overly verbose.

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

Completeness2/5

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

Given the tool's complexity (batch API calls, concurrency, multiple parameters, no output schema), the description is insufficient. It does not explain the return format, result handling, or how it differs from related tools. An agent would lack critical context for correct usage.

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

Parameters2/5

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

Schema description coverage is 50% (urls and concurrency have descriptions), but the description adds no extra meaning beyond the schema. The strategy and categories parameters, which lack schema descriptions, are not elaborated in the description. Thus the description does not compensate for the coverage gap.

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 analyzes up to 10 URLs using the PageSpeed Insights API v5 with concurrency limits and returns a compact comparison. It effectively distinguishes from siblings like analyze_pagespeed (likely single URL) and compare_web_performance by specifying the batch capability.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus the sibling tools. The description does not explicitly state that it is for batch analysis or that analyze_pagespeed is for single URL. An agent would have to infer from the name, which is unreliable.

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

compare_web_performanceB

Compara varias URLs combinando PageSpeed Insights e CrUX, priorizando os maiores problemas de Core Web Vitals e laboratorio.

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes	Lista de ate 10 URLs http/https.
`strategy`	No		mobile
`categories`	No
`concurrency`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It mentions combining PSI and CrUX and prioritizing problems, but does not disclose whether it is read-only, authentication needs, rate limits, or other behavioral traits.

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?

The description is a single sentence that front-loads the main action ('Compares multiple URLs'). It is efficient but could be slightly more structured.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, the combination logic, or the meaning of 'prioritizing biggest problems,' leaving agents underinformed.

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

Parameters2/5

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

Schema description coverage is 25% (only 'urls' has a description). The tool description does not add meaning to individual parameters, only hinting at the combination of PSI and CrUX. It fails to compensate for the low 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 it compares multiple URLs using PageSpeed Insights and CrUX, focusing on Core Web Vitals and lab issues. This verb+resource combination distinguishes it from sibling tools like analyze_pagespeed (single URL) and get_crux_origin (single origin).

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 implies usage for comparing multiple URLs with combined PSI and CrUX data, but does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance.

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

get_crux_originA

Consulta a Chrome UX Report API para uma origem e retorna LCP, INP, CLS e distribuicoes good/needs improvement/poor agregadas.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes	Origem http/https, por exemplo https://www.example.com.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden of behavioral disclosure. It partially meets this by listing the output metrics but omits important aspects such as whether the tool is read-only, any rate limits, or error handling for invalid origins.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and outputs without extraneous words.

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 simplicity of the tool (one parameter, no output schema), the description adequately explains the return values (LCP, INP, CLS, distributions) and covers the essential information needed for an agent.

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?

With schema description coverage at 100%, the baseline is 3. The description does not add meaning beyond the schema's parameter description, merely restating that it queries an origin.

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 queries the Chrome UX Report API for an origin and enumerates the specific metrics (LCP, INP, CLS) and distributions returned. The verb 'consulta' and resource 'origem' are specific, and the name distinguishes it from sibling 'get_crux_url'.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like analyze_pagespeed or compare_web_performance is provided. The description lacks when-not-to-use or prerequisite information.

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

get_crux_urlA

Consulta a Chrome UX Report API para uma URL e retorna LCP, INP, CLS e distribuicoes good/needs improvement/poor.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL http/https a consultar no CrUX.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It mentions the API call and returned metrics, which is adequate for a simple read operation, but omits details like authentication, rate limits, error handling, or idempotency. The behavior is partially transparent.

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?

Single sentence that is front-loaded with action and outcome. Every word is necessary, no redundancy.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description conveys the core purpose and return values. However, it lacks usage guidelines and behavioral details, leaving some gaps for an agent to fully understand the tool's role and limitations.

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?

Input schema has 100% coverage describing the url parameter. The description adds no new meaning beyond 'query CrUX for this URL', which is already in the schema. Baseline of 3 is appropriate.

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 queries the Chrome UX Report API for a specific URL and returns LCP, INP, CLS, and good/needs improvement/poor distributions. This distinguishes it from siblings like get_crux_origin (origin-level) and analyze_pagespeed (different tool).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like get_crux_origin or analyze_pagespeed. The description only states what the tool does without contextualizing appropriate scenarios or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 13, 2026
- First observedanalyze_pagespeed
- First observedanalyze_pagespeed_batch
- First observedcompare_web_performance
- First observedget_crux_origin
- First observedget_crux_url

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: single URL analysis, batch analysis, combined comparison, origin-level CrUX, and URL-level CrUX. No overlap in functionality.

Naming Consistency4/5

All names use snake_case and follow a verb_noun pattern. Minor deviation with 'compare_web_performance' which uses a broader verb, but overall consistent.

Tool Count5/5

Five tools is ideal for a web performance server, covering single/batch analysis, comparison, and CrUX data without bloat.

Completeness4/5

Covers the core PageSpeed Insights and CrUX functionalities well. Could include a tool for Lighthouse report details, but the current scope is reasonable.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

turbometrics-mcpOAuth
io.github.turbopress-de
Website performance monitoring: scans, Core Web Vitals, RUM data and alerts.
Monitoring Observability Web Scraping
2
gtmetrixOAuth
com.gtmetrix
Analyze web performance and get optimization insights from GTmetrix, directly in your AI workflow.
Monitoring Observability
2
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
HubVibe Site Audits A
io.github.Its-fortunatefolly
Rule-based site audits: accessibility, SEO, security headers, performance. Metered per call.
Testing & QA Tools Monitoring Security
51

Related MCP Servers

PageSpeed MCP Server
Web Scraping Monitoring Developer Tools
PhialsBasement
A
license
Not graded
quality
D
maintenance
Acts as a bridge between AI models and Google's PageSpeed Insights API, enabling detailed performance analysis of websites.
Updated a year ago (2025-09-13 23:16 UTC)
22
13
MIT
MCP Server Pagespeed
Web Scraping Monitoring
enemyrr
A
license
B
quality
D
maintenance
Enables AI models to analyze webpage performance using the Google PageSpeed Insights API, providing real-time performance scores and improvement suggestions.
Updated 2 years ago (2025-02-11 17:17 UTC)
1
257
12
MIT
PageSpeed MCP Server
Monitoring Developer Tools
mcpflow
A
license
Not graded
quality
D
maintenance
Enables AI assistants to perform comprehensive web performance analysis using Google's PageSpeed Insights API, including metrics, best practices, SEO, and accessibility audits.
Updated 2 years ago (2025-02-16 19:19 UTC)
22
MIT
MCP PageSpeed Insights
Monitoring Observability
NicolasET
A
license
Not graded
quality
C
maintenance
Connects LLMs to Google PageSpeed Insights to analyze web performance, accessibility, SEO, and best practices, enabling AI assistants to audit and improve any web page.
Updated 6 months ago (2026-03-14 04:28 UTC)
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/teles/web-performance-mcp'

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