MCP 服务器围绕 Google 的 Lighthouse 工具，帮助测量网页的各种性能指标。
对任何 URL 运行全面的 Lighthouse 审核
获取绩效分数和指标
配置设备模拟（移动/桌面）
控制网络限制
选择特定的审计类别
Related MCP server: LightScout MCP
您可以直接使用 npx 运行该工具，无需安装：
npx lighthouse-mcp全局安装包：
npm install -g lighthouse-mcp然后运行它：
lighthouse-mcp克隆此存储库
安装依赖项：
npm install构建项目：
npm run build运行服务器：
npm start将以下内容添加到您的 MCP 设置配置文件中：
{
"mcpServers": {
"lighthouse": {
"command": "npx",
"args": ["lighthouse-mcp"],
"disabled": false,
"autoApprove": []
}
}
}将以下内容添加到您的 MCP 设置配置文件中：
{
"mcpServers": {
"lighthouse": {
"command": "node",
"args": ["/absolute/path/to/lighthouse-mcp/build/index.js"],
"disabled": false,
"autoApprove": []
}
}
}将/absolute/path/to/lighthouse-mcp替换为此项目的实际路径。
对 URL 运行全面的 Lighthouse 审核。
参数：
url （必填）：需要审核的 URL
categories （可选）：要审核的类别数组（默认为全部）
选项：“性能”、“可访问性”、“最佳实践”、“SEO”、“PWA”
device （可选）：要模拟的设备（默认为“移动设备”）
选项：“移动”、“桌面”
throttling （可选）：是否应用网络节流（默认为 true）
例子：
{
"url": "https://example.com",
"categories": ["performance", "accessibility"],
"device": "desktop",
"throttling": false
}仅获取 URL 的性能分数。
参数：
url （必填）：需要审核的 URL
device （可选）：要模拟的设备（默认为“移动设备”）
选项：“移动”、“桌面”
例子：
{
"url": "https://example.com",
"device": "mobile"
}一旦 MCP 服务器配置完毕，您就可以将其与 Claude 一起使用：
What's the performance score for example.com?Claude 将使用get_performance_score工具来分析网站并返回结果。
Node.js 16+
Chrome/Chromium 浏览器（适用于 Lighthouse）
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
