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 "Install 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.
Accessibility testing MCP server for Cursor, VS Code Copilot, Claude Code, and any other MCP-compatible IDE.
WebAbility.io is an AI-powered web accessibility platform — accessibility widget, automated scanner, and AI agents for WCAG 2.1 / 2.2 AA, ADA, Section 508, EAA (European Accessibility Act) and AODA compliance. This MCP exposes the same accessibility-testing engine that powers the WebAbility widget and dashboard, so you can scan, audit and fix web accessibility issues (color contrast, ARIA, alt text, keyboard navigation, focus visibility, target size, and more) from your IDE while you build.
New to accessibility compliance? Start with the free WCAG & ADA accessibility checker, or read the WebAbility MCP docs and the getting-started guide.
The server registers an instructions block on initialize, so any MCP-compatible client picks up business context (what tool to call when, the three-tier output convention, etc.) automatically — no setup required beyond the install below.
Related MCP server: A11y Expert MCP
Most accessibility MCP servers stop at find and suggest. WebAbility closes the whole loop in your editor, and starts free:
Free, local scan — no account, no Docker. scan_page runs entirely on your machine. (Deque's axe MCP needs a paid subscription, an API key, and a Docker install just to analyze a page.)
Fixes that fit your stack. generate_ai_fix returns ready-to-paste code for the framework you actually use — Tailwind, MUI, Bootstrap, WordPress, Next.js — not generic guidance.
A vision pass DOM scanners can't do. visual_audit catches focus visibility, icon contrast, and "looks like a button but isn't" — issues axe-core structurally cannot see.
Verification, not just detection. verify_fix re-checks that your fix actually landed and returns verified: true/false. Every 2026 comparison of accessibility MCPs names this the biggest gap in the category — most tools never close it.
Evidence for compliance. start_audit produces a persistent, timestamped report and Excel workbook you can hand to an auditor — not a result that vanishes with your session.
The full cycle, without leaving the editor: scan_page → generate_ai_fix → verify_fix, then start_audit when you need the paper trail.
npm install -g @webability/mcpAdd to your IDE's MCP config:
{
"mcpServers": {
"webability": {
"command": "webability-mcp"
}
}
}Optional env: WEBABILITY_API_URL (default https://api.webability.io) for self-hosted backends.
scan_page runs three 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 |
HTML_CodeSniffer | 200+ | Section 508 + WCAG techniques cross-reference |
Every scan returns:
issues — high-confidence violations, safe to surface as bugs
incomplete — findings that need human review (contrast against gradients, marketing imagery, framer-motion pre-animation states, axe-incomplete). Never auto-fix these.
summary — counts by severity + an incomplete count
This mirrors axe-core's violations / incomplete / passes split and prevents agents from "fixing" false positives in destructive ways.
Tool | What it does |
| Scan a URL for WCAG accessibility issues (3 engines) |
| Multi-page journey scan with deduplicated issues across pages |
| Scan a raw HTML snippet (no URL needed) |
| Detect Tailwind / MUI / Bootstrap / Next.js / WP / plain CSS |
| Framework-aware fix alternatives. Auto-extracts brand palette from the live URL on contrast issues. |
| Re-scan a fixed element and confirm the violation is gone — |
| Pixel-level audit via vision (icon contrast, focus visibility, looks-like-a-button-but-isn't) |
| Kick off the full server-side audit deliverable (report + Excel workbook). Returns an id to poll. Requires an account. |
| Check an audit's progress and, once complete, get the severity summary + report/workbook download URLs. |
| WCAG contrast check on a color pair; pass |
| Validate ARIA attributes in an HTML snippet |
| List axe-core rules with optional WCAG tag filter |
| Map a CSS selector back to local source files |
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 all three 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)
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?"
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.
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. See PRIVACY.md for the full per-tool breakdown and WebAbility's privacy policy.
WebAbility platform & docs
WebAbility.io — the accessibility platform (widget, scanner, AI agents, dashboard)
Accessibility widget — one-line install, WCAG-compliant remediation for live sites
Free WCAG & ADA accessibility checker — scan any URL in seconds
Accessibility compliance guides
WCAG 2.1 / 2.2 AA — Web Content Accessibility Guidelines
ADA compliance — Americans with Disabilities Act
Section 508 — U.S. federal accessibility requirements
EAA — European Accessibility Act · AODA — Ontario (Canada)
Accessibility by industry
Install the widget on your stack
WordPress · Shopify · Webflow · Squarespace · BigCommerce · HubSpot · any site (embed)
Package
npm: @webability/mcp · Source: github.com/snayyar00/webability-mcp
Keywords: web accessibility, accessibility testing, WCAG 2.2 AA, ADA compliance, Section 508, EAA, AODA, a11y, accessibility scanner, color contrast checker, ARIA validation, alt text, keyboard navigation, screen reader, MCP server, accessibility for AI coding agents.
MIT © WebAbility.io
Validate ARIA attribute + accessible name/role/value usage in an HTML snippet. 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 (high-confidence) and incomplete (needs human review, e.g. dangling ARIA references — do NOT auto-fix).
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | HTML to test for ARIA correctness |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: runs specific axe-core rules, returns violations and incomplete categories, and warns that incomplete results require human review. It does not contradict any annotations. While it lacks details on performance or rate limits, it is transparent for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently stating the purpose and then providing key details about rules, output types, and usage warnings. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter and no output schema, the description adequately covers the tool's function, rules used, and the nature of results (violations vs. incomplete). It could mention the format of output items, but the absence of an output schema reduces that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'html' is described in the schema as 'HTML to test for ARIA correctness', and the tool description calls it an 'HTML snippet', which adds minor clarity. Since schema coverage is 100%, the description adds limited additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates ARIA attributes and accessible name/role/value usage in HTML snippets, specifying the axe-core rules used. It provides a specific verb and resource, but does not explicitly differentiate from sibling tools like check_color_contrast or scan_html.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use: for ARIA validation of HTML snippets. It advises that 'incomplete' results need human review and should not be auto-fixed, which is a helpful guideline. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a foreground/background color pair against WCAG contrast thresholds. When it fails, suggests BRAND-aligned replacements — extracts the actual brand palette from a live URL using our scanner (CSS vars + most-used colors), or use a provided brandColors array. No url and no brandColors = ratio + pass/fail only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Live URL to extract brand palette from (uses our scanner — CSS vars + dominant colors). | |
| isBold | No | Whether text is bold (default false) | |
| fontSize | No | Font size in px (default 16) | |
| background | Yes | Background color (hex or rgb) | |
| foreground | Yes | Foreground color (hex or rgb) | |
| brandColors | No | Pre-supplied brand palette. Skips URL extraction if provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the extraction process (CSS vars + dominant colors) and fallback behavior. No destructive actions or rate limits mentioned; sufficient for a check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, front-loads the primary purpose, and efficiently conveys core behavior and conditional logic without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should specify output. It mentions 'ratio + pass/fail' and 'suggests replacements' but lacks details on suggestion format. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% providing baseline 3. Description adds workflow context (how url and brandColors trigger suggestions, fallback without them) beyond schema definitions, aiding parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks a foreground/background color pair against WCAG contrast thresholds and optionally suggests brand-aligned replacements. It distinguishes itself from unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when suggestions are provided (with url or brandColors) and when only ratio/pass-fail is returned. It does not explicitly mention alternatives but sibling tools are unrelated, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect which framework/stack a page uses (Tailwind, MUI, Bootstrap, WordPress, Next.js, plain CSS). Use before generate_ai_fix to get framework-appropriate code.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the detection action but omits details about output format (e.g., returns a list or single framework) or any latency considerations. Still, for a simple read-only inspection, the level of disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the core action, provides examples, and gives usage guidance—no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, trivial domain), the description covers all essential aspects: what it detects, which frameworks, and how to use it with a sibling tool. No further documentation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'url' is described in the schema as 'URL to inspect', and the tool description adds no further semantics. With 100% schema description coverage, a baseline of 3 is appropriate since the schema already handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects which framework/stack a page uses, listing specific examples (Tailwind, MUI, Bootstrap, WordPress, Next.js, plain CSS). It also ties to a sibling tool (generate_ai_fix), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before generate_ai_fix to get framework-appropriate code, providing clear context and guidance for when to invoke it relative to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| rootDir | No | Project root to search (defaults to cwd) | |
| selector | Yes | CSS selector from a scan issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes search scope (file types) and purpose, but does not disclose return format, error behavior, or permissions (likely read-only). Meets minimum for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. First sentence conveys core function, subsequent sentences add context (mapping purpose and file types). Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Description fails to mention what the tool returns (e.g., list of file paths), which is critical for an AI agent to interpret results. Missing return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). Description adds no additional detail beyond schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds source files containing a CSS selector, lists supported file types (React/Vue/Svelte/HTML/PHP/Astro), and distinguishes from sibling tools like scan_page or check_aria by mapping DOM selectors back to source code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage context by stating 'so you can edit the right file', but lacks explicit when-to-use vs alternatives like scan_page or check_aria, and no exclusionary guidance. Adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a multi-page user journey. Walks startUrl plus the required 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 / confidence / review flags 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). For a single page, use scan_page.
| Name | Required | Description | Default |
|---|---|---|---|
| maxPages | No | Max pages to scan (default 10) | |
| startUrl | Yes | Starting URL of the journey | |
| autoNavigate | Yes | REQUIRED — the URLs to walk after startUrl (the MCP server is headless and cannot discover a journey interactively). For a single page, use scan_page instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It comprehensively describes behavior: deterministic sequential scanning, explicit outcomes for each page in pages[], deduplication of issues, and that pages are never silently dropped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, well-structured with purpose first, then behavioral details. Packs much information efficiently, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return format (pages[] with explicit outcomes, fix payload etc). Covers deduplication and that each page carries same flags as scan_page. Complete for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning beyond schema: clarifies startUrl as starting point, autoNavigate as list after startUrl, and maxPages default of 10. Reinforces that autoNavigate is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans multi-page user journeys, walks URLs sequentially, and returns one consolidated report. It distinguishes from the sibling tool scan_page by explicitly noting it is better for journeys and that for a single page, one should use scan_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (multi-page journeys like login -> checkout) and when not (single page -> use scan_page). It also mentions that autoNavigate is required and the server is headless, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL — also used to auto-extract brand palette for contrast issues if `brandColors` is not provided. | |
| html | Yes | The element's outerHTML — send at most ~600 chars | |
| issue | Yes | Issue object from scan_page (with selector, wcag, impact, message, fix.currentValue) | |
| context | No | Parent element outerHTML for context (~400 chars) | |
| framework | Yes | CSS framework — use detect_framework first | |
| brandColors | No | Brand palette for brand-aligned suggestions. If omitted on a contrast issue with a `url`, auto-extracted via the scanner. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing issue-type-specific behavior (number of alternatives per type), auto-extraction of brand palette, and the ready-to-paste code output. It lacks mention of potential side effects or error states, but overall provides sufficient behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of moderate length that efficiently conveys key information. While not overly verbose, it could be slightly more structured (e.g., bullet points) for easier scanning. It remains concise without missing critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects, no output schema), the description covers essential behavioral aspects: issue-type handling, auto-extraction, and output format. It references related tools (detect_framework) and provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining behavioral differences (e.g., brandColors auto-extraction) and how parameters interplay with issue type, going beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating framework-aware fix alternatives for a specific accessibility issue. It distinguishes itself from sibling tools by detailing different behaviors for color contrast vs. label/ARIA issues, making it unambiguous what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for a specific issue) and hints at prerequisites via the framework parameter (recommends using detect_framework first). However, it does not explicitly state when not to use it or name alternative tools for different scenarios, which would improve guidance further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The audit id returned by start_audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses polling behavior, access restriction, and that download URLs are short-lived. Without annotations, the description covers key behavioral aspects, though it omits potential error states or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is concise but packs multiple pieces of information. Could be more structured but remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output structure well (status, progress, severity, download URLs). Includes polling interval and access rules, making it sufficiently complete for a monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the single parameter 'id' with its description. The tool description adds no extra parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks an audit started with start_audit and lists returned data (status, progress, severity, URLs). Distinguishes itself from sibling tools by specifying its role as a polling endpoint for audit results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides polling guidance (every ~15s) and access restriction (only the starter account). Implicitly tells when to use (after start_audit) but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List axe-core accessibility rules with optional tag filtering. Returns ruleId, description, help text, helpUrl, and tags for each rule. Useful for understanding what a WCAG criterion checks.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tags (e.g. ["wcag21aa"], ["best-practice"], ["cat.aria"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates a read operation (listing rules) with no destructive side effects, but does not disclose other traits like authentication needs, rate limits, or limitations. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The main action is front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is fairly complete. It explains purpose, returned fields, and a use case. Lacks mention of pagination or ordering, but not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the 'tags' parameter. The description adds context about returned fields but does not add parameter-specific details beyond the schema. Given high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists axe-core accessibility rules with optional tag filtering, specifies returned fields, and gives a use case. It differentiates from sibling tools like 'check_aria' or 'check_color_contrast' which are specific checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful for understanding what a WCAG criterion checks' but does not explicitly state when to use this tool versus siblings like 'start_audit' or 'scan_page'. Usage guidance is implied but not sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A scan id from the history list — returns that scan's full stored response | |
| limit | No | Max history entries to return (default 20) | |
| filter | No | Substring match on target URL or tool name (e.g. "abilyo.com" or "scan_page") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description covers storage location (~/.webability/scans), local vs hosted behavior, and the effect of each parameter. It could mention what happens with invalid id, but overall discloses key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) without wasted words. The first sentence front-loads purpose. Minor improvement could be separating the local/hosted note for clarity, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives enough info on return behavior (result summary vs full result). It addresses the complexity of 3 optional parameters and distinguishes from 13 sibling tools. Lacks error handling details but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100%, but the description adds value by clarifying that 'id' returns the full stored response and 'filter' matches URL or tool name. This enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses past scans, explicitly lists which sibling tools are logged (scan_page, flow_scan, etc.), and distinguishes its role from others by focusing on history rather than new scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each parameter: no arguments for recent scans, id for full result, filter for substring matching. It also notes the local-only constraint. Missing explicit 'when not to use' but provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a raw HTML snippet for accessibility issues without serving it. Useful for code review, component snippets, or content from docs. Spins up a headless page, sets the HTML, and runs axe-core ONLY — lighter and faster than scan_page, but it skips the WebAbility detectors and HTML_CodeSniffer, and returns axe violations (with an incomplete count), not scan_page's three-tier issues/incomplete/summary shape.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | HTML content to test | |
| tags | No | WCAG tags to check (default ["wcag2a","wcag2aa","wcag21aa","wcag22aa"]) | |
| width | No | Viewport width (default 1280) | |
| height | No | Viewport height (default 800) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: spins up a headless page, sets HTML, runs axe-core only, and returns axe violations with an incomplete count. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding essential information: purpose and differential context. No redundant or vague phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no output schema, no annotations), the description covers purpose, usage scenarios, behavioral details, and output shape comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described. The description does not add additional parameter-level detail beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans raw HTML snippets for accessibility issues without serving, and explicitly distinguishes it from the sibling tool scan_page by noting it's lighter, faster, and uses only axe-core.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: useful for code review, component snippets, or content from docs. Also clearly states when not to use it (when you need WebAbility detectors or HTML_CodeSniffer) and names the alternative sibling tool scan_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a web page for WCAG accessibility issues. Works on any URL — deployed sites, localhost, staging. Returns the three-tier shape: issues (high-confidence violations safe to fix), incomplete (needs human review — gradient backgrounds, marketing imagery, axe-incomplete results, framer-motion pre-animation states), and a summary. Treat incomplete as questions, never auto-fix them.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scan (e.g. https://example.com or http://localhost:3000) | |
| viewport | No | Viewport size (default: desktop) | |
| rootSelector | No | CSS selector to limit scan scope (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the return structure (issues, incomplete, summary) and warns that incomplete results need human review. It implies read-only behavior but does not explicitly state safety or lack of side effects. Still, it provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight three sentences: purpose, applicability, and output details. Front-loaded with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the three-tier output shape and provides examples of what goes where. It covers the main parameter usage. Additional detail on summary structure would improve completeness, but it is adequate for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much. The description provides context on URL handling but adds no extra meaning to viewport or rootSelector beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans web pages for WCAG accessibility issues. The verb 'scan' and resource 'WCAG accessibility issues' are specific. Among sibling tools, this is the general scanner, distinct from specific ones like check_aria or check_color_contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly mentions it works on any URL including localhost and staging, providing clear usage context. However, it does not explicitly contrast with siblings or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. REQUIRES A WEBABILITY ACCOUNT (runs paid server-side browser/AI work): authenticate via webability login or set WEBABILITY_API_KEY. Set includeAgent:true to add the (slower, paid) agentic manual-audit pass.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit (a public/staging URL the server can reach — not localhost) | |
| includeAgent | No | Also run the agentic manual-audit pass (keyboard/focus/modal exploration). Slower and paid. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes that the tool runs server-side pipeline, returns immediately with an id, and requires polling. It also mentions the optional agent pass and its implications (slower, paid). However, it does not explicitly state that the operation is non-destructive or that it requires certain permissions, but the context implies a read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: starts with purpose, then details, then usage guidance. It front-loads key information. A slight reduction in wording could improve conciseness, but overall it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description covers return value (audit id), polling instructions, prerequisites (account and authentication), and output format. It also provides alternatives and explains when to use agentic audit. This is highly complete for a tool with two parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are present. The description adds context beyond schema: url must be public/staging and not localhost; includeAgent defaults to false and is slower/paid. This is helpful beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it kicks off a full accessibility audit deliverable, distinguishing it from inline scans. It specifies the server-side pipeline and outputs (downloadable report and Excel workbook). It also contrasts with sibling tools like scan_page and verify_fix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('for evidence of testing effort for compliance officer or legal response') and when to use alternatives ('for iterating on code, use scan_page + verify_fix instead'). Also mentions required account and authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 and needs-review items 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. IMPORTANT: if your fix changed the element's class or id, the original selector may no longer match anything, which reads as verified — re-run scan_page or pass the updated selector to be sure. Pair with scan_page → generate_ai_fix → verify_fix for a full find-fix-verify cycle.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL now serving the fix (deployed, staging, or http://localhost:3000) | |
| wcag | No | Optional: WCAG criterion (e.g. "1.1.1", "1.4.3") or axe rule id (e.g. "color-contrast") to verify specifically. Omit to require the element be free of ALL violations. | |
| selector | Yes | CSS selector of the element you fixed — use the `selector` from the original scan_page issue | |
| viewport | No | Viewport size (default: desktop). Use the same viewport the issue was found at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that verification only works for DOM engines (not visual_audit), that a blocked page results in unverified (fail closed), and warns about selector mismatch potentially causing false verified. It also explains the optional wcag parameter behavior. These details provide good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose in the first sentence. It covers all necessary information without unnecessary verbosity. While it could be broken into bullet points for improved scannability, it is efficient and well-organized for an agent reading sequentially.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (accessibility verification), parameter count (4), and lack of output schema, the description adequately covers return semantics (verified: true|false), scope limitations (DOM engines only), and edge cases (blocked page, selector mismatch). It also references a full workflow cycle, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining each parameter's context: url indicates deployment/staging/localhost; wcag explains optionality and behavior when omitted; selector references original scan_page issue; viewport recommends same viewport. This adds clarity beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Re-scan a specific element after applying an accessibility fix and confirm the violation is gone'. It distinguishes from siblings by positioning it as part of a find-fix-verify cycle, and uses a specific verb-resource combination (verify fix).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (after editing code and serving it with URL and selector) and when not (visual_audit and needs-review are out of scope). It also advises on handling changed selectors. However, it does not explicitly contrast with other verification siblings like check_aria or check_color_contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. REQUIRES A WEBABILITY ACCOUNT (like start_audit — these are the paid, server-side tools; the DOM-based tools run free and local): authenticate via webability login or set WEBABILITY_API_KEY in your MCP server env before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit visually | |
| fullPage | No | Capture full scrolled page instead of just viewport (default: false) | |
| viewport | No | Viewport size (default: desktop) | |
| brandColors | No | Brand hex colors for context-aware filtering |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully bears burden. It discloses the process: takes URL, opens headless browser, screenshots, runs vision detection. Also warns about account requirement and paid nature, which are critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but well-structured with bullet points and clear separation of purpose, process, and prerequisites. Each sentence adds value, though slight verbosity could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing description of output or return value. For a tool that runs an audit, it doesn't explain what the agent receives (e.g., a report, issues list, score). With no output schema, this is a notable gap, but other aspects (usage, parameters) are well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds no extra meaning to parameters beyond what schema already provides. The text only mentions 'takes a URL' but does not elaborate on optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Pixel-level accessibility audit using Claude vision' and lists specific issues it detects (icon contrast, focus visibility, etc.). It distinguishes from sibling tool scan_page by stating it complements it and suggests running both for full coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (for vision-based checks), how it complements scan_page, and prerequisites including account requirement and authentication methods. Differentiates from DOM-based free tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.1check_ariacheck_color_contrastdetect_frameworkfind_sourceflow_scangenerate_ai_fixget_auditget_rulesscan_historyscan_htmlscan_pagestart_auditverify_fixvisual_auditEach tool has a clearly distinct purpose: scanning pages, checking specific accessibility aspects, finding sources, generating fixes, verifying fixes, auditing, etc. Descriptions provide clear differentiation.
All tool names follow a consistent verb_noun pattern with underscores (e.g., check_aria, scan_page, verify_fix). No mixing of conventions.
14 tools cover the domain of accessibility scanning, fixing, and auditing comprehensively without feeling bloated. Each tool serves a distinct purpose.
The tool set covers the full workflow: scanning (page, flow, HTML), detailed checks (ARIA, color, visual), source finding, framework detection, fix generation, verification, auditing, and history. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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 for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/snayyar00/webability-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
