@webability/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEBABILITY_API_URL | No | Optional URL for self-hosted backends | https://api.webability.io |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
| extensions | {
"io.modelcontextprotocol/ui": {
"mimeTypes": [
"text/html;profile=mcp-app"
]
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_pageA | Scan a web page for WCAG accessibility issues. Works on any URL — deployed sites, localhost, staging. Returns |
| verify_fixA | 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. |
| diff_scanA | Compare two scans of the same page and report what changed: |
| start_auditA | [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 |
| add_siteA | 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"). |
| list_sitesA | 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. |
| get_install_snippetA | 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. |
| create_upgrade_linkA | 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. |
| get_auditA | [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 |
| flow_scanA | Scan a multi-page user journey. Walks startUrl plus the |
| detect_frameworkA | Detect a page's stack as two separate fields: |
| generate_ai_fixA | 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 |
| visual_auditA | [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 |
| find_sourceA | 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. |
| scan_htmlA | 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 |
| get_rulesA | List accessibility rules from both engines — axe-core (104) and the WebAbility detectors (90+) — with optional filters. Every rule carries |
| check_color_contrastA | 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 |
| check_ariaA | Validate ARIA attribute + accessible name/role/value usage — in an HTML snippet ( |
| scan_historyA | 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 |
| generate_report_pdfA | Turn scan findings into a branded WebAbility accessibility-report PDF, saved next to the project (local installs only). Pass the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| webability-result-card | Renders scan_page and verify_fix results as a card. |
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.