Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@accesslint/mcp audit https://example.com for WCAG violations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This package is maintained in the AccessLint monorepo.
MCP server for accessible agentic coding — WCAG audit tools for AI coding agents. Built on @accesslint/core. From AccessLint.
Add to your MCP client configuration:
{
"mcpServers": {
"accesslint": {
"command": "npx",
"args": ["@accesslint/mcp"]
}
}
}Related MCP server: A11y MCP Server
audit_html — Audit an HTML string for WCAG violations. Auto-detects fragments vs full documents.
audit_file — Read an HTML file from disk and audit it.
audit_url — Fetch a URL and audit the returned HTML.
diff_html — Audit new HTML and diff against a previously named audit to verify fixes.
list_rules — List available WCAG rules with optional filters by category, level, fixability, or criterion.
All audit and diff tools accept an optional min_impact parameter to filter results by severity. Valid values, from most to least severe: critical, serious, moderate, minor. When set, only violations at that level or above are shown.
Each violation in the audit output includes the rule ID, CSS selector, failing HTML, impact level, and — where available — a concrete fix suggestion, fixability rating, and guidance. When multiple elements break the same rule, shared metadata is printed once to keep output compact.
To audit React components (.jsx/.tsx), the agent uses the audit-react-component prompt, which guides it through:
Reading the component source
Mentally rendering it to static HTML (acting as renderToStaticMarkup)
Passing the rendered HTML to audit_html with component_mode: true
No extra runtime dependencies are required — the agent renders the component itself based on the source code.
Without tools, the agent reasons about WCAG rules from memory. The MCP replaces that with structured output — specific rule IDs, CSS selectors, and fix suggestions — so the agent skips straight to applying fixes. This means 23% fewer output tokens per run, which translates directly to faster and cheaper completions.
Benchmarked across 25 test cases, 67 fixable violations, 3 runs each (Claude Opus):
With @accesslint/mcp | Agent alone | |
Violations fixed | 99.5% (200/201) | 93.5% (188/201) |
Regressions | 1.7 / run | 2.0 / run |
Cost | $0.56 / run | $0.62 / run |
Duration | 270s / run | 377s / run |
Timeouts | 0 / 63 tasks | 2 / 63 tasks |
MIT
Read an HTML file from disk and audit it for accessibility violations.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Store result for later diffing (e.g. "before") | |
| path | Yes | Path to HTML file (absolute, or relative to cwd) | |
| min_impact | No | Only show violations at this severity or above |
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 says the tool reads and audits, but does not disclose the optional storage side effect implied by the 'name' parameter, nor what the audit result contains or whether anything is written.
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?
A single, front-loaded sentence with no filler. Every word contributes to the core purpose of the tool.
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?
With no output schema and no annotations, the description should explain what an audit returns and any side effects. It provides neither, and it also does not differentiate itself clearly from the sibling audit tools.
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?
All three parameters are described in the schema, including the enum for min_impact, so the description does not need to add much. It also does not add material semantics beyond what the schema already provides.
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 uses a specific verb and resource: 'Read an HTML file from disk and audit it for accessibility violations.' It clearly identifies what the tool does and the 'from disk' qualifier distinguishes it from URL- or string-based audit siblings.
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 phrase 'from disk' implies this tool is for local HTML files, which is some guidance, but it does not explicitly state when to use audit_file over audit_html, audit_url, or list_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit an HTML string for accessibility violations. Auto-detects fragments vs full documents.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | HTML to audit for accessibility violations | |
| name | No | Store result for later diffing (e.g. "before") | |
| min_impact | No | Only show violations at this severity or above |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. It does add one useful trait (auto-detecting fragments vs full documents), but it fails to say whether the audit is read-only, what the return format looks like, whether it stores results, or what side effects might occur. Substantial behavioral gaps remain.
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?
Two sentences, front-loaded with the core purpose, and the second sentence adds a meaningful behavioral detail. Every word earns its place; no filler or redundancy.
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?
The tool has no output schema and no annotations, yet the description does not explain what the audit result looks like, how violations are reported, or any usage context. Required input is clear, but an agent cannot predict the response shape or know when this tool is preferred over siblings.
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?
All three parameters have schema descriptions (100% coverage), so the baseline of 3 applies. The tool description adds no further parameter meaning beyond the schema's own documentation of html, name, and min_impact.
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?
Description states a specific verb ('Audit') and resource ('an HTML string'), and the target is clear: accessibility violations. It distinguishes from likely siblings like audit_file/audit_url implicitly by the input type, but it does not name those alternatives or explicitly frame the difference.
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 on when to use this tool vs alternatives such as audit_file or audit_url. The 'auto-detects fragments vs full documents' line is a behavioral note, not usage guidance. The appropriate context must be inferred entirely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and audit the returned HTML for accessibility violations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch and audit | |
| name | No | Store result for later diffing (e.g. "before") | |
| min_impact | No | Only show violations at this severity or above |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says the tool 'fetches' and 'audits'. It does not mention network behavior, timeouts, redirects, authentication requirements, side effects of fetching a remote URL, or the shape of the returned audit result.
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, front-loaded sentence with no filler. It efficiently conveys the action and resource in under 15 words, and every word adds meaning.
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?
The schema fully documents the parameters, and the core purpose is clear. However, with no output schema and no annotations, the description leaves out the audit result format and important network-related behaviors, making it minimally adequate rather than complete.
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 the url, name, and min_impact parameters are already documented in the schema. The description adds no parameter-level meaning beyond confirming the URL fetch and HTML audit, so the baseline of 3 applies.
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?
States a specific operation: fetching a URL and auditing the returned HTML for accessibility violations. It is clearly URL-based and thus distinct from sibling tools like audit_html and audit_file, but it does not explicitly call out that differentiation.
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 given on when to use this tool vs alternatives such as audit_html, audit_file, diff_html, or list_rules. The description only states what the tool does, leaving an agent to infer selection from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit new HTML and diff against a previously named audit. Use after audit_html with a name to verify fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Updated HTML to audit and compare | |
| before | Yes | Name passed to a prior audit_html call (must run audit_html with this name first) | |
| min_impact | No | Only show violations at this severity or above |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior. It discloses the key behavioral requirement: the tool depends on a previous named audit_html call and compares against it. It doesn't detail output specifics, but the audit-and-diff behavior is clearly conveyed.
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?
Two concise sentences front-load the core purpose and then give usage direction. Every word contributes, with no redundant or filler content.
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?
The description provides the essential prerequisite (prior named audit) and expected workflow (verify fixes), which is sufficient for a three-parameter tool. The absence of explicit output details is minor, since the schema covers parameters and the diff behavior implies the result.
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 the schema already documents all three parameters. The description adds context around 'new HTML' and 'previously named audit' but does not add substantive meaning beyond what the schema already provides.
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 states a specific action—'Audit new HTML and diff against a previously named audit'—with a clear resource and comparison target. It also distinguishes itself from sibling audit tools by emphasizing the diff against a prior named audit rather than a standalone audit.
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 explicitly says to use this tool 'after audit_html with a name to verify fixes,' which gives clear timing and purpose. It does not explicitly list when-not-to-use conditions, but the prerequisite and sibling relationship are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available accessibility rules with optional filters by category, WCAG level, fixability, or criterion.
| Name | Required | Description | Default |
|---|---|---|---|
| wcag | No | Filter by WCAG criterion (e.g. "1.1.1") | |
| level | No | Filter by WCAG level | |
| category | No | Filter by category slug (e.g. "aria", "text-alternatives") | |
| fixability | No | Filter by fixability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List available accessibility rules' with filters; it does not disclose whether this is a read-only operation, what the return format is, whether there are limits, or any side effects. For a listing tool, this is a notable gap in transparency.
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 sentence that is concise and front-loaded with the main action ('List available accessibility rules') followed by the optional filter dimensions. There is no fluff or repetition, making it efficient for an agent to parse.
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's simplicity and the complete parameter documentation, the description covers the essential purpose and usage. It does not explain how results might be returned or how filters interact, but that is not critical for a listing operation. The absence of an output schema is offset by the straightforward nature of the tool, but a note on how to use the results would improve completeness.
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?
The input schema provides descriptions for all four parameters (wcag, level, category, fixability), achieving 100% coverage. The description only mentions the filter types without adding extra meaning or examples beyond what the schema already contains. Baseline of 3 is appropriate since 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 lists accessibility rules and mentions specific filter dimensions. This distinguishes it from auditing tools (audit_html, audit_file, audit_url) which perform analysis, and diff_html which compares documents. The verb 'List' is specific and the resource 'available accessibility rules' is unambiguous.
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 implies the tool is for discovering available rules and optionally filtering them, but it does not explicitly state when an agent should use this over alternatives or when not to use it. There is no mention of prerequisites, context, or exclusions. The usage context is implied rather than stated.
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.2.5audit_fileaudit_htmlaudit_urldiff_htmllist_rulesScored across 5 tools
Each tool has a clearly distinct input source or purpose: HTML strings, files, URLs, diffs, and rule listing. There is no meaningful overlap between audit sources or the diff and rules tools.
Tool names consistently follow a verb_noun pattern in snake_case: audit_html, audit_file, audit_url, diff_html, list_rules. The naming is predictable and easy to reason about.
Five tools is well-scoped for an accessibility auditing server. Each tool covers a distinct, necessary function without bloat or redundancy.
The tool surface covers the full audit workflow: input from multiple sources, diffing to verify fixes, and rule discovery. No obvious dead-end operations or critical missing capabilities for the stated purpose.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
Website QA for your coding agent: audit SEO, performance, security, accessibility over MCP.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
MCP server for building and testing AI agents with multi-model experimentation and insights.
