@webability/mcp

Overview Schema Source Related Servers Discussions Admin

Start a full accessibility audit

start_audit

Kick off a full accessibility audit for a URL that produces a persistent, timestamped report and Excel workbook for compliance evidence; returns an audit ID for progress polling.

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

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": "start_audit"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	URL to audit (a public/staging URL the server can reach, or a webability-tunnel URL — not localhost)
`includeAgent`	No	Also run the agentic manual-audit pass (keyboard/focus/modal exploration). Slower. Default false.
`tunnel_secret`	No	Secret printed by `webability-tunnel`. Required when `url` is a tunnel URL; the URL alone will be refused by the relay. Ignored otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.7.0Oct 5, 2026

changedInput schema / properties / includeAgent / description

Previous value: -"Also run the agentic manual-audit pass (keyboard/focus/modal exploration). Slower and paid. Default false."New value: +"Also run the agentic manual-audit pass (keyboard/focus/modal exploration). Slower. Default false."

addedInput schema / properties / tunnel_secret

Added value: +{
+  "description": "Secret printed by `webability-tunnel`. Required when `url` is a tunnel URL; the URL alone will be refused by the relay. Ignored otherwise.",
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"URL to audit (a public/staging URL the server can reach — not localhost)"New value: +"URL to audit (a public/staging URL the server can reach, or a webability-tunnel URL — not localhost)"

First observedv1.3.1Jul 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description adds far more: async behavior (returns an id immediately, poll get_audit, ~5 minute runtime), durable server-side storage, auth/account requirements, hosted-MCP connect path, and the tunnel requirement to keep a connection open because the pipeline reloads the page. That is exactly the context annotations cannot carry.

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

Conciseness4/5

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

Purpose and the alternative routing are front-loaded, and each sentence carries information. However, the bracketed hosting/auth preamble is dense and partially redundant with the later 'Needs a free WebAbility account' sentence, so a small amount of trimming is possible.

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

Completeness5/5

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

For an async, multi-minute pipeline tool with no output schema, the description supplies everything an agent needs: what it produces (report + Excel workbook with named sheets), that it returns an id rather than results, how to get progress and download URLs via get_audit, how long to wait, and the prerequisites. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by explaining the operational consequence of includeAgent (slower agentic pass) and the tunnel workflow — `webability-tunnel --port 3000`, pass the printed secret as tunnel_secret, keep it open until complete. It doesn't add new meaning to `url` beyond the schema's 'not localhost' note, but the workflow context is genuinely additive.

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 deliverable ('Kick off a FULL accessibility audit deliverable for a URL — a persistent, timestamped artifact, not an inline scan') and immediately distinguishes it from inline scanning. The distinction from siblings scan_page/verify_fix and its relationship to get_audit are both explicit.

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

Usage Guidelines5/5

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

Gives an explicit when: 'when someone needs a durable artifact to attach as evidence of testing effort for a compliance officer or legal response.' Gives an explicit when-not plus alternative: 'for iterating on code, use scan_page + verify_fix instead.' Also names get_audit as the follow-up call for polling.

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