a11y-toolkit: Form error testing

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only and idempotent annotations, the description discloses that the tool actually submits the form with invalid data, which is a significant behavioral trait. It also notes edge cases like native validation and forms that navigate on submit, providing transparency about limitations. This adds value beyond the annotations.

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?

The description is informative but slightly long; it front-loads the purpose and then details the flow and edge cases. It uses punctuation effectively to organize information. It could be trimmed, but it remains readable and well-structured.

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?

The description explains the tool's purpose, process, and limitations, including how it handles novalidate and navigation-on-submit. However, it does not describe the output format or return value, which might be expected from a testing tool. Given the absence of an output schema, this is a minor gap.

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?

The input schema already documents all four parameters with descriptions (100% coverage). The description does not add further parameter-specific details beyond mentioning the Playwright requirement, which is a prerequisite rather than a parameter. Thus, the description adds minimal value to parameter semantics.

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?

The description clearly states the tool tests form error identification and suggestion (WCAG 3.3.1 and 3.3.3). It specifies the exact flow: fills invalid data, submits, and checks the post-submit DOM. This distinguishes it from sibling tools like a11y_audit_url, which do general accessibility audits.

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 this tool is for form error testing, but it doesn't explicitly state when to use it versus other a11y tools. It mentions a prerequisite (local Playwright) but doesn't describe alternatives or exclusions. The context is clear enough for an agent to infer, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.