@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 | {} |
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 — closes the loop that find-only tools leave open. 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. If the selector matches no element, the result is verified: false with reason "not-found" — 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 |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools have clearly distinct scopes (single-page scan, journey scan, HTML snippet scan, vision audit, fix verification, diffing). The main overlap is between the focused checkers (check_color_contrast, check_aria) and the broader scan_page/scan_html, which also surface those findings — but careful descriptions clarify when to reach for the narrow tools versus the full scan.
Names are mostly verb_noun (scan_page, verify_fix, start_audit, add_site, list_sites, get_rules, generate_report_pdf). A handful invert to noun/qualifier + verb (flow_scan, diff_scan, visual_audit), which is a minor deviation but still readable and predictable.
At 20 tools this is on the heavier side, but the breadth (page/journey/HTML/vision scanning, fixing, verification, history, reporting, account and widget management) justifies the surface. Each tool maps to a distinct capability rather than padding, so it stays reasonable for the scope.
The set covers the full accessibility lifecycle: find (scan_page, flow_scan, scan_html, visual_audit), diagnose (check_color_contrast, check_aria, detect_framework, get_rules, find_source), fix (generate_ai_fix), verify (verify_fix, diff_scan), persist/report (scan_history, generate_report_pdf, start_audit/get_audit), plus site/widget/account management. No obvious dead ends.