wcagc-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WCAGC_MCP_KEY | Yes | wcagc API key with the mcp:scan scope | |
| WCAGC_API_BASE_URL | No | Only for self-hosting; defaults to https://api.wcagc.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_urlA | 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. |
| get_scanA | 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. |
| get_findingsA | 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. |
| check_pdfA | 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. |
| get_pdf_checkA | Polls a PDF check started by check_pdf — status, failed-rule and failed-check counts, and a failure reason if it did not complete. |
| list_sitesA | Lists this organization's registered sites — their normalized hosts are what every other Pro+ tool takes as siteHost. Pro+ (requires sites:read + API_ACCESS). |
| scan_siteA | 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. |
| get_runA | 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. |
| get_run_findingsA | 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. |
| get_root_causesA | 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+. |
| run_journeyA | 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. |
| get_journey_runA | Polls a run started by run_journey — per-step checkpoints and, once terminal, a failure reason if a step failed. Pro+. |
| get_trendsA | 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). |
| get_fixesA | Lists tracked remediation items for a registered site, including status and the scope of any automated verification proof. Pro+ (REMEDIATION_TRACKING). |
| verify_fixA | 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+. |
| get_fix_verificationB | Polls a targeted fix verification and reports only what was detected on the selected pages checked. Pro+. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools are clearly scoped to distinct resources and actions: scan_url/scan_site, check_pdf, run_journey, and verify_fix each have their own dedicated polling tool. The many get_* tools could be confused at a glance, but descriptions explicitly cross-reference which poller to use for each job type.
All tools follow a consistent lowercase snake_case verb_noun pattern (scan_url, list_sites, get_run_findings, verify_fix). Paired queue/poll tools are predictably named (check_pdf -> get_pdf_check, run_journey -> get_journey_run), making the set easy to navigate.
16 tools is slightly above the ideal 3-15 range but each tool maps to a distinct stage in the scanning pipeline: initiating a job, polling it, retrieving findings, and listing supporting resources. The count feels justified by the breadth of scan types rather than redundant.
The surface covers the core lifecycle for URL scans, full-site runs, PDF checks, journeys, trend history, and fix verification. Minor gaps exist — no site registration/update/delete and no cancellation or re-run operations — but these are likely managed outside the MCP and don't block primary workflows.