Skip to main content
Glama
enesjakozh
westsideori

Cursor A11y MCP

by westsideori
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Cursor A11y MCP

A Model Context Protocol (MCP) server that provides accessibility testing capabilities AI agents. This tool helps identify accessibility issues in web applications using axe-core and Puppeteer.

Features

  • Run accessibility tests on any URL or local development server

  • Powered by axe-core for comprehensive accessibility testing

  • Provides detailed violation reports including:

    • Impact level

    • Description of the issue

    • Help text and documentation links

    • Affected HTML elements

    • Failure summaries

Related MCP server: Web Accessibility MCP Server

Project Structure

  • src/ - Source code for the MCP server and accessibility testing tool

  • test-site/ - A React application with intentional accessibility issues for testing

  • build/ - Compiled version of the source code

Installation

npm install

Then install the test site dependencies:

cd test-site
npm install
cd ..

Usage

Starting the MCP Server

npm run build
npm start

Running the Test Site

npm run start:test-site

The test site will be available at http://localhost:5000.

Running Accessibility Tests

The tool accepts two types of inputs:

  1. A full URL to test

  2. A relative path that will be appended to http://localhost:5000

Dependencies

  • @modelcontextprotocol/sdk: ^1.4.1

  • puppeteer: ^24.1.1

  • zod: ^3.24.1

Test Site Dependencies

  • react: ^18.2.0

  • react-dom: ^18.2.0

  • react-scripts: 5.0.1

Development

  1. Make changes to the source code in the src/ directory

  2. Run npm run build to compile the changes

  3. Start the server with npm start

Configuring in Cursor

To add this accessibility testing tool to Cursor's MCP Server settings:

  1. Open Cursor's Settings (⌘ + ,)

  2. Navigate to "Features" > "MCP Servers"

  3. Add a new MCP Server with the following configuration:

    • Name: a11y

    • Select command from the dropdown

    • Command: node path/to/cursor-a11y-mcp/index/file/in/build/folder (Replace path/to/cursor-a11y-mcp/index/file/in/build/folder with the absolute path to your index.js file in the build folder.)

  4. Click Add

  5. The accessibility testing tool will now be available in Cursor's Composer

Usage in Composer

To use the accessibility testing tool in Cursor's Composer:

  1. Run in your terminal:

npm run start:test-site

This will start the test site at http://localhost:5000

  1. In Cursor's Composer, type use a11y tool

  2. Composer will prompt you to run the tool

  3. After running the tool, you will see the accessibility violations in the response, and code actions to fix the violations

  4. The Composer may prompt you to use the tool again to confirm that the violations are fixed

License

This project is licensed under the MIT License - see the LICENSE file for details.

Version

Current version: 2.0.1

Available Tools

1 tool
a11yB

Run accessibility tests on a URL or a local path (relative URL appended to http://localhost:5000).

ParametersJSON Schema
NameRequiredDescriptionDefault
relativePathNoRelative path appended to http://localhost:5000
urlNoFull URL to test

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the local path behavior (appended to localhost:5000), which is useful, but doesn't disclose critical behavioral traits like what the tests actually do, whether they're destructive, what permissions are needed, rate limits, or output format. This leaves significant gaps for an agent.

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 a single, efficient sentence that front-loads the core purpose and includes essential details without any wasted words. Every element serves a clear purpose in conveying the tool's functionality.

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?

Given no annotations and no output schema, the description is incomplete for a testing tool. It doesn't explain what accessibility tests are run, what the results look like, error conditions, or behavioral constraints. This leaves the agent with insufficient context to use the tool effectively.

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 100%, so the schema already documents both parameters fully. The description adds marginal value by clarifying the local path behavior (appended to localhost:5000), but doesn't provide additional syntax, format details, or usage examples beyond what the schema states.

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 specific action ('Run accessibility tests') and the target resources ('on a URL or a local path'), with no siblings to distinguish from. It uses precise verbs and identifies the exact scope of operation.

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 context by specifying the two input types (URL or local path), but doesn't provide explicit guidance on when to choose one over the other or mention any prerequisites. With no sibling tools, this is adequate but lacks detailed decision criteria.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'a11y' has a clear and distinct purpose focused on accessibility testing.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'a11y' is concise and descriptive, and there are no other tools to compare it against for consistency.

Tool Count2/5

A single tool is too few for a server named 'Cursor A11y MCP', which suggests a broader accessibility domain. While the tool is functional, the set lacks coverage for other common accessibility tasks like reporting, fixing issues, or checking compliance, making it feel thin and incomplete.

Completeness2/5

The tool surface is severely incomplete for an accessibility domain. It only provides testing on URLs or local paths, missing essential operations such as generating reports, analyzing results, fixing issues, or supporting different accessibility standards, which will limit agent effectiveness.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/westsideori/cursor-a11y-mcp'

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