a11y-mcp
# A11y MCP Server
An MCP (Model Context Protocol) server for performing accessibility audits on webpages using axe-core. Use the results in an agentic loop with your favorite AI assistants (Cline/Cursor/GH Copilot) and let them fix a11y issues for you!
<a href="https://glama.ai/mcp/servers/@priyankark/a11y-mcp">
<img width="380" height="200" src="https://glama.ai/mcp/servers/@priyankark/a11y-mcp/badge" alt="a11y-mcp MCP server" />
</a>
## Features
- Perform detailed accessibility audits on any webpage
- Get a summary of accessibility issues
- Filter audits by specific WCAG criteria
- Include HTML snippets in the results for easier debugging
## Installation
```bash
# Install globally
npm install -g a11y-mcp
# Or use directly with npx
npx a11y-mcp
```
## Configuration
To use this MCP server with Cline, you need to add it to your MCP settings configuration file.
### MCP configuration
Add the following to the `mcpServers` object:
```json
{
"mcpServers": {
"a11y": {
"command": "npx",
"args": ["a11y-mcp"],
"disabled": false,
"autoApprove": []
}
}
}
```
## Available Tools
### audit_webpage
Performs a detailed accessibility audit on a webpage.
**Parameters:**
- `url` (required): URL of the webpage to audit
- `includeHtml` (optional): Whether to include HTML snippets in the results (default: false)
- `tags` (optional): Array of specific accessibility tags to check (e.g., wcag2a, wcag2aa, wcag21a, best-practice)
**Example:**
```
Use the a11y MCP server to audit example.com for accessibility issues
```
### get_summary
Gets a summary of accessibility issues for a webpage.
**Parameters:**
- `url` (required): URL of the webpage to audit
**Example:**
```
Give me an accessibility summary of example.com
```
## Example Usage
Once configured, you can ask Claude to use the MCP server to perform accessibility audits:
1. "Can you check example.com for accessibility issues?"
2. "Audit my website at https://mywebsite.com for WCAG 2.1 AA compliance"
3. "Give me a summary of accessibility issues on https://example.com"
4. "Check if my local development server at http://localhost:3000 has any critical accessibility problems"
## Development
To run the server locally for development:
```bash
npm start
```
## Releasing
This project includes a release script to help with versioning and publishing to npm. The script handles version bumping, running tests, git tagging, and npm publishing.
To release a new version:
```bash
# Make sure the script is executable
chmod +x release.sh
# Release a patch version (default)
./release.sh
# Release a minor version
./release.sh --minor
# Release a major version
./release.sh --major
# Release a specific version
./release.sh --version=1.2.3
# Skip git operations
./release.sh --skip-git
# Dry run (no changes will be made)
./release.sh --dry-run
# Force release even with uncommitted changes
./release.sh --force
```
For more information, run:
```bash
./release.sh --help
```
## License
MPL 2.0
## Credits
This project builds atop the awesome work done by [axe-core](https://github.com/dequelabs/axe-core)
## Security and hosting
Requires Node.js 22.12 or newer. Chrome runs with its sandbox enabled.
Every HTTP(S) connection, including redirects and subresources, goes through a
validating proxy that pins the destination IP. Private, link-local, multicast,
reserved, and cloud metadata addresses are blocked, including mapped IPv6.
Loopback remains available for local development; set `AUDIT_ALLOW_LOOPBACK=false`
for public-only audits. LAN addresses are no longer supported.
One audit runs per MCP process, with a 90-second browser deadline.
For hosted use, additionally isolate browser workers and enforce network egress
restrictions at the infrastructure layer. Automated axe checks do not establish
WCAG conformance; manual review is still required.
Run `npm test`, `npm run test:smoke` (requires Chrome), and `npm audit`.
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: 'audit_webpage' performs an accessibility audit, while 'get_summary' retrieves a summary of issues, with no overlap in functionality. An agent can easily differentiate between initiating an audit and fetching results.
Both tools follow a consistent verb_noun pattern ('audit_webpage', 'get_summary'), using snake_case and clear action-oriented verbs. This uniformity makes the tool set predictable and easy to understand.
With only 2 tools, the server feels thin for the domain of web accessibility, lacking operations like detailed issue retrieval, filtering, remediation suggestions, or batch processing. This minimal set may limit agent workflows.
The tool set is severely incomplete for web accessibility auditing; it covers audit initiation and summary retrieval but misses essential functions such as getting detailed issue reports, updating audits, or handling multiple pages, leaving significant gaps for practical use.