WCAG Accessibility Audit MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. The server lists its tool without a token; a call needs one. |
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 |
|---|---|
| audit_wcag_accessibilityA | Audit websites for accessibility with axe-core in a real browser. Give one domain or a list; each domain returns one row with the WCAG issues automated checks find (distinct failing rules by impact, affected element count, top failing rules with help links, sample selectors), a 0 to 100 score, European Accessibility Act exposure signals, and optional presence checks for an accessibility statement, an accessibility overlay widget, a privacy policy, a German Impressum, and the US privacy choice link and GPC file. Blocked, timed out, or unreachable sites return a free row that says why. Automated checks find a subset of WCAG failures and the result is never a conformance claim. A run that does not succeed is returned as an error with its run ID. Read-only on the audited sites; requires an APIFY_TOKEN and consumes Apify credits per audited domain. |
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 1 tool
There is only one tool, so there is no possibility of selecting the wrong one. The tool's purpose (run a WCAG accessibility audit via axe-core in a real browser) is unambiguous and clearly stated.
With a single tool, naming is trivially consistent. The name audit_wcag_accessibility follows a clear verb_noun/domain-noun convention that is readable and descriptive.
One tool is borderline thin for a server with this much surface area (single vs. batch domains, multiple presence checks, scoring, EAA signals). It works as a single 'do the audit' entry point, but the lack of any companion tool makes the surface feel under-provisioned.
The audit itself is well-covered, including error rows for blocked/unreachable sites. However, there is no tool to retrieve or re-fetch results for a run ID (which the description says is returned on failure), and no way to list past runs or fetch detailed per-element remediation data, creating a dead end after errors.