Lighthouse MCP

by danielsogl

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.27
Disambiguation2/5
There is significant overlap between run_audit and the specific getter tools (accessibility, SEO, performance), as run_audit likely encompasses all of those. Additionally, get_lcp_opportunities, find_unused_javascript, and analyze_resources all target performance optimization with unclear boundaries.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (e.g., get_*, run_audit, compare_mobile_desktop, check_performance_budget). Minor deviations include run_audit vs. get_security_audit (both use 'audit' but different verbs) and find_unused_javascript/analyze_resources not using 'get_' prefix, but the overall convention is consistent.
Tool Count5/5
With 11 tools, the set is well-scoped for a website auditing server. Each tool covers a distinct aspect of Lighthouse auditing (performance, SEO, accessibility, security, resources), and the count is within the ideal 3-15 range without feeling bloated.
Completeness4/5
The tool surface covers major Lighthouse categories (performance, accessibility, SEO, security, Core Web Vitals, resources) and includes useful extras like budget checks and mobile/desktop comparison. However, it lacks explicit best practices and PWA audits, which are standard Lighthouse categories, creating minor gaps.
Average 3.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 50 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not state that the tool fetches a live URL, runs a Lighthouse audit, or that it may take time or require network access. With readOnlyHint and openWorldHint already provided, the description contributes nothing extra.
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 efficient sentence with no wasted words. It is appropriately concise for the tool's simplicity, though it is not front-loaded with any additional context because there is none.
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 two-parameter tool with an output schema, the description is minimally adequate but lacks key contextual details such as what constitutes a 'performance score' (e.g., Lighthouse metric), prerequisites like URL accessibility, or any potential variability. Given the existence of siblings, it is not sufficiently complete to guide correct selection.
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 coverage is 100% as both 'url' and 'device' are described in the input schema. The description adds no additional meaning about the parameters or their usage, so the baseline of 3 is appropriate.
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?
The description uses a specific verb ('get') and resource ('performance score for a website'), making the intent clear. However, it does not differentiate from nearby siblings like get_core_web_vitals or get_lcp_opportunities, which also relate to performance metrics, so there is a mild ambiguity.
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?
There is no guidance on when to use this tool versus alternatives such as get_core_web_vitals or analyze_resources. No exclusions or recommended contexts are provided, leaving an agent to infer the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds no further behavioral context such as rate limits, time expectations, or the nature of external fetches, offering minimal value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core purpose. It is appropriately concise for a tool whose parameters and return format are fully specified in the schema.
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 large set of specialized audit siblings, the description is thin on context for selection. It doesn't mention that this provides a comprehensive overview or when to prefer it over targeted tools, and it omits any note about output shape (though the output schema covers that). The lack of usage guidance undermines completeness.
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 schema provides full descriptions for all three parameters at 100% coverage. The description adds no extra meaning, so the baseline of 3 applies. Nothing is lacking in terms of parameter documentation.
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?
The description clearly states the tool retrieves SEO analysis and recommendations for a website, using a specific verb and resource. While it doesn't explicitly contrast with sibling audit tools, the name and resource make it distinct from performance, accessibility, and security-specific tools.
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?
The description provides no guidance on when to choose this tool over alternative audit or metric tools. An agent must infer from the name that it covers general SEO, with no explicit exclusions or references to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the purpose and adds no behavioral traits beyond the annotations. Annotations declare readOnlyHint and openWorldHint, but the description does not disclose what an audit entails (e.g., live network request, duration, caching). Since annotations are present, the burden is lower, but the description adds no value.
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?
A single, clear sentence with no redundancy. The primary action and outcome are front-loaded. Perfectly concise.
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?
The tool is simple, has an output schema (though not shown), and full schema coverage. The description is adequate but omits context about how the audit is performed (live vs. cached) and what 'recommendations' entail. Given the complexity level, this is a minimum-viable description.
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 100% for all parameters, including device enum and includeDetails. The description does not elaborate on parameters, but the schema carries the full burden. Baseline 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'accessibility score and recommendations for a website'. It distinguishes itself from performance, SEO, and security siblings by naming the accessibility domain, but does not explicitly reference alternatives.
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 alternatives. It does not mention prerequisites, use cases, or exclusions. An agent would have to infer from the name that it is for accessibility audits only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true and openWorldHint: true, indicating a read-only operation that may access external resources. The description adds no extra behavioral context—it does not mention that the tool will perform a live audit, make network requests, or have rate limits. While there is no contradiction, the description fails to disclose the operation's networked nature, which is a meaningful behavioral trait beyond 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 a single, efficient sentence with no filler. It conveys the purpose immediately and contains no redundant information. It earns a high score for being appropriately sized and front-loaded.
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?
Given the tool's moderate complexity (nested budget object, optional device, output schema present), the description is minimal. It does not explain when to use it compared to siblings, nor does it clarify the semantics of the budget fields beyond what the schema provides. The output schema exists, so return values are covered, but the lack of usage guidance leaves the description somewhat incomplete for guiding an agent toward correct invocation in context.
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 67%: url and device have descriptions, but the budget object itself lacks a description at the top level. The inner properties are described, so the schema partially covers the main parameter. The description adds no additional meaning about how to structure the budget or interpret thresholds, leaving the agent to rely on the schema's inner property descriptions, which are adequate but not enriched.
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?
The description clearly states the tool's function: checking website performance against budget thresholds. It uses a specific verb ('check') and resource ('website performance'), and the notion of 'budget thresholds' distinguishes it from sibling tools that return raw scores or metrics. However, it does not explicitly name an alternative or contrast with similar tools like get_performance_score, so it is clear but not strongly differentiated.
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?
There is no guidance on when to use this tool instead of siblings such as run_audit, get_performance_score, or get_core_web_vitals. The description only states what it does, leaving the agent to infer appropriate use. No exclusions, alternatives, or preconditions are provided, so usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and openWorldHint=true, so the tool's non-destructive and open-world behavior is covered, and the description does not contradict the annotations. The description adds little beyond the generic 'find' behavior—no mention of how the scan is performed, what resources are fetched, or what output to expect—so it stays at the baseline for annotation-covered tools.
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 efficient sentence that immediately states the tool's core function. It avoids filler and front-loads the verb and resource, making it easy for an agent to parse at a glance.
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?
The tool is simple, and the schema, annotations, and output schema fill in a lot. However, the description does not mention the need for a URL or clarify how this audit relates to the many other audit siblings, leaving the agent without enough context to confidently choose and invoke it among the broader toolset.
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 coverage of the input parameters is 100%, so the baseline is 3. The description mentions bundle size, which loosely relates to minBytes, but it does not add detail about how url, device, or minBytes interplay; the schema carries the burden.
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?
The description uses a specific verb ('Find') and a concrete resource ('unused JavaScript code'), and adds the motivating goal of reducing bundle size. It is clear enough to be distinguished from performance scoring tools, but it does not explicitly differentiate it from a sibling like analyze_resources, so it misses the 5 criterion.
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 alternatives such as get_performance_score, analyze_resources, or run_audit. There are no conditions, prerequisites, or exclusion criteria—only a one-line purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description itself adds little behavioral context, such as whether the tool performs a live network audit or how results are ordered, but it does not contradict 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 a single front-loaded sentence with no filler or repetition. It states the essential purpose efficiently, and nothing extraneous is included.
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?
Output schema and complete parameter documentation reduce the need for the description to explain return values or parameters. However, the lack of usage guidance relative to sibling tools and the absence of operational caveats leave the overall context only adequate, not fully complete.
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 100%, and each parameter is documented with types, defaults, enums, and constraints. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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?
The description clearly identifies the verb ('Get') and resource ('LCP optimization opportunities for a website'), so an agent understands the tool's core purpose. It does not explicitly distinguish itself from sibling tools such as get_core_web_vitals or get_performance_score, but the LCP-specific focus provides reasonable differentiation.
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 provided about when to use this tool versus alternatives like get_core_web_vitals, get_performance_score, or run_audit. There are no stated exclusions, prerequisites, or context cues, leaving the agent to infer selection based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds 'comprehensive' but doesn't disclose behavioral traits like the fact that it runs multiple categories, the time it takes, or that it may be slower than targeted audits. With annotations covering safety, the description adds minimal behavioral context beyond the word 'comprehensive'.
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 with no waste. It's front-loaded with the verb and resource. It could be slightly more informative, but it's concise and to the point.
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?
The tool has an output schema (not shown) and 4 parameters with 75% schema coverage. The description is minimal but the schema and annotations carry some weight. However, given the complexity of a Lighthouse audit (multiple categories, device emulation, throttling), the description could explain what 'comprehensive' means and how it relates to the sibling tools. It's adequate but not complete.
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 75%, so most parameters are documented in the schema. The description doesn't add any parameter-specific meaning beyond what the schema provides. The 'categories' parameter has an enum with 'agentic-browsing' which is unusual, but the description doesn't explain it. Baseline 3 is appropriate since the schema does most of the work.
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?
The description states a specific verb ('Run') and resource ('Lighthouse audit'), and the title clarifies it's a website audit. It's clear what the tool does, though it doesn't explicitly differentiate from siblings like get_performance_score or get_accessibility_score, which are more specific. The description is broad but not misleading.
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 running a comprehensive audit, but it doesn't explicitly state when to use this tool versus the more specific sibling tools (e.g., get_performance_score, get_accessibility_score). It doesn't mention alternatives or exclusions. The context signals show many sibling tools that are more targeted, so the description should guide the agent on when to choose this comprehensive audit over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, read-only operation that may access external URLs. The description adds the focus on optimization opportunities but does not disclose details like whether it fetches live pages, handles redirects, or has rate limits. With annotations covering the safety profile, a 3 is appropriate – it adds some context but not rich behavioral detail.
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?
A single, clear sentence that front-loads the resource types and purpose. No waste, though it could be slightly more specific about the output or usage context. Efficient and to the point.
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 output schema exists and annotations cover safety, the description is adequate for a resource analysis tool. It doesn't explain return values (covered by output schema) or edge cases, but for a read-only analysis tool with 4 parameters, it is reasonably complete. Could benefit from mentioning that it analyzes a single URL or that it's for optimization, but these are minor gaps.
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 100%, so all four parameters are documented in the schema. The description adds the overall purpose but does not add syntax or format details beyond what the schema provides. Baseline 3 is correct when schema does the heavy lifting.
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?
The description states a specific verb ('Analyze') and resource ('website resources') with a clear scope (images, JS, CSS, fonts) and purpose (optimization opportunities). It distinguishes from siblings like get_performance_score or get_seo_analysis by focusing on resource-level analysis, though it doesn't explicitly name a sibling it is not.
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 optimization analysis but does not explicitly state when to use this tool versus alternatives like find_unused_javascript or get_lcp_opportunities. The sibling list suggests related tools, but no exclusions or conditions are provided. The context is clear enough for a general audit, but lacks explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. However, it adds no extra behavioral context such as how the comparison is structured, whether it returns a single report or dual reports, or any throttling implications. With annotations covering the read-only nature, the description provides marginal added value.
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?
A single, front-loaded sentence with zero filler. It delivers the core purpose immediately and does not elaborate unnecessarily.
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?
The tool is simple, annotations cover safety, and an output schema exists so return format details are not required. However, the description lacks usage guidance and does not mention any special considerations (e.g., throttling, category selection) that an agent might need to know for effective invocation. It is minimally sufficient but not comprehensive.
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 75% (high), and all parameters have descriptive names and default values in the schema. The description adds no parameter-specific meaning beyond what the schema already provides. The 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 states a specific action (compare) on a defined resource (website performance) between mobile and desktop devices. It clearly distinguishes itself from sibling audit tools like run_audit or get_performance_score, which focus on single-device audits or individual metric categories.
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 is given on when to use this tool versus alternatives. It does not mention that it is the preferred tool when a mobile/desktop comparison is needed, nor does it exclude cases where a single-device audit would suffice. The usage context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds that it checks HTTPS/CSP and 'other security measures', which is useful but thin. It does not mention network behavior toward the target URL or response characteristics, though openWorldHint partially implies external access. No contradiction with annotations.
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?
A single sentence that front-loads the action ('Perform security audit') and gives concrete examples of check types. The tail 'and other security measures' is slightly vague but functions as a pointer to the schema's enum without bloating the text.
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, full parameter documentation in the schema, and annotations covering the read-only/open-world safety profile, the description is largely sufficient for correct invocation. The notable gap is the missing relationship to 'run_audit', which is the one sibling that could genuinely confuse tool selection.
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 100% — url, checks, and device are all documented in the input schema, so the description carries no required burden. The mention of 'HTTPS, CSP' marginally reinforces the enum values in the 'checks' parameter, but adds little beyond the schema's own descriptions.
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?
The description names a specific verb+resource ('security audit') and concrete focus areas (HTTPS, CSP), which cleanly separates it from the nine accessibility/SEO/performance siblings. However, it does not distinguish itself from the overlapping sibling 'run_audit', whose scope is left undefined, so an agent cannot fully tell them apart.
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?
Usage is implied by the security focus and the 'checking HTTPS, CSP' phrasing, which suggests this is the tool for security-related audits. There is no explicit statement of when to prefer it over 'run_audit' or when not to use it, leaving the selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, meaning the tool performs a safe, read-only operation. The description adds no new behavioral information beyond the name, but given the annotations already cover the safety and non-mutating nature, the description's transparency is adequate. It does not contradict annotations, and the openWorldHint suggests the tool may reach external websites, which is not disclosed in the description but is implied by the term 'website'. The absence of details about rate limits or external dependencies is minor since the tool is read-only.
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, concise sentence that directly states the tool's purpose. Every word is meaningful; there is no fluff or repetition. It is appropriately front-loaded, with the verb 'Get' immediately clarifying the action. This is a model of conciseness.
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 tool's complexity (4 parameters, nested threshold object, output schema present), the description is relatively sparse, but the robust input schema and presence of an output schema reduce the need for extensive description. The description covers the 'what' but not the 'how' or nuances like how thresholds affect evaluation or what 'detailed metrics' entails. With the output schema handling return values and the schema handling parameters, the description is sufficient for a read-only tool, so it slightly exceeds the minimum viable.
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 input schema already describes all parameters with reasonable detail (url, device, threshold object with fields, includeDetails). The schema description coverage is 75%, so most parameters are documented. The description does not add any additional meaning beyond what the schema provides; for example, it doesn't explain how thresholds are used or how includeDetails alters the output. With high coverage, the baseline is 3, and the description contributes minimal 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?
The description 'Get Core Web Vitals metrics for a website' clearly identifies the specific metrics (Core Web Vitals) and the resource (a website), using a precise verb. It is specific enough to distinguish it from generic measures like 'get_performance_score', though it could name a specific competitor (e.g., get_performance_score) to further differentiate. The title and description are aligned, with the description adding 'metrics' to clarify the resource.
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 no explicit guidance on when to use this tool versus siblings such as 'get_performance_score' or 'compare_mobile_desktop'. However, the purpose is clear enough that an agent can infer it is for Core Web Vitals (LCP, INP, CLS) specifically, which is a subset of performance. There are no exclusions or alternatives mentioned, so the usage context is implied rather than explicit, warranting a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Lighthouse MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Lighthouse MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/danielsogl/lighthouse-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/danielsogl/lighthouse-mcp-server)

Score Badge

Copy to your README.md:

[![Lighthouse MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/danielsogl/lighthouse-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/danielsogl/lighthouse-mcp-server)

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/danielsogl/lighthouse-mcp-server'

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