WCAG 2.2 rule reference for free; with an API key: what to fix on your sites and new checks.
Scored across 3 tools
explain_rule and explain_wcag_criterion target different inputs (axe rule ID vs WCAG criterion number), and search_rules is a distinct retrieval action. Some overlap remains because search_rules also accepts WCAG criteria, so a careless agent might search instead of explain.
All tool names use snake_case with a verb_noun pattern. The two explain_ tools share a consistent prefix, and search_rules follows the same readable convention.
Three tools is well-scoped for a read-only reference service. Each tool has a clear, non-redundant purpose, and no essential sibling operation is obviously missing.
Core operations are covered: explain an axe rule, explain a WCAG criterion, and search the rule library. There is no list or browse tool for all rules or criteria, which is a minor discoverability gap.
Explains one accessibility rule (an axe-core rule id such as image-alt or color-contrast): what is wrong, why it matters for customers, who is affected, how to fix it in code and on Shopify, WooCommerce, PrestaShop or Shoptet, and the WCAG 2.2 / EN 301 549 clauses. Free, no API token needed.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | axe-core rule id, for example image-alt. | |
| locale | No | Language of the card. | en |
| platform | No | Only the tip for this platform, for example shopify or woocommerce. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds real context beyond it: no API token or cost, plus the exact content produced (what is wrong, who is affected, code and platform fixes, WCAG 2.2 / EN 301 549 clauses). It does not say how an unknown rule id is handled, but the added behavioral context is substantial for an annotation-covered read tool.
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?
Front-loaded with the verb and resource, then a compact enumeration of the output contents. The single long sentence is dense but every clause maps to a distinct piece of returned information; the closing 'Free, no API token needed' earns its place as a usage signal.
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 no output schema, the description usefully enumerates what the explanation contains (cause, impact, affected users, code and CMS fixes, WCAG/EN clauses), and covers auth/cost. Nothing critical is missing for a read-only, 3-parameter lookup tool, though error behavior for invalid rule ids is unstated.
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 the baseline is 3, but the description goes further by defining what 'rule' means (axe-core rule id) and by enumerating supported platforms (Shopify, WooCommerce, PrestaShop, Shoptet) that the platform parameter's schema text does not list. It adds no detail on locale beyond what the schema enum already 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?
Specific verb ('Explains') plus a tightly scoped resource ('one accessibility rule'), with concrete axe-core id examples (image-alt, color-contrast) that make the input shape unambiguous. The scope 'one rule' also cleanly separates it from the sibling explain_wcag_criterion.
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 establishes clear context: it is for a single axe-core rule id, with examples of valid ids and a note that it is free and requires no API token. It does not explicitly route the agent to search_rules to discover a rule id or to explain_wcag_criterion for criterion-level questions, so no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains a WCAG 2.2 level A or AA success criterion (for example 2.4.7) in plain words: what it asks, examples, how to test it by hand and what automated checks can and cannot find. Free, no API token needed.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of the text. | en |
| criterion | Yes | WCAG success criterion number, for example 1.4.3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, so the description earns credit for adding output-shape information: what the criterion asks, examples, manual testing steps, and the limits of automated checks. It also discloses the auth/cost situation (free, no token). No output schema exists, so this return-format context is genuinely valuable.
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?
A single front-loaded sentence with the verb and scope first, followed by a colon list of what the output covers. Every clause earns its place, though the list plus the trailing 'Free, no API token needed' makes it slightly dense.
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 read-only lookup tool with no output schema, the description covers purpose, scope (levels A/AA), output contents, and auth requirements. It omits any mention of the locale option or supported languages, which the schema does carry, so it is nearly but not fully 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 description coverage is 100%, with both parameters (criterion, locale enum) fully documented in the schema itself. The description reinforces the criterion format with an example but adds no semantics beyond what the schema provides, so the 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?
States a specific verb (Explains) and resource (a WCAG 2.2 level A or AA success criterion), with an example (2.4.7) and a scope of WCAG 2.2 levels A/AA. This is enough to distinguish it from the sibling explain_rule, which covers a different artifact type.
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 when to use it via its scope (success criteria, levels A/AA), and mentions it is free with no API token. However, it never states when to prefer it over explain_rule or search_rules, nor any exclusion conditions. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the Pandus library of accessibility rule cards (the axe-core rules Pandus checks, explained for business owners) by words, an axe rule id or a WCAG success criterion such as 1.4.3. Free, no API token needed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Words, an axe-core rule id (color-contrast) or a WCAG criterion (1.4.3). | |
| locale | No | Language of the texts. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already marks this as a safe read, but the description adds genuinely new behavioral context: that access is 'Free, no API token needed,' which tells the agent authentication isn't a barrier. It stops short of describing result volume, ranking, or pagination.
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 tight sentences with no filler, and the core purpose is front-loaded before the clarifying aside. Minor repetition of 'Pandus' and a slightly nested parenthetical keep it from a clean 5.
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 two-parameter search tool with no output schema and full schema coverage, the description is largely sufficient. It could say more about what a result looks like or how it relates to the explain_* siblings, but nothing critical to correct invocation is missing.
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 schema already documents both query and locale. The description's enumeration of query forms and the 1.4.3 example merely restate what the schema (and its description) already say, so the baseline of 3 applies.
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?
States a specific verb (Searches) and resource (Pandus library of accessibility rule cards), and clarifies what those cards actually are (axe-core rules explained for business owners). It does not, however, name the sibling tools explain_rule or explain_wcag_criterion to draw a boundary between searching and explaining.
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?
Usage is only implied: the accepted query forms (words, axe rule id, WCAG criterion) suggest when to reach for it. There is no explicit when-not or named alternative, even though explain_rule and explain_wcag_criterion are obvious candidates for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_ruleexplain_wcag_criterionsearch_rulesAccessibility and WCAG data for your own websites: fix lists, live checks, and fix validation.
Scan URLs or HTML for WCAG 2.2 violations. 75-rule manifest, weighted score, shareable reports.
Accessibility compliance for AI coding tools. WCAG 2.2 reviews with shared evidence.
Free WCAG 2.2/ADA/508 accessibility MCP: scan, AI fixes, verify, vision audit, localhost tunnel
Add one secure layer between your agents and this server.
