Skip to main content
Glama
Sign In
mcp-seo-audit

mcp-seo-audit

by GiorgiKemo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

run_lighthouse_audit

Read-onlyIdempotent

Run a local Lighthouse audit on a trusted URL to measure performance, SEO, accessibility, and best practices for mobile or desktop.

Instructions

Run a local Lighthouse CLI audit for an explicitly trusted URL.
Requires SEO_AUDIT_ENABLE_LOCAL_LIGHTHOUSE=true, Node.js and Chrome/Chromium.
Lighthouse browser networking is not guarded by the public crawl transport.

Args:
    url: Full page URL
    form_factor: mobile or desktop
    categories: Comma-separated Lighthouse categories

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "run_lighthouse_audit"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
categoriesNoperformance,seo,accessibility,best-practices
form_factorNomobile

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: a required env flag, local runtime dependencies, and the notable disclosure that Lighthouse browser networking is not guarded by the public crawl transport. It does not mention cost/duration or failure behavior of a local browser run.

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 key constraint (local, trusted URL) is front-loaded, and the args block is compact. The three lines of prerequisites are individually short and each carries distinct meaning.

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?

Output schema exists so return values need no explanation, and all three params plus runtime prerequisites are covered. Remaining gap is guidance on how this audit relates to the many other audit/report siblings and what 'trusted URL' implies in practice.

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

Parameters4/5

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

With 0% schema description coverage, the description carries the whole burden and does document all three parameters: full page URL, mobile/desktop form factor, and comma-separated categories. It even supplies the mobile/desktop values the schema lacks as an enum. Format detail is good but not exhaustive (e.g. allowed category tokens).

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?

States a specific verb and resource (run a Lighthouse CLI audit) with a scoping qualifier ('local', 'explicitly trusted URL') that implicitly separates it from remote siblings like get_pagespeed_insights and audit_live_site. It never names an alternative outright, so the differentiation is inferred rather than explicit.

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

Usage Guidelines4/5

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

Gives clear preconditions (SEO_AUDIT_ENABLE_LOCAL_LIGHTHOUSE=true, Node.js, Chrome/Chromium) and a trust constraint on the URL, which tells the agent when it *can* run. It stops short of naming when to prefer this over the other audit tools in the sibling list.

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

Deploy Server

Other Tools