Accessibility checks for your AI coding agent
Add the AccessLumens MCP server to Claude Code, Cursor, GitHub Copilot or any MCP client. Your agent scans the page it is building for WCAG 2.2 issues, fixes the code, and scans again to prove it. Free, it runs on your machine, and it works on localhost.
npx -y @accesslumens/mcp- Free, including commercial use
- No account or API key
- Runs locally
- On the official MCP Registry
See an agent fix a page from 75 to 100
Claude Code scans a local dev server, fixes the source and rescans. axe DevTools checks the result. One minute, with captions and voiceover.
Also on YouTube, with switchable captions.
Read the transcript, with what is on screen
Here's a demo shop page. It looks fine. But is it accessible?
On screen: A demo outdoor-gear shop, Trailhead Outfitters, with a hero banner and three product cards.
axe DevTools finds 26 issues.
On screen: The axe DevTools browser extension scans the page: 26 automatic issues (6 critical, 10 serious, 9 moderate, 1 minor), including buttons without discernible text, low contrast and a missing page language.
Now in Claude Code, with the free AccessLumens MCP server, I just ask the agent to check the page.
On screen: VS Code with the Claude Code panel open. The prompt reads "check accessibility on http://localhost:5173/".
It runs a real scan of localhost, in a headless browser on my machine.
On screen: The agent calls the AccessLumens check_accessibility tool. Its result: score 75/100, high risk, with 3 critical, 5 serious and 4 moderate issue types.
75 out of 100. Missing labels and low contrast, plus things axe doesn't test: controls you can't reach by keyboard, no visible focus, and sideways scrolling at 320px.
On screen: The agent's summary: an icon button with no name, an email field with no label, a social link with no name, no visible focus indicator on 7 elements, low text contrast on 5 elements, five clickable divs that cannot be reached by keyboard, no page language, and horizontal scrolling at 320px.
Then two words: "Fix them."
On screen: The prompt "Fix them" is sent.
It fixes the source code: real buttons instead of clickable divs, labels and landmarks. Every "Add to cart" button gets the product name for screen readers.
On screen: The agent reads the component files and edits them, including a skip link and landmark styles.
Then it rescans to prove it: 100 out of 100.
On screen: The rescan reports 100/100 with no issues, and the agent lists what it changed and what still needs a person to check.
And axe DevTools agrees: zero issues.
On screen: axe DevTools re-runs on the same page: 0 automatic issues.
AccessLumens MCP: free, and it runs on your machine.
On screen: A closing card: "AccessLumens MCP. Free accessibility checks for your AI coding agent", the install command npx -y @accesslumens/mcp, and accesslumens.com.
What your agent gets
The same scanner as accesslumens.com: axe-core plus our own checks for what axe does not test.
- WCAG 2.2 Level AA checksaxe-core, the engine most accessibility tools build on, run in a real browser.
- Controls you cannot reach by keyboardClickable divs, keyboard traps and anything Tab skips. axe does not test these.
- Focus you cannot seeElements where the focus outline was removed and nothing replaced it.
- Reflow at 320pxPages that scroll sideways when zoomed or on a narrow screen.
- Names a screen reader cannot tell apartThree identical "Add to cart" buttons, alt text that repeats the heading beside it, an aria-label that drops the visible words.
- A fix for every issueThe exact element, why it fails, how to fix it and the WCAG criteria, so the agent edits the right line.
Private by design. Every scan runs in a headless browser on your machine. It works on localhost, staging URLs, public sites and plain .html files, and nothing is sent to AccessLumens.
Set it up, step by step
About two minutes. You need Node.js and an editor with an AI agent that supports MCP.
Check you have Node.js 18.17 or later
Run this in a terminal. If it prints v18.17 or higher you are set; if not, install the LTS version from nodejs.org.
Node version checknode --versionDownload the scanning browser once
The scanner uses a headless Chromium (about 150 MB). Downloading it now means your first scan does not wait for it, and your editor will not time out on the first start.
Browser download commandnpx -y @accesslumens/mcp installAdd the server to your editor
Pick yours. Each one starts the same server with npx, so you always get the latest version.
Claude Code
Run this in your project folder:
Claude Code commandclaude mcp add accesslumens -- npx -y @accesslumens/mcpOn Windows (not WSL), wrap npx in cmd so Claude Code can start it:
Claude Code command for Windowsclaude mcp add accesslumens -- cmd /c npx -y @accesslumens/mcpCursor, Windsurf, Claude Desktop and most other clients
Add this to the client's MCP config file. In Cursor that is .cursor/mcp.json in your project.
MCP config for Cursor and other clients{ "mcpServers": { "accesslumens": { "command": "npx", "args": ["-y", "@accesslumens/mcp"] } } }VS Code with GitHub Copilot
Save this as .vscode/mcp.json in your project, then click Start above the server name.
VS Code mcp.json{ "servers": { "accesslumens": { "type": "stdio", "command": "npx", "args": ["-y", "@accesslumens/mcp"] } } }Check it is connected
Your editor's MCP list should show accesslumens as connected, with two tools. In Claude Code, type /mcp. If it shows as failed or stuck connecting the very first time, reconnect it once: the first start downloads the package.
Start your dev server and ask
In plain words, with your own address. The agent calls the scanner by itself.
Example promptCheck http://localhost:3000 for accessibility issues and fix them.Or run a ready-made workflow
The server ships three workflows (MCP prompts) that tell the agent how to fix well: in the source, native HTML before ARIA, shared causes fixed once, design unchanged, and every fix confirmed by a rescan. In Claude Code, type / and pick accesslumens:fix-all. Some clients, including some Copilot versions, do not list MCP prompts; there, just ask.
- fix-page
- Scans one page, fixes every issue in the source, rescans until no Critical or Serious issues remain, and lists what it changed.
- fix-all
- Two passes over every route in your app: fixes what the scanner finds, then reviews the code for what scanners cannot detect, such as focus in dialogs, route-change announcements, form errors and reduced motion.
- audit
- The same review without changing any files: issues grouped by root cause, with the file each one comes from and an ordered fix plan.
Review what a scanner cannot judge
Issues marked "needs human review" need a person to confirm. Before you ship, tab through the page yourself and try it with a screen reader. A score of 100 means no automated failures, not full WCAG conformance.
The tools your agent can call
- check_accessibility
- Scans a URL, a localhost address or a local .html file. Returns a 0-100 score and each issue with its severity, WCAG criteria, fix, and every failing element. Options: keyboard checks (on by default), crawl (follow links, up to 10 pages) and max_issues (default 30).
- explain_issue
- Explains a rule from a scan result: what it means, who it affects, how to fix it, and the WCAG criteria with links to W3C.
Common questions
What is an MCP server?
MCP (Model Context Protocol) is the open standard AI coding agents use to call outside tools. Adding the AccessLumens MCP server gives your agent two new tools: one that scans a page for accessibility issues, and one that explains a rule. The agent decides when to call them, reads the results and edits your code.
Is it really free?
Yes. The MCP server is free to use, including for commercial work, with no account, no API key and no usage limit. It runs on your own machine, so there is no server cost for us to pass on. The license does not allow redistributing or reselling it.
Does my code or my page get sent to AccessLumens?
No. The scan runs in a headless browser on your machine and the results go straight to your agent. Nothing is sent to AccessLumens. Your agent's own model provider sees the results the way it sees any tool output.
Which editors and agents does it work with?
Any MCP client that can start a local (stdio) server: Claude Code, Cursor, Windsurf, Claude Desktop, VS Code with GitHub Copilot, and others. The setup steps above cover the common ones; most other clients take the same JSON block.
Can it scan localhost, staging and pages that are not public?
Yes. It scans whatever your machine can open: a dev server on localhost, a staging URL on your network, a public site, or a plain .html file. It opens the page as a fresh browser would, so a page behind a sign-in is out of reach. Scan a local copy, or use a user journey on accesslumens.com for signed-in flows.
How is this different from other axe-core MCP servers?
Most of them run axe-core and stop there. This runs axe-core plus the checks axe does not do: controls you cannot reach by keyboard, keyboard traps, focus you cannot see, sideways scrolling at 320px, and names a screen reader cannot tell apart. Its results also carry fix guidance written for an agent, and it ships ready-made fix and audit workflows. It is the same scanner as accesslumens.com.
Does a score of 100 mean my site is WCAG compliant?
No. Automated testing finds roughly a third of WCAG issues. A clean scan is a good start, not proof of conformance. Issues marked "needs human review" need a person to confirm, and things like a sensible reading order or good alt text still need a human eye.
The server shows as failed or stuck on "Connecting" the first time. What now?
The very first start downloads the package and can take more than 30 seconds, which some clients, Claude Code among them, treat as a failed connection. Reconnect it once (in Claude Code, type /mcp and pick accesslumens). Later starts take a few seconds. Running the browser download command in step 2 first also helps.
Why does a scan of a live site fail?
Sites behind bot protection, such as Cloudflare, can block headless browsers. Scan a local or staging copy of the same page instead. Set ACCESSLUMENS_DEBUG=1 in the server's environment to log what the scanner saw.
What do I need installed?
Node.js 18.17 or later. The scanner uses a headless Chromium, which it downloads once (about 150 MB). If you would rather not install anything, a Docker image with Chromium bundled is described in the GitHub repository.
Where do I report a bug or ask for a feature?
Open an issue on the GitHub repository, or write to support@accesslumens.com. The repository holds the listing and the Dockerfile; the server itself ships on npm.
Need a report to share?
The website scan gives a scored, shareable report with your legal context (ADA, EAA, Section 508), full-site crawls and journeys through signed-in flows.
Scan a websiteGot PDFs too?
Check a PDF against WCAG 2.2 and PDF/UA, or upload one and get a repaired, tagged version back.
Fix a PDF