This server runs Google Lighthouse audits on web pages and exposes them as MCP tools.
Run comprehensive Lighthouse audits on any URL with run_audit
Get just the performance score with get_performance_score
Choose audit categories: performance, accessibility, best-practices, SEO, and PWA
Emulate mobile or desktop devices
Enable or disable network throttling
Integrates with MCP clients like Claude Desktop to analyze website quality via natural language
Integrates with Google's Lighthouse tool to provide web performance analysis and auditing capabilities.
Wraps around Google's Lighthouse tool to run comprehensive performance audits on web pages, providing performance scores, metrics, device emulation, network throttling control, and specific audit categories (performance, accessibility, best-practices, seo, pwa).
Enables auditing of Progressive Web App (PWA) metrics as one of the available audit categories when running Lighthouse tests.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lighthouse-mcp audit https://mywebsite.com for performance and accessibility"
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.
An MCP server that wraps around Google's Lighthouse tool to help measure various performance metrics for web pages.
Run comprehensive Lighthouse audits on any URL
Get performance scores and metrics
Configure device emulation (mobile/desktop)
Control network throttling
Select specific audit categories
Related MCP server: LightScout MCP
This server is available in the Model Context Protocol Registry. Install it using your MCP client or Claude Desktop.
You can run the tool directly using npx without installation:
npx lighthouse-mcpInstall the package globally from npm:
npm install -g lighthouse-mcpThen run it:
lighthouse-mcpClone this repository
Install dependencies:
npm installBuild the project:
npm run buildRun the server:
npm startAdd the following to your MCP settings configuration file:
{
"mcpServers": {
"lighthouse": {
"command": "npx",
"args": ["lighthouse-mcp"],
"disabled": false,
"autoApprove": []
}
}
}Add the following to your MCP settings configuration file:
{
"mcpServers": {
"lighthouse": {
"command": "node",
"args": ["/absolute/path/to/lighthouse-mcp/build/index.js"],
"disabled": false,
"autoApprove": []
}
}
}Replace /absolute/path/to/lighthouse-mcp with the actual path to this project.
Run a comprehensive Lighthouse audit on a URL.
Parameters:
url (required): The URL to audit
categories (optional): Array of categories to audit (defaults to all)
Options: "performance", "accessibility", "best-practices", "seo"
device (optional): Device to emulate (defaults to "mobile")
Options: "mobile", "desktop"
throttling (optional): Whether to apply network throttling (defaults to true)
Example:
{
"url": "https://example.com",
"categories": ["performance", "accessibility"],
"device": "desktop",
"throttling": false
}Get just the performance score for a URL.
Parameters:
url (required): The URL to audit
device (optional): Device to emulate (defaults to "mobile")
Options: "mobile", "desktop"
Example:
{
"url": "https://example.com",
"device": "mobile"
}Once the MCP server is configured, you can use it with Claude:
What's the performance score for example.com?Claude will use the get_performance_score tool to analyze the website and return the results.
Node.js 22.19+
Chrome/Chromium browser (for Lighthouse)
Chrome runs with its sandbox enabled. Localhost, IPv4 loopback, and IPv6 loopback remain supported by default. Private, link-local, cloud metadata, and other non-public destinations are blocked, including requests made by redirects and page resources. Connections use validated IP addresses to prevent DNS rebinding. Because loopback access is intentional, audit only pages you trust to access services on your own machine. For hostile sites, use a separate environment with network isolation.
Audits are limited to one at a time and time out after 120 seconds. Chrome and the audit proxy are cleaned up after success or failure.
Set AUDIT_ALLOW_LOOPBACK=false to reject loopback destinations as well as private and metadata addresses. Hosted workers must use this setting and infrastructure egress isolation. Local development keeps loopback access by default.
Get just the performance score for a URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit | |
| device | No | Device to emulate (defaults to mobile) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't describe whether this is a read-only operation, what authentication might be required, rate limits, error conditions, or what format the performance score returns. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's core functionality. There's zero waste or unnecessary elaboration, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'performance score' entails (numeric value, rating scale, composite metric), doesn't mention the sibling tool relationship, and provides no behavioral context. Users need more information to effectively use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents both parameters (url and device). The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'performance score' means, how it's calculated, or provide context about the device parameter's impact. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('performance score for a URL'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'run_audit' - both likely relate to performance analysis but with different outputs or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus its sibling 'run_audit' or any alternatives. It doesn't mention prerequisites, constraints, or appropriate contexts for usage beyond the basic functionality stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Lighthouse audit on a URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit | |
| device | No | Device to emulate (defaults to mobile) | |
| categories | No | Categories to audit (defaults to all) | |
| throttling | No | Whether to apply network throttling (defaults to true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Run a Lighthouse audit'. It does not mention what the audit produces (e.g., scores, report), whether it is time-consuming, if it requires network access, or any side effects. The agent gets no behavioral context beyond the obvious mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately short, though it could be improved by front-loading key behavior. It earns a 4 because conciseness is good, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations, and no output schema, the description is far from complete. It does not explain what the audit returns, how to interpret results, or any edge cases. An agent would not know what to do with the output or how the audit behaves. This is a significant gap for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has its own description in the schema (e.g., device, categories, throttling). The tool description adds no additional parameter meaning, but per the baseline rule, high schema coverage warrants a score of 3. The description does not compensate with extra context but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a Lighthouse audit') and the target ('on a URL'). It is a specific verb+resource combination, but it does not differentiate from the sibling tool get_performance_score, which likely also deals with Lighthouse scores. So it's clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_performance_score. The description does not mention any prerequisites, constraints, or alternative scenarios. It simply states what it does, leaving the agent to guess when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.17run_audit1 field changedInput schema / properties / categories / items / enumPrevious value: -[
- "performance",
- "accessibility",
- "best-practices",
- "seo",
- "pwa"
-]New value: +[
+ "performance",
+ "accessibility",
+ "best-practices",
+ "seo"
+]v1.0.0get_performance_scorerun_auditScored across 2 tools
Both tools relate to Lighthouse audits, but they have distinct purposes: run_audit executes a full audit, while get_performance_score focuses on retrieving only the performance metric. However, get_performance_score is essentially a subset of run_audit, so an agent might be unsure when to use one over the other without additional context.
Both tool names follow a clear verb_noun pattern (run_audit, get_performance_score) with consistent snake_case and action-first style. The naming is predictable and unambiguous in structure.
With only 2 tools, the server feels under-scoped for a Lighthouse MCP. A typical Lighthouse workflow would expect a richer set of operations, such as fetching full report details, comparing scores, or handling multiple categories. The minimal count limits utility and feels thin.
The tool surface is severely incomplete for a Lighthouse server. It only covers running an audit and extracting the performance score, omitting other standard audit categories (accessibility, SEO, best practices) and report retrieval. Agents would hit dead ends if they need any other Lighthouse data.
Analyze web performance and get optimization insights from GTmetrix, directly in your AI workflow.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Find what slows your website down. Run a free check in Claude Code, Cursor or ChatGPT. No account needed to try it. Save your result with a free Nimo account, then check again after your fixes. No card needed. Learn more: https://heynimo.com/for/coding-assistants
