@webability/mcp

Overview Schema Source Related Servers Discussions Admin

Visual accessibility audit

visual_audit

Runs pixel-level visual accessibility audits on a URL using screenshots and vision detection to catch contrast, focus visibility, and false-button issues that DOM scanners miss.

Instructions

[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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "visual_audit"
  }
}

Input Schema

Name	Required	Description
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.1Jul 11, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations it discloses real operational traits: a headless browser fetch of the target URL, screenshot-based vision detection, an account/auth prerequisite with the exact auth endpoint, and fair-use rate limits. What it does not clarify is cost/latency expectations or whether anything persists server-side, but readOnlyHint=false and openWorldHint=true already signal the outbound, non-read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core content is well front-loaded, but the bracketed hosting preamble and the auth instructions are duplicated across two separate sentences (connect https://mcp.webability.io/mcp/auth vs `webability login` restated later). Roughly a third of the text is setup/onboarding boilerplate rather than tool behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does name what comes back conceptually — WCAG-referenced findings such as icon contrast (1.4.11), focus visibility (2.4.7), and text-as-image (1.4.5). It stops short of describing result shape, grouping, or severity fields, but an agent knows enough to call it and interpret the gist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so url, fullPage, viewport and brandColors are already fully documented, and the enum on viewport is structured. The description adds only that a URL is taken and the page is screenshotted full-page-or-viewport-by-implication; it says nothing extra about brandColors or viewport presets, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('pixel-level accessibility audit using Claude vision') plus concrete scope: opens a URL, screenshots, and runs vision detection. It explicitly distinguishes itself from DOM-scanner siblings ('catches issues DOM scanners miss', 'Complements scan_page'), so an agent can place it against scan_page without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing advice ('run both for full coverage' with scan_page) and states the eligibility condition (full audits require a free WebAbility account; not runnable in Lite). It never says when to skip this tool in favour of check_color_contrast or check_aria, so the alternative-path coverage is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.