Skip to main content
Glama

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@webability

or 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": false
  • fix.op is one of add-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_fix re-scans one element and fails closed. diff_scan reports fixed[], 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 npx -y @webability/cli login locally)

Adds visual_audit (vision pass), start_audit / get_audit (full report), and webability-tunnel (lets the hosted server scan your localhost)

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 (npx / webability-mcp)

Full — hosted (https://mcp.webability.io/mcp)

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 OPENROUTER_API_KEY (your key)

On, nothing to set (our key)

find_source

Yes

No

scan_history / generate_report_pdf

Yes

No

visual_audit / start_audit / get_audit

Listed as stubs → connect Full (still free)

Yes — free with your account

PostHog / dashboard analytics

Optional env only

On by default on hosted

localhost / private addresses

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-mcp

Other 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 3000

It 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 &lt;secret&gt;"

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 GET and HEAD reach you, on the one port you named, and Authorization / Cookie are 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 (default https://api.webability.io) for self-hosted backends.

  • POSTHOG_PROJECT_API_KEY or POSTHOG_API_KEY to enable PostHog MCP Analytics for MCP initialize, tools/list, and tool-call usage events.

  • POSTHOG_HOST (default https://us.i.posthog.com) for EU or self-hosted PostHog ingestion.

  • WEBABILITY_POSTHOG_MCP_ANALYTICS=off to 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 bugs

  • summary — 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.op

add-attribute · set-attribute · remove-attribute · add-element · remove-element · add-text-content · suggest

fixability

mechanical — value known, apply as given · contextual — op known, value needs judgment (alt text, a label) · visual — needs rendered output (contrast, focus ring, target size); propose, never auto-apply

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

minImpact

minor · moderate · serious · critical — drop anything below

rules[]

keep only these rule ids (missing_alt, image-alt, …)

wcag[]

keep only these criteria; a prefix like 1.4 matches 1.4.3

format: "compact"

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

scan_page

Lite + Full

Scan a URL for WCAG accessibility issues (2 engines). source pointers on dev builds; minImpact / rules / wcag / format output controls

flow_scan

Lite + Full

Multi-page journey scan with deduplicated issues across pages

scan_html

Lite + Full

Scan a raw HTML snippet or fragment in-process (jsdom, ms, no browser); engine: "browser" for contrast

detect_framework

Lite + Full

Detect Tailwind / MUI / Bootstrap / Next.js / WP / plain CSS

generate_ai_fix

Lite + Full

Framework-aware fix alternatives. Auto-extracts brand palette from the live URL on contrast issues.

verify_fix

Lite + Full

Re-scan a fixed element and confirm the violation is gone — verified: true/false. Closes the find → fix → verify loop.

diff_scan

Lite + Full

Baseline vs current → fixed[] / new[] / remaining[]. Page-level regression check; baseline from scan_history (Lite) or a live URL.

check_color_contrast

Lite + Full

WCAG contrast check on a color pair; pass url to get brand-aligned suggestions from the live page

check_aria

Lite + Full

Validate ARIA attributes in an HTML snippet

get_rules

Lite + Full

List axe-core + WebAbility rules with fixability and a fix op template; filter by tag, tier, or engine

find_source

Lite only

Map a CSS selector back to local source files (fallback when the page has no framework source pointer)

scan_history

Lite only

Browse prior local scans under ~/.webability/scans/

generate_report_pdf

Lite only

Turn scan findings into a branded WebAbility accessibility-report PDF saved next to the project — free, no account. Pass the issues[] from scan_page. For the full audit deliverable (Excel + evidence), use start_audit.

visual_audit

Full (free w/ account; stub on Lite)

Pixel-level audit via vision (icon contrast, focus visibility, looks-like-a-button-but-isn't)

start_audit

Full (free w/ account; stub on Lite)

Kick off the full server-side audit deliverable (report + Excel workbook). Returns an id to poll.

get_audit

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_page consolidates both engines

  • Generating 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-primary on 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.

License

MIT

Available Tools

20 tools
add_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 pageA
Read-onlyIdempotent
Inspect

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 contrastA
Read-onlyIdempotent
Inspect

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.

detect_frameworkDetect the site frameworkA
Read-onlyIdempotent
Inspect

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 scansA
Read-onlyIdempotent
Inspect

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 selectorA
Read-onlyIdempotent
Inspect

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 flowA
Read-onlyIdempotent
Inspect

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 PDFA
Destructive
Inspect

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 reportA
Read-onlyIdempotent
Inspect

[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 tagA
Read-onlyIdempotent
Inspect

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 rulesA
Read-onlyIdempotent
Inspect

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 plansA
Read-onlyIdempotent
Inspect

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 scansA
Read-onlyIdempotent
Inspect

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 snippetA
Read-onlyIdempotent
Inspect

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 issuesA
Read-onlyIdempotent
Inspect

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 fixA
Read-onlyIdempotent
Inspect

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

    A3.9/5.0

    Scored across 20 tools

    Disambiguation3/5

    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.

    Naming Consistency4/5

    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.

    Tool Count3/5

    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.

    Completeness4/5

    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

    ActivityActive
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      An 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 npm
      MIT
    • A
      license
      A
      quality
      F
      maintenance
      An 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.
      5
      2,666 npm
      6
      MIT