PageSpeed Insights MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GOOGLE_API_KEY | Yes | Google API key for PageSpeed Insights API |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pagespeed_analyze_pageA | Run a PageSpeed Insights Lighthouse analysis for one public page. Start with report=summary for a health check; choose full for audits, recommendations for a prioritized fix list, audit for non-performance categories, or performance-map for Mermaid. Example: analyze a mobile product page and return the three most useful remediation steps. Returns a report plus structured result. The Google API is contacted and results may be served from the local cache. |
| pagespeed_diagnose_pageA | Inspect one page through exactly one diagnostic lens: visual, elements, network, javascript, images, render-blocking, or third-parties. Use after pagespeed_analyze_page identifies a problem; do not use it for a general score. Example: focus=render-blocking to identify CSS/JS delaying first render. Returns focused evidence rather than a full Lighthouse dump. |
| pagespeed_get_field_dataA | Get real-user Core Web Vitals from Chrome UX Report, not Lighthouse lab measurements. Use scope=page for one URL; use scope=origin with a bare origin when the page has insufficient traffic. Example: check mobile LCP and INP for https://example.com/checkout. Returns p75 field metrics or a clear no-data result. |
| pagespeed_compare_pagesA | Compare two pages now (mode=pages) or measure one page against its locally stored baseline (mode=baseline). Baseline mode records the first call; use runs=3 or more and rely on guaranteed deltas, not medians alone. Example: compare staging against production, or verify whether a deployed fix improved mobile LCP. replaceBaseline overwrites local baseline state. |
| pagespeed_analyze_batchA | Analyze 1–10 public URLs and return per-page results plus success/failure counts. Use pagespeed_analyze_page for one URL or pagespeed_compare_pages for a direct comparison. Example: triage the ten highest-traffic landing pages. Progress notifications are emitted when supported by the client. |
| pagespeed_clear_cacheA | Clear only this server process's in-memory PageSpeed response cache, forcing later analysis calls to contact Google again. Use after a deploy when a cached result is stale. It does not change the target website, files, or remote data; repeating the call is safe. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a distinct workflow: single-page analysis, batch analysis, focused diagnostics, field data, comparisons/baselines, and cache control. The only mild overlap is between analyze_page with audit/recommendation reports and diagnose_page, but the descriptions explicitly position diagnose as a follow-up for specific problem areas.
All tools share a consistent pagespeed_ prefix followed by a clear verb_noun pattern: analyze_page, diagnose_page, get_field_data, compare_pages, analyze_batch, clear_cache. The naming is predictable, uniform, and makes the action and target easy to infer.
Six tools is a well-scoped set for a PageSpeed Insights server. Each tool covers a meaningful part of the workflow without redundancy or bloat, and the count feels appropriate for both simple and more advanced performance analysis tasks.
The tool surface covers the core domain well: single and batch Lighthouse analysis, targeted diagnostics, real-user field data, comparison/baselining, and cache management. There are no obvious dead ends or missing operations that would prevent an agent from completing a typical PageSpeed investigation.