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.