Skip to main content
Glama
sitelint

SiteLint Auditor MCP

Official
by sitelint
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

SiteLint Auditor MCP Server

MCP server that runs SiteLint Auditor - WCAG and SiteLint Best Practices for accessibility, SEO, performance, and security audits via LLM agents.

The auditor bundle additionally supports WebMCP: when enabled it registers in-page tools on document.modelContext, so browser agents can run and inspect audits directly on a live site without this server. See WebMCP (in-page tools).

Quick start

npx @sitelint/auditor-mcp

Requires Chromium or Chrome. The MCP server automatically detects an installed system browser. If none is available, Puppeteer normally downloads Chrome during package installation; if that download was skipped, it downloads Chrome for Testing on the first audit. No browser path configuration is required.

Related MCP server: mcp-seo

Tools

audit_url

Audit a live URL.

{
  "url": "https://example.com",
  "standards": ["wcag"],
  "auditTypes": ["accessibility"],
  "wcagLevels": ["A", "AA"],
  "wcagVersions": ["2.2"],
  "wcagCriteria": []
}

audit_html

Audit raw HTML without fetching a URL. Defaults to waitUntil: "load" so image-based rules (e.g. oversized images, size calculations) see fully loaded assets. A timeout guards against hanging external resources — if the load event never fires, the audit aborts with a clear error instead of hanging. Pass waitUntil: "domcontentloaded" to skip slow assets entirely.

All filter parameters are required — pass empty arrays to skip a filter.

WCAG audit:

{
  "html": "<!DOCTYPE html><html>...</html>",
  "standards": ["wcag"],
  "auditTypes": ["accessibility"],
  "wcagLevels": ["A", "AA"],
  "wcagVersions": ["2.2"],
  "wcagCriteria": ["1.1.1", "1.4.3"]
}

SiteLint best practices (proprietary SEO, performance, security):

{
  "html": "<!DOCTYPE html><html lang=\"en\"><head><title>Test</title></head><body></body></html>",
  "standards": ["sitelint"],
  "auditTypes": ["seo", "performance", "security"],
  "wcagLevels": [],
  "wcagVersions": [],
  "wcagCriteria": []
}

Full audit (everything):

{
  "html": "<!DOCTYPE html><html>...</html>",
  "standards": ["wcag", "sitelint"],
  "auditTypes": ["accessibility", "performance", "security", "seo"],
  "wcagLevels": ["A", "AA", "AAA"],
  "wcagVersions": ["2.0", "2.1", "2.2"],
  "wcagCriteria": []
}

check_wcag_criterion

Check a single WCAG criterion against a URL.

{
  "url": "https://example.com",
  "criterion": "1.1.1"
}

Returns pass/fail with violation count.

Filter parameters

Filters are ANDed — a rule must match every provided filter to run. On audit_url filters are optional (omit or pass empty arrays to skip). On audit_html all filter parameters are required — pass empty arrays to skip.

Parameter

Values

Example

standards

wcag, sitelint

["wcag"]

auditTypes

accessibility, performance, security, seo

["accessibility", "seo"]

wcagLevels

A, AA, AAA, best_practices

["A", "AA"]

wcagVersions

2.0, 2.1, 2.2

["2.2"]

wcagCriteria

WCAG criterion numbers

["1.1.1", "1.4.3"]

Omit a parameter (or pass empty array) to skip that filter.

Resources

URI

Description

auditor://standards

Supported WCAG criteria with levels

auditor://report/{id}

Full JSON report from a previous audit

Configuration

Environment variables

Variable

Default

Description

AUDITOR_BROWSER_PATH

Automatic detection

Optional custom Chromium/Chrome executable path

AUDITOR_CONCURRENCY

3

Max concurrent audit pages (hard cap)

AUDITOR_TIMEOUT

30000

Navigation/render timeout (ms)

AUDITOR_HEADLESS

true

Set false to see browser

AUDITOR_TRANSPORT

stdio

stdio or sse

AUDITOR_PORT

3100

Port for SSE transport

SSE / HTTP transport

Run the server over Streamable HTTP instead of stdio:

AUDITOR_TRANSPORT=sse AUDITOR_PORT=3100 npm start

The server listens on 127.0.0.1:3100 and accepts MCP requests via POST /. Host and Origin headers are validated (localhost only). Graceful shutdown on SIGINT/SIGTERM closes the browser and the HTTP server.

Client config:

{
  "mcpServers": {
    "sitelint-auditor": {
      "url": "http://127.0.0.1:3100"
    }
  }
}

CLI flags

auditor-mcp --bundle ./custom-bundle.js --timeout 60000 --headless false

Flag

Env equivalent

--browser <path>

AUDITOR_BROWSER_PATH

--concurrency <n>

AUDITOR_CONCURRENCY

--timeout <ms>

AUDITOR_TIMEOUT

--headless <bool>

AUDITOR_HEADLESS

--bundle <path>

—

--transport <stdio | sse>

AUDITOR_TRANSPORT

--port <n>

AUDITOR_PORT

Integration guides

opencode

Add to ~/.config/opencode/opencode.json:

{
  "mcp": {
    "sitelint-auditor": {
      "type": "local",
      "command": ["npx", "-y", "@sitelint/auditor-mcp"]
    }
  }
}

For a local build:

{
  "mcp": {
    "sitelint-auditor": {
      "type": "local",
      "command": ["node", "/path/to/auditor-mcp/dist/cli.js"]
    }
  }
}

With custom Chromium:

{
  "mcp": {
    "sitelint-auditor": {
      "type": "local",
      "command": ["npx", "-y", "@sitelint/auditor-mcp"],
      "environment": {
        "AUDITOR_BROWSER_PATH": "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        "AUDITOR_TIMEOUT": "60000"
      }
    }
  }
}

Claude Desktop

Edit claude_desktop_config.json:

{
  "mcpServers": {
    "sitelint-auditor": {
      "command": "npx",
      "args": ["-y", "@sitelint/auditor-mcp"]
    }
  }
}

Claude Code

Plugin (recommended)

/plugin marketplace add sitelint/auditor-mcp
/plugin install auditor-mcp@sitelint

Manual

claude mcp add sitelint-auditor -- npx -y @sitelint/auditor-mcp

Codex

Plugin (recommended)

codex plugin marketplace add sitelint/auditor-mcp
codex plugin add auditor-mcp@sitelint

Manual

codex mcp add sitelint-auditor -- npx -y @sitelint/auditor-mcp

ZCode

{
  "sitelint-auditor": {
    "type": "stdio",
    "command": "npx",
    "args": [
      "-y",
      "@sitelint/auditor-mcp@latest"
    ]
  }
}

VS Code (Cline)

In Cline extension settings → MCP Servers:

{
  "sitelint-auditor": {
    "command": "npx",
    "args": ["-y", "@sitelint/auditor-mcp"]
  }
}

VS Code (Continue)

In ~/.continue/config.json:

{
  "experimental": {
    "mcpServers": {
      "sitelint-auditor": {
        "command": "npx",
        "args": ["-y", "@sitelint/auditor-mcp"]
      }
    }
  }
}

AnythingLLM

{
  "mcpServers": {
    "sitelint-auditor": {
      "command": "npx",
      "args": ["-y", "@sitelint/auditor-mcp"]
    }
  }
}

Other MCP clients

Any MCP client can connect. Use stdio transport (default) for local tools, or AUDITOR_TRANSPORT=sse with AUDITOR_PORT=3100 for remote.

Build from source

git clone <repo>
cd auditor-mcp
npm install
npm run build

# Bundle the auditor engine
cp /path/to/auditor/dist/auditor.bundle.js vendor/
cp /path/to/auditor/app/translations/en-us.json vendor/translations/

Requirements

  • Node.js 20+

  • Chromium or Chrome (detected automatically, or downloaded by Puppeteer during installation/on the first audit if needed)

  • SiteLint Auditor bundle (vendored as vendor/auditor.bundle.js)

How it works

  1. Launches headless Chromium via Puppeteer (single browser, pages capped by AUDITOR_CONCURRENCY)

  2. Loads the target page and waits for it to settle (bounded by AUDITOR_TIMEOUT)

  3. Injects the SiteLint Auditor JS bundle into the page

  4. Runs a single-shot audit against the current DOM state

  5. Formats results into a concise text report with grouping and truncation for long outputs

  6. Stores full JSON as a resource accessible via auditor://report/{id}

Navigation failures, timeouts, and browser-launch errors are returned as readable messages rather than raw exceptions.

Limitations vs. embedded auditor

When SiteLint Auditor is embedded directly into a website via <script>, it watches for DOM mutations, re-tests dynamically loaded content, and provides an interactive sidebar UI. The MCP server does not do any of that — it takes a one-time snapshot of the page at the moment of injection. Content loaded after the audit starts (lazy images, infinite scroll, SPA route transitions) is not evaluated. For SPAs or pages with heavy dynamic content, consider waiting for full render before calling the tool.

WebMCP (in-page tools)

WebMCP turns the page itself into a tool server: the site exposes client-side functions with JSON schemas, and a browser agent invokes them directly in the open tab. No stdio/SSE transport, no headless browser, no server deployment.

When the auditor is embedded via <script> with the webmcp option enabled, it registers:

Tool

Description

sitelint_run_audit

Runs a full audit of the live page; returns score and issue totals

sitelint_get_reports

Issues from the last audit with translated messages and element locators (jsPath, cssSelector, xpath); filters ruleId, severity, standard; paginated via offset/limit (default 25, max 100)

sitelint_list_rules

All registered rules with id, severity, standard and WCAG level

sitelint_highlight_issue

Scrolls to and visually highlights the element for an issue jsPath returned by sitelint_get_reports

Enabling from page code:

auditor.config({ webmcp: true });
auditor.run();

The flag is opt-in and defaults to false. Registration is feature-detected: browsers without document.modelContext silently skip it and the auditor behaves exactly as before.

When to use WebMCP instead of this server

  • Live page state — audits SPAs, authenticated views, and content rendered after load; the server only snapshots the initial DOM (see Limitations vs. embedded auditor above).

  • Fix-and-verify loop — the agent changes the page, re-runs sitelint_run_audit, and uses sitelint_highlight_issue to show the user what remains — all inside the user's tab.

  • Assistive and browser-agent workflows — the agent and the user share one context.

Requirements

  • Chromium 146+ with WebMCP enabled (chrome://flags/#enable-webmcp-testing in preview builds; Chrome 150+ exposes the producer API on document.modelContext)

  • Secure context (HTTPS)

  • Tools are visible to same-origin consumers only; cross-origin exposure requires the tools permissions policy plus exposedTo at registration

WebMCP complements this server rather than replacing it: headless audits of arbitrary URLs (CI, batch checks, sites that do not embed the auditor) stay on @sitelint/auditor-mcp; in-browser agents driving a live site use the WebMCP tools.

Available Tools

6 tools
audit_htmlA

Audit raw HTML snippet against WCAG/SEO standards. Creates a sandbox page to analyze the markup.

ParametersJSON Schema
NameRequiredDescriptionDefault
htmlYes
standardsYes
waitUntilNoload
auditTypesYes
wcagLevelsYes
wcagCriteriaYes
wcagVersionsYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It states that a sandbox page is created to analyze the markup, which is useful context, but does not disclose whether the HTML is sent externally, how the sandbox is handled, or any security implications. This is moderate transparency but leaves notable gaps.

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 only two sentences, with no wasted words. It front-loads the core action and adds the key behavioral detail in the second sentence. Exemplary conciseness.

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?

This is a complex tool with 7 parameters (6 required) and no output schema. The description does not explain any of the required parameters, the meaning of 'sitelint', the expected input format for html, or the structure of audit results. Given the complexity, the description is insufficient for an agent to invoke the tool correctly without additional exploration.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the 7 parameters, but it only hints at the standards parameter ('WCAG/SEO') and says nothing about auditTypes, wcagLevels, wcagVersions, wcagCriteria, or waitUntil. The parameter names are somewhat self-explanatory, but the description provides no additional meaning or examples.

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 clearly states the tool audits raw HTML snippets against WCAG/SEO standards, using a sandbox page. This distinguishes it from sibling tools: audit_url presumably audits URLs, and check_wcag_criterion checks specific criteria. The verb 'audit' and resource 'raw HTML snippet' are specific and unambiguous.

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?

The phrase 'raw HTML snippet' provides clear context: use this when you have markup to audit rather than a URL. However, it does not explicitly mention alternatives or exclusions, so it falls short of a full 5.

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

audit_urlA

Run a SiteLint audit on a live URL. Checks WCAG accessibility, SEO, performance, and security. Optionally filter by standard, audit type, WCAG level, version, or specific success criteria.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
standardsNo
waitUntilNonetworkidle2
auditTypesNo
wcagLevelsNo
wcagCriteriaNo
wcagVersionsNo

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the audit scope and available filters but does not mention network behavior, waitUntil handling, or result format. There is no annotation contradiction.

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?

Two sentences, no filler, with the verb and resource front-loaded. Every clause adds value: scope, categories, and filtering capability.

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 description is adequate for tool selection, covering purpose and key filters. But with 7 parameters, no output schema, and no annotations, missing details like waitUntil behavior and return value shape leave notable gaps for an agent invoking it correctly.

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 0%, so the description helps by mapping filter categories (standard, audit type, WCAG level, version, criteria) to parameters. However, it omits waitUntil semantics and does not fully explain each parameter's formatting beyond schema enums.

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 the specific action ('Run a SiteLint audit on a live URL') and names the audit categories (accessibility, SEO, performance, security). This clearly distinguishes it from siblings audit_html (HTML input) and check_wcag_criterion (single criterion).

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?

The 'live URL' scoping provides clear context for when to use this tool vs audit_html, and the optional filter list gives usage flexibility. It doesn't explicitly name alternative tools or state when-not to use, but the context is strong enough.

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

capture_page_issuesB

Load a page with Puppeteer, inject the SiteLint auditor with runtime issue collection enabled, wait, and return captured issues inline. No platform account required — works fully offline.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
waitMsNoMilliseconds to wait after page load before collecting issues.
collectorsNoWhich issue collectors to enable. If omitted, all collectors are enabled.

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the mechanism (Puppeteer load, auditor injection, wait, inline return) and the offline/no-account constraint, but omits permission needs, timeouts/failure behavior, rate limits, and expected issue volume or format.

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?

Two tight sentences with the operational pipeline front-loaded and the offline constraint appended. Nothing is wasted, though it is arguably too terse given the missing usage guidance.

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?

With no output schema and no annotations, the description should carry more weight. 'Return captured issues inline' is vague about the return shape, and nothing is said about failure modes, duration implications of waitMs, or how collectors affect output.

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%: waitMs and collectors are documented in-schema, while url has only a format constraint. The description adds no further semantics for any parameter, so it neither compensates for nor exceeds the schema baseline.

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 pipeline: load a page with Puppeteer, inject the SiteLint auditor, wait, and return issues. This is concrete enough for an agent to know the tool produces issue captures. However, it never distinguishes itself from close siblings like audit_url or audit_html, leaving the agent to infer which captures runtime issues versus static ones.

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 explicit when-to-use guidance or routing to alternatives such as audit_url or check_wcag_criterion. The only contextual hint is 'No platform account required — works fully offline,' which describes a constraint rather than a selection condition.

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

check_wcag_criterionA

Check a single WCAG success criterion against a page. Filters audit to one criterion, level, and WCAG standard — faster than full audit. Returns pass/fail per element.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
levelNoAA
criterionYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It conveys that the tool filters an audit, returns pass/fail per element, and is faster than a full audit. However, it does not explicitly state read-only behavior, error handling, or prerequisites, which are useful for a tool with no annotation safety net.

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 two sentences, front-loaded with purpose, and includes a valuable output hint ('Returns pass/fail per element'). Every phrase contributes without redundancy.

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?

With no output schema and no annotations, the description provides a basic return format and scope but lacks details on edge cases (e.g., invalid URLs, missing criteria, accessibility limitations). It is adequate for a simple check tool but not comprehensive.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must explain parameters. It mentions 'criterion, level, and WCAG standard,' but 'WCAG standard' does not correspond to any schema property (only url, level, criterion). The description does not clearly map parameters to schema fields, leaving ambiguity for an agent.

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 clearly states the action ('Check a single WCAG success criterion against a page') and differentiates from siblings by noting it 'filters audit to one criterion, level, and WCAG standard — faster than full audit.' This makes the tool's specific role unambiguous.

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?

The description implies when to use this tool — for targeted, faster checks — and contrasts it with a full audit. It does not explicitly name sibling tools or state exclusions, but the context and wording ('faster than full audit') provide clear usage guidance.

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

get_issueB

Get full detail for a single issue group: stack trace, user events log (steps to reproduce), network context, and console tail.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupIdYes
siteApiTokenYes

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the returned content, but it does not state that this is a read-only operation, nor does it explain the auth requirement beyond the siteApiToken parameter name, leaving the safety/mutation profile unstated.

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 the verb first and the return payload enumerated. Every clause earns its place with no filler.

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?

There is no output schema, so describing the returned fields is valuable and partially complete. However, with no annotations and 0% parameter coverage, gaps remain around auth/scoping and parameter meaning.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters, so the description would need to compensate. It says nothing about what groupId identifies or what siteApiToken is for, leaving both parameters entirely undocumented.

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 clear verb+resource ('Get full detail for a single issue group') and enumerates what detail is returned (stack trace, user events log, network context, console tail). It implicitly distinguishes itself from the sibling list_issues by emphasizing 'single issue group,' though it never names that sibling explicitly.

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: an agent calling with a groupId wants the full detail of one issue rather than a list. But there is no explicit when-to-use, no stated prerequisite (e.g., needing a groupId from list_issues first), and no exclusion against alternatives.

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

list_issuesA

List recent runtime issues captured by the SiteLint auditor for a site. Returns trimmed fields (issueId, ts, type, severity, pageUrl, message, fingerprint, count). This is the "go find what I just hit" call.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of issues to return.
typesNoFilter by issue type.
minutesNoOnly return issues seen within the last N minutes.
severityNoFilter by severity.
siteApiTokenYes

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It usefully discloses that results are trimmed to specific fields and that recency matters, but it omits the requirement for siteApiToken, rate-limit behavior, and pagination semantics. For a read-only list tool this is adequate but incomplete.

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?

Three sentences, front-loaded with purpose, then return fields, then usage cue. No sentence is redundant; the parenthetical field list is justified because no output schema exists.

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 no output schema, listing the returned fields is valuable and the description covers purpose and recency well. It is slightly incomplete on auth (siteApiToken) and relationship to sibling tools, but the 80% schema coverage fills most parameter 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 coverage is 80%, with descriptions for limit, types, minutes, and severity; siteApiToken is required but undocumented. The description adds "recent" context and says results are for a site, but does not explain parameter behavior beyond what the schema already provides. 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 gives a specific verb and resource ("List recent runtime issues") plus the source (SiteLint auditor) and scope (for a site). It does not explicitly differentiate itself from siblings like get_issue or capture_page_issues; the "go find what I just hit" phrasing only implies the distinction.

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?

"This is the 'go find what I just hit' call" gives an implied usage scenario for recent runtime issues. It does not state when to use this versus get_issue for a single issue or capture_page_issues to generate issues, nor does it provide explicit exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.35
    • Addedcapture_page_issues
    • Addedget_issue
    • Addedlist_issues
  2. 3 tool updatesv1.0.1
    • First observedaudit_html
    • First observedaudit_url
    • First observedcheck_wcag_criterion
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation4/5

Core issue tools list_issues/get_issue are clearly distinct retrieval levels, and audit_html/audit_url separate raw markup from live URL auditing. However, check_wcag_criterion overlaps heavily with audit_url's optional success-criteria filtering, and capture_page_issues vs audit_url both load pages, so an agent could sometimes hesitate between them.

Naming Consistency5/5

All names use snake_case and a predictable verb_noun pattern: list_issues, get_issue, capture_page_issues, audit_html, audit_url, check_wcag_criterion. Singular/plural differences (get_issue vs list_issues) follow normal REST-like conventions.

Tool Count5/5

Six tools is well-scoped for an auditing server, with each tool covering a distinct operation: retrieve issues, inspect issue detail, capture runtime issues, audit HTML, audit URL, and check one WCAG criterion. No obvious filler or missing bulk.

Completeness4/5

The surface covers issue discovery/detail, live page capture, HTML/URL audits, and single-criterion checks, which are the core operations for an auditor. Minor gaps exist around batch/multi-page auditing or listing available sites/audit history, but these are likely workable around.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

  • Web Validator by DigestSEOA
    io.github.AKzar1el

    Audit public webpages and supplied markup for HTML, CSS, SEO, JSON-LD, and link issues.

    Browser AutomationMarketingTesting & QA Tools
    818
  • squirrelscanAOAuth
    com.squirrelscan

    Website QA for your coding agent: audit SEO, performance, security, accessibility over MCP.

    Browser AutomationMonitoringWeb Scraping
    272283
  • crawlinx-mcpA
    io.github.im-ff

    Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.

    Web ScrapingBrowser AutomationMarketing
    3
  • AIsa On-Page AuditBOAuth
    one.aisa

    Your agent needs to crawl a site and say what is wrong with it — broken tags, duplicate content, pages nothing can index, resources that never load. **What you can ask for** • "Crawl this site and list every page with a duplicate title or missing description." • "Which pages are non-indexable, and why?" • "Run Lighthouse on these URLs and give me the failing audits." • "Show the internal link graph and the orphan pages." • "Give me this page's raw HTML and its microdata." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-onpage/mcp and sign in with OAuth — there is no key to create or paste. 20 tools: submit a crawl and read its summary, pages, resources, links and waterfall; duplicate content and duplicate tags; keyword density; non-indexable and uncrawlable resources; parsed content, raw HTML, microdata, screenshots and Lighthouse. **Why this rather than the source** A crawler you drive from the agent, with the audit results as structured data rather than a PDF. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the broken pages here, then ask the same agent what those pages used to rank for — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.

    Browser AutomationWeb Scraping
    261

Related MCP Servers

  • mcp-a11y-tools

    rog0x
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides AI agents with web accessibility analysis tools via MCP, enabling checks for alt text, heading hierarchy, color contrast, ARIA validation, and form accessibility.
    11 npm
    MIT

  • mcp-seo

    g-battaglia
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to perform comprehensive SEO audits on web pages, including meta tags, headings, links, images, performance, and more, via a CLI or MCP server.
    18
    1
    MIT

  • sage-audit

    tmolavi
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to audit URLs or raw HTML for SEO, AEO, and GEO performance, generate llms.txt manifests, and check the tool version via MCP tools.
    1
    MIT