What can you do with this server?

This server provides automated web accessibility auditing using axe-core, with built-in Cloudflare/bot protection bypass via an anti-detect browser (Camoufox). * Scan entire pages (scan_page): Navigate to any URL and run a full WCAG accessibility audit, with automatic Cloudflare bypass and configurable conformance level. * Scan specific elements (scan_element): Target a CSS selector on the current page to audit just that element and its descendants. * Retrieve violation details (get_violations): Get a detailed list of accessibility violations from the most recent scan, including affected HTML elements, WCAG references, and remediation guidance. * Get full reports (get_full_report): Access a comprehensive report covering violations, passes, incomplete checks, and inapplicable rules. * Export reports (export_report): Export scan results in JSON (machine-readable), HTML (stakeholder-friendly), or CSV (spreadsheet/tracking) formats. * Set WCAG conformance level (set_wcag_level): Configure the WCAG standard to test against — supports WCAG 2.0 (A, AA, AAA), 2.1 (21A, 21AA), and 2.2 (22AA). * Configure rules (configure_rules): Enable or disable specific axe-core rules (e.g., color-contrast, image-alt) to customize subsequent scans.

Which integrations are available for this server?

Allows scanning of Cloudflare-protected websites by bypassing bot protection mechanisms like JavaScript challenges and Turnstile using Camoufox.

How do I use a11y-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@a11y-mcp check accessibility of https://example.com" 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.

a11y-mcp

by antonio-rmrz

Overview Schema Related Servers Score Discussions

Python

Local

PyPI License: MIT

MCP server for running axe-core accessibility audits. Uses Camoufox to bypass Cloudflare and other bot protection.

Install

# Claude Code
claude mcp add a11y -- uvx a11y-mcp

# Or with pip
pip install a11y-mcp

Related MCP server: Accessibility MCP Server

Configuration

For Claude Desktop, add to your config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "a11y": {
      "command": "uvx",
      "args": ["a11y-mcp"]
    }
  }
}

Most editors use the same format. Add to your MCP config:

{
  "mcpServers": {
    "a11y": {
      "command": "uvx",
      "args": ["a11y-mcp"]
    }
  }
}

Config locations:

Cursor: ~/.cursor/mcp.json
VS Code (Continue): .continue/config.json under experimental.modelContextProtocolServers
VS Code (Cline): Cline MCP settings
Zed: ~/.config/zed/settings.json under context_servers

Tools

Tool	Description
`scan_page`	Scan a URL for WCAG violations
`scan_element`	Scan a specific CSS selector
`get_violations`	Get detailed violation info from last scan
`get_full_report`	Full axe results (violations, passes, incomplete)
`export_report`	Export as JSON, HTML, or CSV
`set_wcag_level`	Set WCAG level (A, AA, AAA, 21A, 21AA, 22AA)
`configure_rules`	Enable/disable specific axe rules

Usage

> Scan https://example.com for accessibility issues

> Export an HTML report for the last scan

> Check WCAG 2.2 AA compliance for https://adobe.com

WCAG Levels

Level	Standard
`A`, `AA`, `AAA`	WCAG 2.0
`21A`, `21AA`	WCAG 2.1
`22AA`	WCAG 2.2

Default is AA.

Cloudflare Bypass

This uses Camoufox, an anti-detect browser with fingerprint spoofing at the C++ level. It handles JavaScript challenges, Turnstile, and most bot detection automatically.

On first run, Camoufox downloads a browser binary (~300MB).

Requirements

Python 3.10+
macOS, Linux, or Windows

Troubleshooting

Browser won't launch: Run python -c "import camoufox; camoufox.install()"

Cloudflare still blocking: Some sites have aggressive detection. The first visit may require manual verification.

axe-core won't inject: Likely a strict CSP. Try a different page on the same domain.

Development

git clone https://github.com/antonio-rmrz/a11y-mcp && cd a11y-mcp
uv venv && source .venv/bin/activate
uv pip install -e ".[dev]"
python -m camoufox fetch
pytest

Debug with the MCP inspector:

npx @modelcontextprotocol/inspector uvx a11y-mcp

License

MIT License - see LICENSE for details.

Credits

axe-core - Accessibility testing engine by Deque
Camoufox - Anti-detect browser
MCP - Model Context Protocol by Anthropic

mcp-server-fetch - Web content fetching
mcp-server-puppeteer - Browser automation
mcp-server-playwright - Playwright browser control

Available Tools

7 tools

configure_rulesA

Enable or disable specific accessibility rules.

Use this to customize which rules are checked during scans. Changes apply to all subsequent scans until reconfigured.

Common rules to disable:

color-contrast: Color contrast checks
image-alt: Image alt text requirements
link-name: Link text requirements
region: Landmark region requirements

Args: rules: Map of rule IDs to enabled status. Example: {'color-contrast': false}

Returns: Confirmation of applied configuration

ParametersJSON Schema

Name	Required	Description	Default
`rules`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

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

Discloses that changes apply to all subsequent scans until reconfigured, but lacks details on potential side effects, error handling, or scope (session vs. global). No annotations provided, so description carries full burden.

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?

Concise with three short paragraphs, bullet points for common rules, and an Args section. No wasted words; purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple configuration tool with one parameter and an output schema, the description covers purpose, usage, parameter explanation, and return value adequately.

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?

The schema has 0% description coverage, but the description compensates well by providing an example, listing common rule IDs, and explaining the map structure. Adds meaning beyond the schema.

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 specifies a clear verb ('Enable or disable') and resource ('specific accessibility rules'), distinguishing it from sibling tools like scan_page or get_violations.

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?

States when to use ('customize which rules are checked during scans') and that changes persist across scans, but does not explicitly exclude use cases or mention alternatives.

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

export_reportA

Export accessibility report in the specified format.

Generates a formatted report from the last scan results.

Formats:

json: Machine-readable JSON with full details
html: Styled HTML report for stakeholders
csv: Spreadsheet-compatible format for tracking

Args: format: Output format - 'json', 'html', or 'csv'

Returns: Formatted report content as a string

ParametersJSON Schema

Name	Required	Description	Default
`format`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided; description notes report comes from 'last scan results' and returns a string, but doesn't disclose prerequisites, side effects, or permissions.

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?

Very concise with a clear sentence, bullet list of formats, and labeled args section. Every sentence adds value.

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 one parameter and output schema present, description explains return type and formats. Missing error handling or prerequisites, but adequate for a simple export tool.

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

Parameters5/5

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

The single parameter 'format' has no schema description (0% coverage), but the description adds full value by listing accepted formats ('json', 'html', 'csv') and their meanings.

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 exports an accessibility report in specified formats. It uses specific verbs and resource, and lists formats, but could better distinguish from sibling 'get_full_report'.

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 on when to use this tool versus alternatives like 'get_full_report' or 'get_violations'. The description only implies it uses last scan results.

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

get_full_reportA

Get complete accessibility report from the last scan.

Includes violations, passes, incomplete checks, and inapplicable rules. Use this for comprehensive analysis of accessibility compliance.

Returns: Complete scan results including all categories (violations, passes, incomplete, inapplicable)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided. The description implies it reads from the last scan but doesn't disclose side effects (e.g., whether it triggers a new scan) or read-only nature. Return content described but behavioral traits missing.

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?

Short and to the point, but slightly redundant (first sentence and second paragraph cover same ground). Still efficient for an agent.

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?

Explains return content well, but doesn't clarify prerequisites (e.g., that a scan must have been performed). With output schema existing, minor gap.

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?

Zero parameters. Baseline 4 applies as schema coverage is 100%. Description adds no param info but doesn't need to.

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 it retrieves a complete accessibility report from the last scan, listing included categories (violations, passes, etc.). It differentiates from siblings like get_violations by specifying comprehensiveness.

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?

Explicitly says 'use this for comprehensive analysis,' but lacks guidance on when not to use (e.g., if only violations needed, use get_violations). No alternative suggestions.

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

get_violationsA

Get detailed list of violations from the most recent scan.

Returns full violation details including affected elements, WCAG references, and remediation guidance.

Returns: List of violations with complete details including affected HTML elements

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses return details: 'full violation details including affected elements, WCAG references, and remediation guidance'. With no annotations, this provides adequate behavioral transparency. No mention of side effects, but it is a read operation.

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 concise but has slight redundancy by repeating 'Returns' in a separate line. The first sentence is clear and front-loaded. Could be tighter, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, a known output schema, and the description detailing what is returned, the tool definition is complete. For a simple retrieval tool, all necessary context is provided.

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?

The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter information. Baseline for 0 parameters is 4, and the description's mention of 'from the most recent scan' adds context about implicit behavior.

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 retrieves a 'detailed list of violations from the most recent scan'. The verb 'Get' and resource 'violations' are explicit, and it distinguishes from sibling tools like 'get_full_report' (broader) and 'scan_page' (triggers scan).

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 after a scan but does not specify when to use versus alternatives like 'get_full_report' or why not to use it. No explicit when-to-use or when-not-to-use guidance.

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

scan_elementA

Scan a specific element on the current page for accessibility issues.

Must be called after scan_page() has loaded a page. Runs axe-core on just the specified element and its descendants.

Args: selector: CSS selector for the element to scan (e.g., '#main-nav', '.form-container')

Returns: Accessibility scan results for the specified element

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

Describes that axe-core runs on the specified element and its descendants, and returns accessibility scan results. No annotations are present, so the description carries full burden; it adequately discloses the tool's behavior without contradictions.

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 concise: a brief purpose statement, a clear prerequisite note, a parameter explanation with examples, and a return summary. Every sentence adds value, and it is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present (context signals indicate 'Has output schema: true'), the description need not detail return values. It covers the prerequisite, usage, and parameter adequately for a simple tool.

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

Parameters5/5

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

The only parameter 'selector' lacks schema description, but the description adds 'CSS selector for the element to scan (e.g., '#main-nav', '.form-container')', providing clear semantic meaning and 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 'Scan a specific element on the current page for accessibility issues.' It specifies a specific verb and resource, and distinguishes from the sibling tool 'scan_page' by noting the prerequisite of calling scan_page first.

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?

Explicitly states 'Must be called after scan_page() has loaded a page,' providing clear when-to-use guidance. While it doesn't list alternatives or when-not-to, the context is sufficient for typical use.

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

scan_pageA

Navigate to a URL, bypass Cloudflare if present, and run an accessibility scan.

This tool uses an anti-detect browser (Camoufox) that can bypass Cloudflare protection, then injects axe-core and runs a full accessibility audit.

Args: url: The URL to scan for accessibility issues wcag_level: WCAG conformance level (A, AA, AAA, 21A, 21AA, 22AA). Default: AA wait_for_cloudflare: Wait for Cloudflare challenges to complete. Default: True

Returns: Summary of accessibility scan including violation counts by severity

ParametersJSON Schema

Name	Required	Default
`url`	Yes
`wcag_level`	No	AA
`wait_for_cloudflare`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the use of an anti-detect browser for Cloudflare bypass and axe-core injection, but lacks details on failure handling or timeouts. Still, the core behavior is transparent.

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 concise and well-structured: a one-sentence summary, a paragraph detailing technology, and a clean Args list. Every sentence adds value without fluff.

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 presence of an output schema and the tool's complexity (Cloudflare bypass, axe-core), the description covers essential behaviors and return values. Minor gaps exist in failure scenarios, but overall it is complete enough.

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

Parameters5/5

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

The Args section defines each parameter's meaning, defaults, and role (e.g., wcag_level default AA, wait_for_cloudflare default True). This compensates fully for the 0% schema description coverage.

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 navigates to a URL, bypasses Cloudflare, and runs an accessibility scan using axe-core. This specific verb+resource combination distinguishes it from siblings like scan_element.

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 use for Cloudflare-protected pages and full accessibility audits, but does not explicitly guide when to use this tool over siblings like scan_element or configure_rules.

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

set_wcag_levelA

Set WCAG conformance level for accessibility testing.

Available levels:

A: WCAG 2.0 Level A (minimum accessibility)
AA: WCAG 2.0 Level AA (standard compliance target, recommended)
AAA: WCAG 2.0 Level AAA (enhanced accessibility)
21A: WCAG 2.1 Level A
21AA: WCAG 2.1 Level AA
22AA: WCAG 2.2 Level AA (latest standard)

Args: level: WCAG level code (A, AA, AAA, 21A, 21AA, 22AA)

Returns: Confirmation of WCAG level setting with tags that will be used

ParametersJSON Schema

Name	Required	Description	Default
`level`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It notes that the tool returns a confirmation with tags, but does not disclose side effects, prerequisites, or persistence behavior. As a setter, this is adequate but not exhaustive.

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 concise and well-structured: a brief purpose statement, a formatted list of level options, and clearly labeled 'Args' and 'Returns' sections. Every element adds value without redundancy.

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 simplicity (one parameter, output schema exists), the description covers available levels and return value. However, it omits whether the setting is session-persistent or page-specific, which would fully contextualize the tool's effect.

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

Parameters5/5

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

The input schema provides only a string type for 'level' with 0% description coverage. The description significantly enriches this by listing all valid values (A, AA, AAA, 21A, 21AA, 22AA) with explanatory context, adding essential meaning beyond the schema.

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 sets WCAG conformance levels for accessibility testing, with a specific verb ('Set') and resource ('WCAG conformance level'). It lists available level options, distinguishing it from sibling tools like scan_page or configure_rules.

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 provides the available level options but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context (e.g., set before scanning) is implied rather than explicit.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.1Jun 11, 2026
- First observedconfigure_rules
- First observedexport_report
- First observedget_full_report
- First observedget_violations
- First observedscan_element
- First observedscan_page
- First observedset_wcag_level

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

All tools have clearly distinct purposes: configuration (rules and WCAG level), scanning (page and element), and result retrieval (full report, violations, export). No ambiguous overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., configure_rules, scan_page, get_violations), making the tool set predictable.

Tool Count5/5

Seven tools cover the essential workflow of accessibility testing: configuration, scanning, and reporting. The scope is appropriate without unnecessary tools.

Completeness4/5

Core workflows are covered, but minor gaps exist: there is no tool to retrieve current configuration (e.g., enabled rules or WCAG level) or to list available rules, which could hinder agents needing to inspect settings.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

accessibility-ai A
io.github.groundlogic-ai-source
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Testing & QA Tools Legal & Compliance AI & Machine Learning
421
wcagc — accessibility scanningOAuth
io.github.WCAG-Compliance
Deterministic axe-core accessibility scans (WCAG 2.1 AA, EN 301 549, PDF/UA) via your account.
Testing & QA Tools Developer Tools
2
Sitejar Web Compliance Scanner
app.sitejar
Scan a web page for accessibility, security, privacy, quality and SEO issues, with fixes.
Legal & Compliance Security Testing & QA Tools
1
dropcoin-a11y A
io.github.freshfos
Accessibility pre-checks (WCAG/BFSG) in a real browser + statement drafts. Pay per call.
Testing & QA Tools Browser Automation
21

Related MCP Servers

MCP Accessibility Scanner
Browser Automation Testing & QA Tools
JustasMonkev
A
license
B
quality
A
maintenance
Enables automated web accessibility scans for WCAG compliance using Playwright and Axe-core, providing visual and JSON reports with remediation guidance.
Updated 18 hours ago (2026-09-05 12:22 UTC)
25
3,068
56
MIT
Accessibility MCP Server
Browser Automation Testing & QA Tools Web Scraping
jbuchan
F
license
B
quality
D
maintenance
Enables AI agents to perform comprehensive accessibility audits on websites using Playwright and axe-core against WCAG standards. Provides detailed compliance reports with violation summaries and remediation guidance across multiple browsers.
Updated a year ago (2025-10-07 01:03 UTC)
3
-
Accessibility Testing MCP
Testing & QA Tools Web Scraping Browser Automation
joe-watkins
F
license
A
quality
D
maintenance
Enables accessibility testing of websites and HTML content using axe-core and IBM Equal Access engines. Supports WCAG compliance checking, multi-viewport testing, and provides detailed violation reports with remediation guidance.
Updated 9 months ago (2025-12-07 09:01 UTC)
5
1
-
aria51 MCP Server
Browser Automation Testing & QA Tools Developer Tools
justinleeirizarry
A
license
Not graded
quality
B
maintenance
Enables AI coding assistants to test web accessibility by scanning URLs, detecting violations, and running focused audits on keyboard navigation, screen reader compatibility, and WCAG criteria — all within the assistant's loop.
Updated 7 days ago (2026-08-30 09:45 UTC)
MIT

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/antonio-rmrz/a11y-mcp'

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

a11y-mcp

Install

Configuration

Tools

Usage

WCAG Levels

Cloudflare Bypass

Requirements

Troubleshooting

Development

License

Credits

Related Projects

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API