@webability/mcp
The server provides accessibility scanning, fixing, verification, and audit/site-management capabilities for coding agents.
Scan any URL or localhost with
scan_page(axe-core + WebAbility engines), including WCAG/level/rule/severity/viewport filters and structuredfix.op/fixabilitydata; get source pointers on React ≤18/Vue dev builds.Scan multi-page journeys with
flow_scan, raw HTML snippets withscan_html, and detect frameworks/CSS toolkits withdetect_framework.Generate framework-aware fixes with
generate_ai_fix, check contrast withcheck_color_contrast, validate ARIA withcheck_aria, and list rules withget_rules.Close the loop with
verify_fixfor a single element anddiff_scanfor baseline-vs-current regressions.Run vision-based checks via
visual_auditand full server-side audits/reports viastart_auditandget_audit(free account needed on hosted server).Manage WebAbility sites and widget installs via
add_site,list_sites,get_install_snippet, andcreate_upgrade_link.Use local-only helpers:
find_source,scan_history, andgenerate_report_pdf.
Provides accessibility testing and fix generation for BigCommerce stores.
Generates framework-aware accessibility fixes for Bootstrap components.
Provides accessibility testing and fix generation for HubSpot websites.
Generates framework-aware accessibility fixes for Material-UI components.
Generates framework-aware accessibility fixes for Next.js projects.
Provides accessibility testing and fix generation for Shopify stores.
Provides accessibility testing and fix generation for Squarespace websites.
Provides accessibility testing and fix generation for Webflow websites.
Generates framework-aware accessibility fixes for WordPress sites.
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., "@@webability/mcp scan https://example.com for accessibility issues"
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.
WebAbility MCP
Accessibility checks your coding agent can act on: scan a page with two engines, get a structured fix for each issue, then re-check that the fix landed.
Free. Hosted at https://mcp.webability.io/mcp. No API key for scans. MIT.
Install
Claude Code (plugin)
/plugin marketplace add snayyar00/webability-mcp
/plugin install webability-accessibility@webabilityor claude mcp add --transport http webability https://mcp.webability.io/mcp
Cursor: Add to Cursor
VS Code: Install in VS Code · or run
code --add-mcp '{"name":"webability","type":"http","url":"https://mcp.webability.io/mcp"}'
Claude.ai / ChatGPT / any MCP client: add a custom connector with the URL https://mcp.webability.io/mcp.
Local (the browser runs on your machine, so it scans localhost directly): npx -y -p @webability/mcp webability-mcp
Related MCP server: A11y Expert MCP
What you get back
Real output, scan_page on https://demo.vercel.store (trimmed):
Found 16 high-confidence issue(s): 0 critical, 4 serious, 8 moderate, 4 minor.
20 additional finding(s) need human review — see incomplete[]. Do NOT auto-fix these.
missing_label · serious · WCAG 1.3.1 · input.text-md.w-full.rounded-lg
fix: { op: "add-attribute", attribute: "aria-label" } fixability: contextual
missing_table_scope · moderate · WCAG 1.3.1 · thead > tr > th:nth-of-type(1) (vite.dev/guide)
fix: { op: "add-attribute", attribute: "scope", value: "col" } fixability: mechanical
verify_fix input.text-md.w-full.rounded-lg wcag=4.1.2
NOT RESOLVED: 1 violation still present → "verified": falsefix.opis one ofadd-attribute,set-attribute,remove-attribute,add-element,remove-element,add-text-content,suggest.fixability:mechanical= apply as given.contextual= the op is known, the value (alt text, a label) needs judgment.visual= needs rendered output; propose, do not auto-apply.judged[]lists findings the scanner settled itself, each with a verdict and a reason (see Output below). Anything it cannot settle is dropped.source: on React ≤18 and Vue dev builds, each issue carries{file, line, column, component}from the live component tree.verify_fixre-scans one element and fails closed.diff_scanreportsfixed[],new[],remaining[]for a page.
Free
What you get | |
No account | Scan and check tools on the hosted server. Fair-use limits per IP: 30 browser scans/h, 10 AI fixes/h |
Free account (OAuth prompt in your client, or | Adds |
No trial, no credits, no paid tier on the MCP.
What it does not do
It cannot judge if alt text is meaningful or if a custom widget makes sense with a screen reader. Use it to clear the automated layer in source, then test with assistive technology.
Local vs hosted
Lite — local stdio ( | Full — hosted ( | |
Account | None | None for scan tools; free account (OAuth sign-in) for visual and full audits |
Scan / fix / verify | Yes (on your machine) | Yes |
AI judge for uncertain findings | Off until you set | On, nothing to set (our key) |
| Yes | No |
| Yes | No |
| Listed as stubs → connect Full (still free) | Yes — free with your account |
PostHog / dashboard analytics | Optional env only | On by default on hosted |
| Yes — the browser runs on your machine | Via a tunnel — see below |
Scanning a local dev server
Use Lite (stdio). It runs the browser on your machine, so http://localhost:3000 is just localhost:
claude mcp add webability-local -- npx -y -p @webability/mcp webability-mcpOther clients: add npx -y -p @webability/mcp webability-mcp as a stdio server.
Full (hosted) cannot reach your machine directly, by design. It runs in our cloud, so localhost there means our localhost. Every URL is checked before any fetch and loopback / private / link-local addresses are refused: without that check, anyone could point the server at internal services or a cloud metadata endpoint. That check is not relaxed for anyone.
When you need hosted: webability-tunnel
CI, a remote agent, or a dashboard-triggered scan cannot run Lite, because there is no laptop in the loop. For those, open a tunnel:
WEBABILITY_API_KEY=<your-token> npx -y -p @webability/mcp webability-tunnel --port 3000It prints a https://tunnel.webability.io/t/<id>/ URL and a secret. Pass the URL as url and the secret as tunnel_secret:
"Scan https://tunnel.webability.io/t/abc123.../ with tunnel_secret <secret>"
Your machine dials out to the relay, so the URL is an ordinary public hostname and the SSRF check above still applies unchanged — nothing is weakened to make this work. Same idea as ngrok, with three differences that matter when the thing on the far side is your dev machine:
The URL is not a credential. Every request must carry the secret header; the URL alone returns 401. URLs leak into shell history, CI logs and screenshots.
Only
GETandHEADreach you, on the one port you named, andAuthorization/Cookieare stripped before anything crosses in.It dies when you do. 30 minutes, 5 minutes idle, or the moment you press Ctrl-C.
Anyone holding both the URL and the secret can read your dev server. Treat the pair like a password, and prefer Lite whenever there is a human at a keyboard.
Third-party tunnels (ngrok, cloudflared) also work — the hosted scanner treats their hostnames like any other public site — but they expose your dev server to anyone who learns the URL. Vite users, either way: add the tunnel hostname to server.allowedHosts, or it answers 403 Blocked request to everything.
start_audit is the exception on both transports — its pipeline runs on our servers even under Lite, so it can never reach a localhost URL.
Local options
Optional env:
WEBABILITY_API_URL(defaulthttps://api.webability.io) for self-hosted backends.POSTHOG_PROJECT_API_KEYorPOSTHOG_API_KEYto enable PostHog MCP Analytics for MCP initialize, tools/list, and tool-call usage events.POSTHOG_HOST(defaulthttps://us.i.posthog.com) for EU or self-hosted PostHog ingestion.WEBABILITY_POSTHOG_MCP_ANALYTICS=offto force-disable PostHog MCP Analytics even when a PostHog key is present.
Scan engines
scan_page runs two engines in parallel and deduplicates the results:
Engine | Rules | What it covers |
WebAbility detectors | 60+ | Gradient-aware contrast, weak names, decorative icons, landmark hierarchy, ARIA correctness, link consistency, target size, keyboard traps |
axe-core | 104 | Industry-standard WCAG 2.2 baseline |
Output
Every scan returns:
issues— violations the scanner stands behind, safe to surface as bugssummary— counts by severity
The scanner judges uncertain findings itself. Text on a gradient or image background is measured from rendered pixels. What the engines still cannot decide goes to an AI judge, which returns a violation with a concrete fix (alt text, a colour that meets the ratio) or a pass with its reason (listed in judged[]). Anything neither can settle is dropped — nothing is left for a human to review. Each judge call sends the page URL, the finding's markup and nearby text, and, when the page can take one, a PNG crop of the element.
Hosted (https://mcp.webability.io/mcp): nothing to set. The judge runs on our side with our models, for anonymous and signed-in callers alike: the server posts each uncertain finding to WebAbility's API. If our judge is unreachable, the findings it would have settled are dropped, never guessed.
Local (npx / webability-mcp): the judge is off until you give it a key. It is not local inference: your machine calls the model endpoint with your key (OpenRouter, or the WEBABILITY_JUDGE_BASE_URL you set). Set OPENROUTER_API_KEY to turn it on (vision anthropic/claude-haiku-4.5, text-only deepseek/deepseek-v4-flash; override with WEBABILITY_JUDGE_BASE_URL, WEBABILITY_JUDGE_VISION_MODEL, WEBABILITY_JUDGE_TEXT_MODEL, budget WEBABILITY_JUDGE_TIMEOUT_MS, default 20 s). WEBABILITY_JUDGE=off disables it in both modes. Without a key, the model-free verdicts still run (a measured contrast pass, a decorative or 1x1 image, a reduced-motion rule) and land in judged[]; findings they cannot settle are dropped.
Structured fixes (since v1.6.0)
Every issue from scan_page, flow_scan, diff_scan and scan_html carries a machine-readable fix and a fixability tier, so an agent can act without parsing prose:
{
"id": "wa-missing_button_type-a1b2c3",
"fixability": "mechanical",
"fix": { "op": "add-attribute", "attribute": "type", "value": "button", "currentValue": "", "needsManualReview": false }
}Field | Values |
|
|
|
|
fix.value is present only when the engine already knows it. The legacy fix.attribute / currentValue / suggestedValue / needsManualReview fields are unchanged. get_rules lists the tier for every rule so you can pick the auto-fixable set up front.
Source pointers (since v1.6.0)
On a React ≤18 or Vue dev build, scan_page, flow_scan and diff_scan read the component tree of the live page and attach the JSX call site to each finding:
{ "selector": "img#hero", "source": { "framework": "react", "file": "/app/src/Hero.tsx", "line": 12, "column": 5, "component": "Hero" } }Open that file — no find_source round-trip. React 19 dropped _debugSource; there you still get component. Production builds have no tree; pass sourceRoot (Lite only) and issues without a pointer get sourceCandidates[] from a token grep of the selector.
Output controls (since v1.6.0)
scan_page, flow_scan, scan_html and diff_scan accept:
Param | Effect |
|
|
| keep only these rule ids ( |
| keep only these criteria; a prefix like |
| one line per element, rule metadata printed once — a fraction of the JSON tokens |
Filters apply before the 50-item cap, so minImpact: "serious" returns every serious issue on a 300-issue page. The scan_history archive keeps the unfiltered result.
In-process scan_html (since v1.6.0)
scan_html no longer launches a browser by default. It runs the WebAbility detectors and axe-core inside jsdom in the MCP process — milliseconds, no network — and returns the same issues / judged / summary shape as scan_page, with fix.op on every finding. Fragments are wrapped into a document automatically. jsdom has no layout, so visual-tier rules (contrast, target size, focus ring) are skipped and counted in skippedVisual; pass engine: "browser" for the previous headless-Chromium axe path.
Tools
Tool | Edition | What it does |
| Lite + Full | Scan a URL for WCAG accessibility issues (2 engines). |
| Lite + Full | Multi-page journey scan with deduplicated issues across pages |
| Lite + Full | Scan a raw HTML snippet or fragment in-process (jsdom, ms, no browser); |
| Lite + Full | Detect Tailwind / MUI / Bootstrap / Next.js / WP / plain CSS |
| Lite + Full | Framework-aware fix alternatives. Auto-extracts brand palette from the live URL on contrast issues. |
| Lite + Full | Re-scan a fixed element and confirm the violation is gone — |
| Lite + Full | Baseline vs current → |
| Lite + Full | WCAG contrast check on a color pair; pass |
| Lite + Full | Validate ARIA attributes in an HTML snippet |
| Lite + Full | List axe-core + WebAbility rules with |
| Lite only | Map a CSS selector back to local source files (fallback when the page has no framework |
| Lite only | Browse prior local scans under |
| Lite only | Turn scan findings into a branded WebAbility accessibility-report PDF saved next to the project — free, no account. Pass the |
| Full (free w/ account; stub on Lite) | Pixel-level audit via vision (icon contrast, focus visibility, looks-like-a-button-but-isn't) |
| Full (free w/ account; stub on Lite) | Kick off the full server-side audit deliverable (report + Excel workbook). Returns an id to poll. |
| Full (free w/ account; stub on Lite) | Check an audit's progress and, once complete, get the severity summary + report/workbook download URLs. |
When to use this MCP
Building a new component and want it accessible from day one
Auditing a localhost / staging build before pushing
Triaging a Lighthouse / axe report —
scan_pageconsolidates both enginesGenerating fix suggestions that match the framework you're already using
Checking color contrast against the user's actual brand palette (not generic suggestions)
Examples
In Cursor / Claude Code:
"Scan localhost:3000 for accessibility issues"
"Walk login → dashboard → checkout and report unique issues across the flow"
"Suggest a fix for the contrast issue on
.btn-primaryon https://example.com — match their brand colors"
"What does WCAG 1.4.11 check?"
"Turn the issues you just found on localhost:3000 into a branded PDF report"
Privacy, scan logs & telemetry
Every scan is logged locally to ~/.webability/scans/ — a one-line-per-scan index.jsonl ledger plus the full result of your last 500 scans. Browse them with the scan_history tool ("what did we scan earlier?") or plain jq. Set WEBABILITY_SCAN_LOG=off to disable, WEBABILITY_SCAN_LOG_DIR to relocate.
The server also reports one small telemetry event per tool call (every tool, not just scans) to the WebAbility API: tool name, a short target label (URL, selector, issue type — never page content), pass/fail, duration, issue counts, and a persistent anonymous install ID. Full scan results, HTML, and generated fix code never leave your machine via telemetry. Set WEBABILITY_SCAN_TELEMETRY=off to opt out.
If POSTHOG_PROJECT_API_KEY or POSTHOG_API_KEY is configured, the server additionally enables PostHog MCP Analytics. This captures MCP usage metadata such as initialize, tools/list, tool name, duration, client name/version, and success/failure. WebAbility strips PostHog's $mcp_parameters and $mcp_response fields before send, so raw HTML snippets, screenshots, scan responses, and generated code are not sent to PostHog by this integration.
Two tools — generate_ai_fix and visual_audit — additionally send page content (an HTML snippet or a screenshot) to WebAbility's API so it can call a third-party LLM on your behalf; WebAbility doesn't store that content, but the LLM provider sees it in transit. generate_report_pdf (local only) sends the findings you pass it, with their HTML snippets, selectors and the page URL, to WebAbility's API to render the PDF. The AI judge (see Output above) also sends page content for uncertain findings: the page URL, the finding's markup and nearby text, and an element crop. Hosted, it goes to WebAbility's API; local, it goes only to the model endpoint you configured with your own key, and only once you set one. See PRIVACY.md for the full per-tool breakdown and WebAbility's privacy policy.
Links
WebAbility — platform, widget, dashboard
License
MIT
Available Tools
20 toolsadd_siteAdd a site to the accountAInspect
Add a website to the signed-in WebAbility account. The site gets the full widget for its first 30 days and a first scan. Returns the site id and plan tier. Next: put the get_install_snippet tag on the site, and use create_upgrade_link to get a payment link for the WebAbility Pro plan. Needs a free WebAbility account (an AI agent can sign itself up with "Sign in with AgentID").
Inputs: url (required).
check_ariaValidate ARIA in HTML or on a pageARead-onlyIdempotentInspect
Validate ARIA attribute + accessible name/role/value usage — in an HTML snippet (html) or on a live page (url), optionally limited to one element and its descendants (selector). Runs axe-core cat.aria and cat.name-role-value rules (aria-* attribute correctness, role validity, required parents/children, aria-hidden-focus, accessible names). Returns violations. A selector that matches nothing, or a page that answers an HTTP error, is an error — never "no violations". Nodes cap at 5 per rule by default — every rule reports nodesTotal + truncated; raise nodeLimit (max 50) or use scan_history(id) for the full set.
Inputs: url, html, selector, nodeLimit.
check_color_contrastCheck color contrastARead-onlyIdempotentInspect
Check text contrast against the WCAG AA threshold (4.5:1, or 3:1 for large text); the AAA verdict is shown only when you pass level: "AAA". Either pass a foreground / background color pair, or pass url + selector to read the element's own text color, background (composited from the nearest painted ancestors), font size and weight from the live page; explicit colors win over the page. A gradient or image background is reported as an error, never a guessed ratio. When it fails, suggests BRAND-aligned replacements — extracts the actual brand palette from the url page using our scanner (CSS vars + most-used colors), or use a provided brandColors array. No url and no brandColors = ratio + pass/fail only.
Inputs: url, level, isBold, fontSize, +4 more.
create_upgrade_linkGet a WebAbility Pro payment linkAInspect
Get a Stripe Checkout link that puts one site on the WebAbility Pro plan (the widget subscription). Give the link to the human who pays (your owner). When they pay, the plan activates on that site automatically; check with list_sites. You never handle card details. The site must be on the account (add_site first). Needs a free WebAbility account.
Inputs: domain (required), billing_interval.
detect_frameworkDetect the site frameworkARead-onlyIdempotentInspect
Detect a page's stack as two separate fields: framework — the application framework, CMS or site builder (e.g. nextjs, nuxt, sveltekit, vitepress, astro, gatsby, wordpress, shopify, mediawiki, vue, react; "unknown" when no signal) — and cssToolkit (tailwind, bootstrap, mui, plain-css). Lists the evidence it used and the value to pass as generate_ai_fix framework. scan_page reports the same two fields from the same detection.
Inputs: url (required).
diff_scanCompare two accessibility scansARead-onlyIdempotentInspect
Compare two scans of the same page and report what changed: fixed[] (in the baseline, gone now), new[] (regressions — not in the baseline, present now), remaining[] (still there). Page-level complement to verify_fix (one element). Baseline is a scan_history id (baselineId, local installs) or a live scan of baselineUrl; current is url (scanned live now) or another history id (currentId). Findings are matched by issue id (rule + element), so a changed class/id on a fixed element reads as fixed AND new — check new[] before calling it a regression. Typical loop: scan_page → edit → diff_scan(baselineId=, url=) → confirm new[] is empty.
Inputs: url, wcag, level, rules, +7 more.
find_sourceFind the source file for a selectorARead-onlyIdempotentInspect
Find source files in the local project that contain a given CSS selector. Maps DOM selectors back to source code so you can edit the right file. Searches React/Vue/Svelte/HTML/PHP/Astro files.
Inputs: selector (required), rootDir.
flow_scanScan a multi-page user flowARead-onlyIdempotentInspect
Scan a multi-page user journey. Walks startUrl plus the autoNavigate URLs sequentially (deterministic — one page fully rendered and scanned before the next), then returns ONE consolidated report with issues deduplicated across pages, each carrying the same fix payload as scan_page. Every requested URL gets an explicit outcome in pages[] (scanned / nav_failed / scan_failed / redirected_duplicate / duplicate_request / skipped_cap / blocked — bot-challenge, not a clean page) — a page is never silently dropped. Better than per-page scans for journeys (login → checkout etc). Without autoNavigate it scans only startUrl, exactly like scan_page.
Inputs: startUrl (required), wcag, level, rules, +5 more.
generate_ai_fixSuggest a framework-aware fixAInspect
Generate framework-aware fix alternatives for a specific accessibility issue. For color contrast issues, returns 3 alternatives (minimal, brand-aligned, high contrast); brand palette is auto-extracted from the live URL using our scanner if brandColors is omitted. For label/ARIA issues, returns 1-2 alternatives. Each alternative includes ready-to-paste code for the detected framework.
Inputs: html (required), issue (required), framework (required), url, +2 more.
generate_report_pdfCreate an accessibility report PDFADestructiveInspect
Turn scan findings into a branded WebAbility accessibility-report PDF, saved next to the project (local installs only). Pass the issues[] array a scan_page call returned plus the page url; the tool groups findings by functionality (Low Vision / Mobility / Navigation / Content / Cognitive), computes the WCAG score with the same penalty ladder as the platform, and renders a shareable PDF — free, no account. Use it when the user wants a deliverable to attach to an email, ticket, or compliance thread. Capped at 500 findings. For the full audit deliverable (Excel workbook + evidence screenshots), use start_audit instead.
Inputs: url (required), issues (required), widgetDetected.
get_auditGet audit status and reportARead-onlyIdempotentInspect
[Full — FREE with a WebAbility account. Not runnable in Lite. Connect hosted MCP at https://mcp.webability.io/mcp (dashboard or Smithery: webability/accessibility), authenticate, then call get_audit.] Check an audit started with start_audit: returns overall status, per-step progress (scan → viewports → screenshots → agent → excel → publish), and — once complete — a severity summary plus short-lived download URLs for the report (JSON) and the Excel workbook. Poll every ~15s while status is pending/running. Only the account that started an audit can read it. Free with a WebAbility account.
Inputs: id (required).
get_install_snippetGet the widget install tagARead-onlyIdempotentInspect
Get the one-line script tag that installs the WebAbility accessibility widget. Put it in the or before of every page of a site added with add_site. The widget finds the site by its domain, so the same tag works on every site. No account needed.
Inputs: no named parameters.
get_rulesList accessibility rulesARead-onlyIdempotentInspect
List accessibility rules from both engines — axe-core (104) and the WebAbility detectors (90+) — with optional filters. Every rule carries fixability (mechanical | contextual | visual) and a fix op template, so you can pick the rules worth auto-fixing before scanning. Returns ruleId, engine, description, help, helpUrl, tags/wcag, fixability, fix.
Inputs: rule, tags, engine, fixability.
list_sitesList the account sites and plansARead-onlyIdempotentInspect
List the sites on the signed-in WebAbility account with each site id, plan tier and the date the current plan ends. Use it to check that a payment activated WebAbility Pro on a site. Needs a free WebAbility account.
Inputs: no named parameters.
scan_historyList past scansARead-onlyIdempotentInspect
Browse past scans run through this MCP server. Every scan_page / flow_scan / scan_html / visual_audit / check_aria / verify_fix call is logged locally (~/.webability/scans; local installs only — the hosted server keeps no history). Without arguments, lists recent scans (when, what target, result summary). Pass id to retrieve the FULL stored result of one past scan, or filter to match a URL/tool substring.
Inputs: id, limit, filter.
scan_htmlScan an HTML snippetARead-onlyIdempotentInspect
Scan a raw HTML snippet or component markup without serving it — IN-PROCESS by default (jsdom + WebAbility detectors + axe-core): milliseconds, no browser, no network, so it fits inside a tight edit loop. Fragments are auto-wrapped into a document. Returns scan_page's shape (issues / summary) with fix.op + fixability on every finding. jsdom has no layout, so visual-tier rules (contrast, target size, focus ring) are NOT evaluated — the dropped count is reported as skippedVisual; pass engine: "browser" to run the axe-core headless-browser path for those (slower, axe rules only, returns axe violations).
Inputs: html (required), tags, wcag, level, +6 more.
scan_pageScan a page for accessibility issuesARead-onlyIdempotentInspect
Scan a web page for WCAG accessibility issues. Works on any URL — deployed sites, localhost, staging. Returns issues (violations the scanner stands behind; findings the engines cannot decide are settled by the AI judge — a violation with a fix, or a pass recorded in judged[] with its reason — and anything unsettled is dropped, never listed for review) and a summary. On React ≤18 / Vue dev builds each issue carries source ({file, line, column, component}) read from the live component tree. Every issue carries a structured fix.op (add-attribute | set-attribute | remove-attribute | add-element | remove-element | add-text-content | suggest) with fix.attribute / fix.value when known, and a fixability tier (mechanical = apply as given; contextual = op known, value needs judgment; visual = needs rendered output, propose only).
Inputs: url (required), wcag, level, rules, +5 more.
start_auditStart a full accessibility auditAInspect
[Full — FREE with a WebAbility account. Not runnable in Lite. Connect hosted MCP at https://mcp.webability.io/mcp (dashboard or Smithery: webability/accessibility), authenticate, then call start_audit.] Kick off a FULL accessibility audit deliverable for a URL — a persistent, timestamped artifact, not an inline scan. Runs the server-side pipeline (axe + advanced checks + mobile viewports + annotated screenshots + optional agent spot-check) and produces a downloadable report and a formatted Excel workbook (Cover / Status / Barriers / ADA context sheets) stored durably. Returns immediately with an audit id; poll get_audit for progress and, when complete, download URLs. Use this when someone needs a durable artifact to attach as evidence of testing effort for a compliance officer or legal response — for iterating on code, use scan_page + verify_fix instead. Needs a free WebAbility account (sign in by connecting https://mcp.webability.io/mcp/auth, or run webability login). Set includeAgent:true to add the slower agentic manual-audit pass. To audit a local dev server, open a tunnel (webability-tunnel --port 3000) and pass its URL as url with the printed secret as tunnel_secret; keep the tunnel open until get_audit reports complete (about 5 minutes) — the pipeline loads the page several times.
Inputs: url (required), includeAgent, tunnel_secret.
verify_fixVerify an accessibility fixARead-onlyIdempotentInspect
Re-scan a specific element after applying an accessibility fix and confirm the violation is gone. After you edit the code and serve it (deployed, staging, or http://localhost:3000), call this with the URL and the selector you fixed to get a machine-checked verified: true|false (DOM engines only — visual_audit findings are out of scope). Pass the WCAG criterion (e.g. "1.1.1") or axe rule id (e.g. "color-contrast") to check just that criterion; omit it to require the element be clean of ALL violations. A blocked page (bot-challenge / HTTP error) is reported as unverified, never a pass — verification fails closed. verified: true is only returned when the selector matched at least one element AND the criterion is one the DOM engines check; if the selector matches no element the result is verified: false with reason "not-found" ("selector matched no elements"), a criterion outside the coverage set returns reason "not-verifiable" ("not checked by any WebAbility tool"); a finding in scope that only the AI judge can settle, when the judge did not run or gave no verdict, also returns "not-verifiable", and shadow-DOM (>>>) / iframe selectors return "unsupported-selector" — pass the element's current selector, or re-run scan_page if your fix removed the element. Pair with scan_page → generate_ai_fix → verify_fix for a full find-fix-verify cycle.
Inputs: url (required), selector (required), wcag, viewport.
visual_auditVisual accessibility auditAInspect
[Full — FREE with a WebAbility account. Not runnable in Lite. Connect hosted MCP at https://mcp.webability.io/mcp (dashboard or Smithery: webability/accessibility), authenticate, then call visual_audit.] Pixel-level accessibility audit using Claude vision. Catches issues that DOM scanners miss: icon contrast (1.4.11), focus visibility (2.4.7), "looks like a button but isn't" (4.1.2), text rendered as images (1.4.5), visual hierarchy mismatches. Takes a URL, opens it in a headless browser, screenshots, and runs vision-based detection. Complements scan_page — run both for full coverage. Sign in with a free WebAbility account for vision and full audits (sign in by connecting https://mcp.webability.io/mcp/auth, or run webability login). Fair-use rate limits apply.
Inputs: url (required), fullPage, viewport, brandColors.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 20 tools
The server has five scanning entry points (scan_page, scan_html, flow_scan, visual_audit, start_audit) whose boundaries are explained across long descriptions but genuinely overlap — flow_scan explicitly degrades to 'exactly like scan_page' without autoNavigate, and scan_page/scan_history/verify_fix all touch the same result data. check_color_contrast and generate_ai_fix both offer brand-palette-derived color suggestions, and diff_scan vs verify_fix are both re-scan-based verification with only granularity (page vs element) separating them. The descriptions do most of the work, but an agent must read them carefully to pick correctly.
The dominant convention is verb_noun (scan_page, get_rules, check_aria, add_site, find_source, generate_report_pdf), applied consistently to a large majority of the 20 tools. The deviations — diff_scan, flow_scan, visual_audit — are noun-first forms, and scan_history uses the scan_ prefix for a browse operation rather than a scan, which is the one place the prefix actively misleads. Still readable and mostly predictable.
20 tools is at the heavy end for a single server and several exist to express modes of the same operation (three scan variants plus visual_audit and start_audit) that could arguably be parameters. Each does earn a real niche, and the breadth (index scanning, fixing, site/account management, audits, reporting) is genuine, but the surface feels like it accumulated rather than was budgeted.
The core lifecycle is well covered end to end: find (scan_page/scan_html/flow_scan/visual_audit), fix (generate_ai_fix, find_source), verify (verify_fix, diff_scan), evidence (start_audit, get_audit, generate_report_pdf), and site/plan management (add_site, list_sites, get_install_snippet, create_upgrade_link). Gaps are minor but real: no way to remove or update a site, no list_audits to find prior audit ids, and scan_history is local-only with no pruning or delete.
Maintenance
Related MCP Connectors
Edge MCP Server for live WCAG 2.1 AA accessibility compliance and AST security audits.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Scan URLs or HTML for WCAG 2.2 violations. 75-rule manifest, weighted score, shareable reports.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server for accessibility auditing that provides WCAG 2.2 criteria lookup, HTML remediation guidance, and automated documentation generation for UI components. It enables users to analyze code snippets for issues and generate professional accessibility audit reports.1,271 npmMIT
- AlicenseAqualityFmaintenanceAn accessibility expert MCP server that provides AI coding assistants with real-time access to WAI-ARIA patterns, code review, contrast checking, and WCAG guidance for writing accessible code from the start.429 PyPIMIT

@accesslint/mcpofficial
AlicenseAqualityFmaintenanceAn MCP server for WCAG accessibility auditing in AI coding agents, providing tools to audit HTML, files, URLs, and diffs, plus a prompt for React component auditing.52,666 npm6MIT- AlicenseNot gradedqualityBmaintenanceAn MCP server that lets an AI agent scan a web page for WCAG accessibility issues and get back findings it can act on.162 npmMIT