Pandus Accessibility

Explain an accessibility rule

explain_rule

Read-only

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.

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": {
      "rule": "<rule>"
    },
    "name": "explain_rule"
  }
}

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

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

Purpose5/5

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.

Usage Guidelines4/5

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.

All Pandus Accessibility tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?