wcagc-mcp is an MCP server that lets AI assistants run real, deterministic accessibility scans (powered by axe-core) and PDF/UA-1 checks via the wcagc API — without relying on LLM guesses. Scans are queued and return an ID immediately; separate polling tools retrieve results. No compliance scores are returned, as automated testing covers only ~30–57% of accessibility issues.
Core Tools (all tiers)
scan_url — Scan any public URL for accessibility issues. Returns a scan ID to poll.
get_scan — Poll status and results (severity counts, top-5 findings) for a scan_url scan.
get_findings — Retrieve top-5 findings (rule ID, severity, help URL, target selector) for a URL scan.
check_pdf — Check a public PDF for PDF/UA-1 conformance (structure, tags, reading order) via veraPDF.
get_pdf_check — Poll results of a check_pdf scan.
Pro+ Tools
list_sites — List all registered sites in your organization.
scan_site — Crawl and scan every reachable page of a registered site; returns a runId to poll.
get_run — Poll the status of a full-site scan run.
get_run_findings — Retrieve deduplicated, rule-level findings for a full-site scan.
run_journey — Replay a saved multi-step user journey (e.g., a checkout flow) and check accessibility at each step.
get_journey_run — Poll results of a journey run, including per-step checkpoints.
get_trends — Retrieve historical violation-count trends for a registered site across completed runs (by severity, with added/resolved markers).
An MCP server that lets an AI assistant (Claude, ChatGPT, or any MCP-compatible client) run real, deterministic accessibility scans through wcagc — axe-core under the hood, not an LLM guess. Every scan result carries an explicit coverage disclaimer and never claims "compliant": automated testing finds only a portion of accessibility barriers, and this tool says so in every response.
This package is a thin, stateless adapter. It holds no database, no scan logic, and no secrets beyond the wcagc API base URL — it translates MCP tool calls into HTTP calls against the wcagc API and forwards the caller's own bearer. All authentication, entitlements, quotas, and scan orchestration live in the API; this code is safe to read end to end.
Local (stdio) — for Claude Desktop, Cursor, or any MCP client that spawns a local process:
npx @wcagc/mcpConfigure your MCP client with:
{
"mcpServers": {
"wcagc": {
"command": "npx",
"args": ["-y", "@wcagc/mcp"],
"env": {
"WCAGC_MCP_KEY": "<your mcp:scan API key>"
}
}
}
}Mint an mcp:scan key from your wcagc account under Settings → API keys — available on every
plan, with a daily quota on Free/Starter and unlimited on Pro/Agency.
Hosted (Streamable HTTP + managed OAuth) — what Claude web/desktop/mobile connectors and ChatGPT use, since neither runs a local process for you. Add this remote MCP connector:
https://mcp.wcagc.com/mcpThe client discovers /.well-known/oauth-protected-resource/mcp, opens the wcagc login/consent
flow, and binds the connection to one Organization. No key copy/paste is required. API-key bearer
authentication remains supported for local stdio and CI.
ChatGPT availability depends on the ChatGPT plan and on whether the client permits action tools;
scan_url creates a scan and is not a read-only operation. See
wcagc.com/integrations/mcp.
Related MCP server: WCAG Color Contrast MCP Server
Tool | Plan | What it does |
| all | Scan any public URL, or a registered site for full tracking (Pro+). |
| all | Run a PDF/UA-1 structure check on a public PDF. |
| all | Read a |
| Pro+ | List the account's registered sites. |
| Pro+ | Crawl and scan every reachable page of a registered site. |
| Pro+ | Read a full-site run from |
| Pro+ | Group a run's repeated DOM patterns and return factual element/page blast radius. |
| Pro+ | Replay a saved multi-step journey and check each step. |
| Pro+ | Read a site's violation-count history over time. |
One id, one poll tool: whatever scan_url did with a URL, get_scan and get_findings read it
back. get_run and get_run_findings are only for full-site runs from scan_site.
Every scan-producing tool returns the coverage disclaimer in both the text content and the structured content. There is no score, grade, or conformance verdict — automated testing finds roughly 30–57% of accessibility issues, and the remainder needs manual review.
Env var | Used by | Meaning |
| both | The wcagc API to call. Defaults to |
| stdio | Your |
| hosted | Port to listen on (default |
| hosted | Comma-separated Host-header allowlist (DNS-rebinding protection when bound to |
| hosted | How long a verified bearer is cached before re-checking with the API (default |
| hosted | Expected OAuth issuer (defaults to |
| hosted | Authorization Server public JWKS URL. |
| hosted | Canonical RFC 9728 protected-resource URL (defaults to |
| hosted | JWKS cache TTL; an unknown |
| hosted | OpenAI Plugins Directory domain-verification token; keep it in the deployment secret store, never in source. |
npm install
npm run dev # hosted, watch mode
npm run start:stdio # stdio mode
npm run typecheck
npm run verify # node:test against a local fixture APIMIT — see LICENSE.
Downloads a public PDF URL and runs a machine-verifiable veraPDF PDF/UA-1 check (document structure, tags, reading order — not a full WCAG audit). Free tier, counted against the caller's daily quota. Queues the check and returns immediately with an id; call get_pdf_check to poll.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public URL serving a PDF file. |
| Name | Required | Description |
|---|---|---|
| pdfCheck | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds behavioral details: it downloads the PDF, queues a check, counts against daily quota, and returns immediately. This goes beyond annotations by explaining the async workflow and quota impact.
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 front-load the core purpose and constraints, then add essential workflow info. No redundant phrases; every sentence contributes.
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 parameter, the description covers purpose, workflow, quota, and follow-up action (poll with get_pdf_check). The presence of an output schema is acknowledged, and the description complements it well.
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 url parameter. The description reiterates 'public PDF URL' but adds no new semantics beyond the schema; the main value is in behavioral context, not parameter-specific details.
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 downloads a public PDF and runs a PDF/UA-1 conformance check, specifying exact checks (structure, tags, reading order) and explicitly distinguishing it from a full WCAG audit, which differentiates it from siblings like scan_url.
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 the free tier quota and the asynchronous nature (returns id, poll with get_pdf_check). It implicitly advises against use for full WCAG audits, providing some when-not guidance, though explicit alternatives are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The findings for a scan started by scan_url — rule id, severity, help URL and the element selector. Works for both kinds of scan_url scan. A one-off scan returns the top-5 sample; a scan recorded against a registered site returns its full findings. For a full-site run from scan_site, use get_run_findings instead.
| Name | Required | Description | Default |
|---|---|---|---|
| scanId | Yes | The id returned by scan_url. |
| Name | Required | Description |
|---|---|---|
| violations | Yes | |
| recordedAgainstSite | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds valuable behavioral context: the differential output based on scan type and the fields included. No contradictions with annotations.
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, each adding essential information without redundancy. Front-loaded with key information about the resource and output.
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 one parameter, output schema present, and annotations covering safety, the description is complete. It explains both usage scenarios and directs to alternative tool for different inputs.
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 'scanId' is fully described in the schema (100% coverage). The description mentions 'The id returned by scan_url' which matches the schema description, so no additional value 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 verb-resource (get findings) and specifies the outputs: rule id, severity, help URL, and element selector. It distinguishes from sibling tool 'get_run_findings' by noting the input type (scan_url vs scan_site).
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 indicates when to use (both kinds of scan_url scans) and when not to (for full-site runs, use get_run_findings instead). Also explains the difference in output size (top-5 sample vs full findings) based on scan type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists tracked remediation items for a registered site, including status and the scope of any automated verification proof. Pro+ (REMEDIATION_TRACKING).
| Name | Required | Description | Default |
|---|---|---|---|
| siteHost | Yes | The registered site's normalized host, as list_sites reports it. |
| Name | Required | Description |
|---|---|---|
| fixes | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds that the tool returns 'status and the scope of any automated verification proof', which is output-oriented rather than behavioral. No additional behavioral traits (e.g., rate limits, side effects) are disclosed beyond annotations.
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 consists of two concise sentences. The first sentence clearly states the purpose and includes output details. The second mentions the required feature gate. No extraneous information; front-loaded with the action verb.
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 has a single parameter, no enums, and an output schema exists, the description adequately covers the purpose and output content. It mentions the required Pro+ feature. It might miss details like pagination or ordering, but these are likely covered by the output schema. Overall, it is sufficiently complete for a list 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?
The schema describes the single required parameter 'siteHost' as 'The registered site's normalized host'. The description adds value by specifying 'as list_sites reports it', which clarifies the expected format and ties it to another tool's output. This reduces ambiguity beyond the schema alone.
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 'Lists tracked remediation items for a registered site', specifying the verb (list), resource (remediation items), and scope (per site). It distinguishes itself from siblings like verify_fix by focusing on listing, not verification. The inclusion of output details (status, verification proof scope) adds clarity.
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 implies usage for listing fixes but lacks explicit guidance on when to use this tool over related siblings (e.g., get_fix_verification, verify_fix). The mention of 'Pro+ (REMEDIATION_TRACKING)' hints at subscription requirements but does not provide when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls a targeted fix verification and reports only what was detected on the selected pages checked. Pro+.
| Name | Required | Description | Default |
|---|---|---|---|
| fixVerificationId | Yes | The id returned by verify_fix. |
| Name | Required | Description |
|---|---|---|
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| verification | Yes | |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds polling behavior and scoped reporting ('only what was detected on selected pages'), which provides useful context beyond annotations. However, it does not elaborate on return format or potential edge cases.
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 very short (two sentences), but the 'Pro+' fragment is incomplete and potentially confusing. It is efficient but lacks clarity in the second part.
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 (1 param, annotations, output schema exists), the description is adequate but not thorough. It conveys the core purpose but misses details like expected response or prerequisites (already partly in 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 the schema's description for fixVerificationId is already clear ('The id returned by verify_fix'). The description adds no further parameter meaning, so 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 indicates the tool polls a fix verification and reports detected issues. The verb 'polls' and resource 'fix verification' are specific. It distinguishes from sibling tools like verify_fix (which initiates verification) and get_fixes (which lists all fixes), though not explicitly.
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 implies usage after calling verify_fix (since it requires a fixVerificationId from that tool), but it provides no explicit guidance on when to use or when not to use, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls a run started by run_journey — per-step checkpoints and, once terminal, a failure reason if a step failed. Pro+.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The id returned by run_journey. |
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that the tool polls, provides per-step checkpoints, and gives failure reason on terminal state. 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, front-loaded with key information, no redundancy. Every sentence 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?
With full schema coverage and output schema implied, the description sufficiently covers polling behavior and terminal state. Minor gap: no mention of error handling or rate limits, but acceptable for a simple read-only 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% for the single parameter runId, described as 'The id returned by run_journey.' The description does not add new meaning beyond the schema, so baseline score of 3.
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 polls a journey run started by run_journey, with per-step checkpoints and failure reason. It differentiates from siblings like get_run by specifying 'journey run' and referencing run_journey.
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 indicates usage after run_journey and mentions 'Pro+' tier. It does not explicitly state when not to use or list alternatives, but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls a PDF check started by check_pdf — status, failed-rule and failed-check counts, and a failure reason if it did not complete.
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | Yes | The id returned by check_pdf. |
| Name | Required | Description |
|---|---|---|
| pdfCheck | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds value by explaining the polling behavior and the specific data returned (status, counts, failure reason), which are not captured in annotations.
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 sentence that efficiently conveys the tool's purpose and return data. No unnecessary words or repetition.
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 existence of an output schema (not shown but indicated), the description appropriately mentions key return fields without needing to detail the schema. The single parameter is clearly documented.
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 checkId. The description does not add significant new meaning beyond the schema, so a 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?
The description clearly states it polls a PDF check started by check_pdf and returns status, counts, and failure reason. It distinguishes from siblings by specifying the polling nature and the type of data returned.
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 implies usage after check_pdf but does not explicitly state when to use this tool versus alternatives like get_scan or get_findings. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns deterministic repeated DOM patterns and factual blast-radius counts for a full-site run. Grouping does not expand automated-test coverage and may not match the site's real component boundaries. Pro+.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The id returned by scan_site. |
| Name | Required | Description |
|---|---|---|
| rootCauses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by mentioning deterministic behavior and the limitation regarding automated-test coverage and component boundaries. It also notes the Pro+ tier, which is not in annotations.
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 three sentences with no wasted words. The first sentence states purpose, the second adds a behavioral caveat, and the third notes the tier. Each sentence serves a clear function.
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?
The tool has one required parameter, an output schema (not shown but present), and clear annotations. The description explains what is returned and gives a key limitation. For a simple read-only tool, this is nearly complete; a missing element would be describing the output structure, but the output schema likely covers that.
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 the parameter 'runId' is already documented as 'The id returned by scan_site.' The description adds no further semantic detail about the parameter beyond what the schema provides, earning a baseline of 3.
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 returns 'deterministic repeated DOM patterns and factual blast-radius counts' for a 'full-site run', distinguishing it from sibling tools like get_findings or get_run_findings. It also specifies the Pro+ tier, which sets context.
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 implicit guidance by noting the tool is for full-site runs and warns that grouping 'does not expand automated-test coverage and may not match the site's real component boundaries'. However, it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls a full-site run started by scan_site — page progress, severity counts and, once terminal, a failure reason. Pro+. For a single-page scan from scan_url, use get_scan instead.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The id returned by scan_site. |
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it is a polling operation (implies repeated calls), provides progress, severity counts, and failure reason. The 'Pro+' hint about access control is additional.
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, no wasted words. First sentence defines the tool's core function, second provides a clear alternative. Information is front-loaded.
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?
The description is complete for a simple read-only poll tool with one parameter and an output schema. It explains what the tool does, what it returns, prerequisites (run started by scan_site), and distinguishes from sibling. No gaps.
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% and already states 'The id returned by scan_site.' The tool description reinforces this by mentioning the parameter in context ('Polls a full-site run started by scan_site — ...'). This adds value by linking the parameter to the tool's workflow.
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 verb 'polls', the resource 'full-site run started by scan_site', and what it returns (page progress, severity counts, failure reason). It also distinguishes from the sibling tool 'get_scan' by specifying the scope (full-site vs single-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?
The description explicitly says when to use ('after scan_site') and provides an alternative ('For a single-page scan from scan_url, use get_scan instead'). Also mentions 'Pro+' which indicates access tier requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run-level, rule-deduplicated findings for a scan_site run — one entry per rule, with the WCAG success criteria it maps to. Pro+. For a single-page scan from scan_url, use get_findings instead.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The id returned by scan_site. |
| Name | Required | Description |
|---|---|---|
| violations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, ensuring safe read behavior. Description adds that results are deduplicated per rule and include WCAG mappings, but doesn't contradict annotations.
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: first delivers core purpose and details, second provides alternative usage. No unnecessary words, well-structured.
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 presence of an output schema, description need not detail return format. It specifies scope (full-site scan), deduplication, and WCAG mapping, which is sufficient for the tool's context.
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% for the single parameter runId, with clear description in schema. Tool description does not add additional parameter semantics beyond what 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?
Clearly states it retrieves run-level, rule-deduplicated findings for a scan_site run, including WCAG success criteria mapping. Explicitly distinguishes from sibling 'get_findings' for single-page 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?
Provides explicit alternative usage: 'For a single-page scan from scan_url, use get_findings instead.' Also notes 'Pro+' restriction, setting clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Polls a scan started by scan_url — either kind, recorded against a registered site or one-off; this tool finds it either way. Returns severity counts, a finding sample, the coverage disclaimer, and (once terminal) a failure reason if the scan did not complete. For a full-site run from scan_site, use get_run instead.
| Name | Required | Description | Default |
|---|---|---|---|
| scanId | Yes | The id returned by scan_url. |
| Name | Required | Description |
|---|---|---|
| scan | Yes | |
| pollWith | Yes | The tool that reads this scan's progress and result. |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
| recordedAgainstSite | Yes | True when the URL belongs to a registered site and the scan was kept against it (so it feeds history and trends); false for a one-off scan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds beyond annotations by detailing return values (severity counts, finding sample, coverage disclaimer, failure reason) and clarifying it is a polling operation. No contradiction with annotations.
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, no wasted words. Purpose and key details are front-loaded. Every sentence 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?
Given output schema exists, description sufficiently summarizes return values and covers both scan types. A bit more detail on polling behavior could be added, but it's 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?
The single parameter scanId is well-described in both schema and description; description adds context that it is the id from scan_url. Schema coverage is 100%, so minor extra value justifies above baseline.
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 polls a scan started by scan_url, works for registered or one-off scans, and distinguishes from sibling get_run for full-site runs.
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 (after scan_url) and when not (instead use get_run for full-site runs). Also mentions it works for either kind of scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chronological (oldest->newest) per-run point history for a registered site's completed full-site runs — counts by severity and, where a comparison exists, added/resolved markers. No score. Pro+ (TREND_HISTORY).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most recent N runs (default 30, max 100). | |
| siteHost | Yes | The registered site's normalized host, as list_sites reports it. |
| Name | Required | Description |
|---|---|---|
| trend | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: chronological ordering, per-run points, severity counts, marker conditions, and plan requirement. No contradictions with annotations.
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 efficient sentences, front-loading key information: chronological order, data points, constraints. Every sentence adds value with no waste.
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 presence of an output schema and only two parameters, the description covers core aspects: data shape, ordering, feature marker, plan requirement. Missing details like limit default or pagination are minor omissions for a tool of this complexity.
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 descriptions for both parameters. The description does not add extra meaning to parameters beyond what the schema provides. Baseline 3 is appropriate as the schema already documents parameters adequately.
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 returns chronological per-run point history for a registered site's completed full-site runs, with counts by severity and optional added/resolved markers. It distinguishes from 'score' and mentions the Pro+ plan requirement, making the purpose specific and unambiguous.
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 implies usage for historical trend data and specifies constraints (registered site, completed full-site runs, no score). However, it does not explicitly compare with siblings like get_run or get_findings, nor does it state when not to use this tool. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists this organization's registered sites — their normalized hosts are what every other Pro+ tool takes as siteHost. Pro+ (requires sites:read + API_ACCESS).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sites | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, read-only, idempotent nature. Description adds permission requirements (sites:read + API_ACCESS), which is useful behavioral context beyond annotations. 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 concise sentences with front-loaded action. Every word adds value, no 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?
For a zero-parameter tool with annotations and output schema, description covers permission needs and output purpose. Complete and self-sufficient.
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?
No parameters exist, so description does not need to add parameter meaning. Baseline 4 applies as no parameter information is missing.
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 lists registered sites and explains the significance of normalized hosts. Distinguishes from sibling tools like scan_url or get_scan which focus on scanning rather than listing.
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?
Implies usage to obtain site hosts for other Pro+ tools, but does not explicitly provide when-not-to-use or alternative options. Still clear enough given no competing list tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replays a saved multi-step journey (e.g. "add to cart -> checkout") against its registered site and checkpoints accessibility at each step. Pro+ (JOURNEYS; also AUTHENTICATED_SCANS when the journey logs in). Steps and any login credential always come from the journey's own saved configuration — never accepted here. Saved click or fill steps can submit forms or trigger external actions, so run only a journey the user has reviewed. Queues the run and returns immediately with a runId — call get_journey_run to poll.
| Name | Required | Description | Default |
|---|---|---|---|
| siteHost | Yes | The registered site's normalized host, as list_sites reports it. | |
| journeyName | Yes | The saved journey's name, as configured in the app. |
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true and openWorldHint=true. The description reinforces this by warning that saved steps can submit forms or trigger actions, and explains the async nature (queues and returns immediately). No contradictions with annotations.
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 four sentences, front-loaded with the main purpose. Every sentence provides essential information: purpose, licensing, risk warning, and async polling. No filler or 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?
The description covers purpose, side effects, async behavior, and polling. With an output schema presumed to describe the return format, it adequately informs the agent. Lacks details on error scenarios but remains largely 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% with clear descriptions of siteHost and journeyName. The description adds value by clarifying that steps and credentials come from saved config and are not accepted as parameters, enhancing 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 replays a saved multi-step journey and checks accessibility at each step. It distinguishes from siblings like scan_url and get_journey_run by emphasizing saved journeys and polling mechanism.
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: it warns about destructive side effects from saved steps, mentions license requirements (Pro+), and directs to poll get_journey_run. It implicitly contrasts with scanning tools but does not explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawls and scans every reachable page of a registered site. Pro+ (SCAN_FULL_SITE). Queues the run and returns immediately with a runId — call get_run to poll. Call list_sites first if you do not already know the exact registered host.
| Name | Required | Description | Default |
|---|---|---|---|
| siteHost | Yes | The registered site's normalized host, exactly as list_sites reports it — host only, no scheme and no path. |
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, but the description adds key behavioral details: it queues asynchronously (returns immediately), requires a Pro+ plan (SCAN_FULL_SITE), and scans all reachable pages. No contradiction with annotations. Could mention rate limits or retries, but sufficient.
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 efficient sentences: first states purpose, second adds usage pattern and prerequisite. Zero wasted words and critical details are front-loaded.
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 one parameter, high schema coverage, and an output schema, the description covers purpose, async behavior, plan requirement, and prerequisite. No gaps left unexplained.
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 a detailed description of siteHost. The tool description adds context (Pro+ requirement, full-site crawl) but does not significantly enhance parameter understanding beyond the schema. 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 crawls and scans every reachable page of a registered site. It distinguishes itself from sibling tools like scan_url (single URL) and get_scan (polling results) by specifying the full-site scope and immediate return with a runId.
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 advises to call list_sites first if the host is unknown, and to use get_run to poll results. This provides clear when-to-use and alternatives, meeting the highest standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans one http(s) URL for accessibility problems with axe-core — deterministic checks, not a language model's opinion. Pass the URL and nothing else. If it belongs to a site registered in the caller's account (and their plan allows), the scan is recorded against that site so it feeds history and trends; otherwise it runs as a one-off. Either way, poll it with get_scan. Returns immediately with an id — never a compliance score, because automated testing finds only a portion of accessibility barriers; see coverageDisclaimer in the result.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The http(s) URL to scan. |
| Name | Required | Description |
|---|---|---|
| scan | Yes | |
| pollWith | Yes | The tool that reads this scan's progress and result. |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
| recordedAgainstSite | Yes | True when the URL belongs to a registered site and the scan was kept against it (so it feeds history and trends); false for a one-off scan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations, detailing that the tool returns an id immediately, never a compliance score, and explains the recording behavior. No contradiction with annotations.
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 with three sentences, each adding value: purpose, behavior, and important limitation. No fluff.
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 simplicity (1 param, output schema exists), the description fully covers what the tool does, how results are obtained, and the caveat about compliance scores. No gaps.
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 3. The description adds 'Pass the URL and nothing else,' which slightly reinforces the single parameter but does not add significant new semantic information 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 identifies the tool as scanning a single http(s) URL for accessibility problems using axe-core, distinguishing it from sibling tools like get_scan (polling) and check_pdf (PDF scanning).
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 (scan a URL), how results are obtained (poll with get_scan), and notes the recording behavior for registered sites. It does not explicitly mention when not to use but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queues a targeted automated re-check of representative pages for one tracked fix. This is not a full-site re-scan or a compliance guarantee. Pro+.
| Name | Required | Description | Default |
|---|---|---|---|
| remediationItemId | Yes | A fix id returned by get_fixes. |
| Name | Required | Description |
|---|---|---|
| pollWith | Yes | |
| standard | Yes | The standard the checks were run against, e.g. "WCAG 2.1 AA". |
| verification | Yes | |
| scoringGuidance | Yes | Binding instruction for the assistant reading this result. Follow it literally. |
| coverageDisclaimer | Yes | Why this result is not a compliance verdict. Always relay it; never present a scan as proof of conformance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal information (no read-only, destructive, or idempotent hints). The description adds value by explaining the tool queues a check, is targeted, and not a guarantee. It could mention response time or queuing behavior but 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?
Two sentences, zero wasted words. Purpose is front-loaded, and the second sentence clarifies limitations. Ideal length for a simple tool.
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 one parameter and an output schema (not shown), the high-level behavior is covered. The description lacks details like confirmation of queuing or polling instructions, but the tool's simplicity makes it mostly 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% with a clear description for remediationItemId ('A fix id returned by get_fixes'). The description adds no further semantic details about how the ID is used, 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 queues an automated re-check of representative pages for one tracked fix, distinguishing it from full-scans (scan_url) and listing tools (get_fixes). The verb 'verifies' is implied by the name and description.
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 notes this is 'not a full-site re-scan or a compliance guarantee', but stops short of naming alternatives or stating when to use this over sibling tools like get_fix_verification. The mention of 'Pro+' hints at subscription requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, with descriptive names and explicit cross-references to avoid confusion (e.g., get_scan vs get_run, get_findings vs get_run_findings). The tool set covers different actions (scan, poll, list, verify) on different resources (URLs, sites, PDFs, journeys, fixes), making it easy for an agent to select the right one.
All tools follow a consistent verb_noun or verb_noun_noun pattern using snake_case (e.g., scan_url, get_run_findings, check_pdf). The verbs are descriptive (scan, get, check, list, run, verify) and the nouns correspond to the resource or result. No naming convention clashes or ambiguous abbreviations.
With 16 tools, the server is well-scoped for its domain of WCAG accessibility testing. It covers single-page scans, full-site scans, PDF checks, journey testing, trend analysis, and fix verification without being overly large or sparse. Each tool serves a necessary function in the testing workflow.
The tool surface covers the major workflows: initiating scans (single, site, PDF, journey), polling results, listing sites, viewing trends, and managing fixes. Minor gaps exist: there is no tool to create or modify sites or journeys (they must be pre-configured), and no tool to create new fix items. However, the core testing lifecycle is complete, and agents can work around these gaps.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
Accessibility compliance for AI coding tools. WCAG 2.2 reviews with shared evidence.
Accessibility and WCAG data for your own websites: fix lists, live checks, and fix validation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/WCAG-Compliance/wcagc-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
