Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Deterministic safe auto-fixes

a11y_autofix
Read-onlyIdempotent

Applies deterministic, allowlisted HTML accessibility fixes for viewport zoom, autocomplete tokens, missing lang, and empty title; returns fixed HTML and applied/not-applied issues with remediation.

Instructions

DETERMINISTIC safe auto-fixes applied to HTML — the honest anti-overlay: a short closed list of fixes where the correct answer is unique (unblock viewport zoom 1.4.4, add the exact autocomplete token 1.3.5, fill missing html lang and empty title when provided). Everything requiring judgment (alt text, contrast, accessible names) is NOT touched — it returns not_applied with the reason and remediation instead. Returns fixed_html + applied + not_applied. — Only the closed allowlist of provably safe fixes; judgment fixes come back as not_applied with remediation. Returns JSON: {fixed_html, applied [{fix, …}], not_applied [{issue, remediation}]} as text content (the agent writes the file).

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": {
      "html": "<html>"
    },
    "name": "a11y_autofix"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoURL context for the report metadata (default: "(html)")
htmlYesraw HTML to fix
langNoonly if provided and <html> lacks lang
titleNoonly if provided and <title> is empty
form_errorsNoinject the accessible form-error layer into forms without their own handling (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.6.0
    • addedInput schema / properties / form_errors
      Added value: +{
+  "description": "inject the accessible form-error layer into forms without their own handling (default true)",
+  "type": "boolean"
+}
    • addedInput schema / properties / url
      Added value: +{
+  "description": "URL context for the report metadata (default: \"(html)\")",
+  "type": "string"
+}
  2. Addedv3.3.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the fix set is a closed allowlist, judgment fixes are returned rather than attempted, the return payload is {fixed_html, applied, not_applied}, and crucially the agent must write the file itself. That last point is the kind of operational detail annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead is well front-loaded, but the same information is stated twice: the return payload appears both as prose ("Returns fixed_html + applied + not_applied") and again as a JSON signature, and the closed-allowlist point is repeated in the trailing sentence. Two sentences of duplication could be cut without loss.

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?

For a 5-parameter tool with full schema coverage, no output schema, and safety annotations, the description covers purpose, scope boundaries, return shape, and the write-it-yourself caveat. Minor gaps remain: form_errors behavior, what happens if the HTML is already compliant, and the url metadata field are left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline applies. The description echoes the lang/title conditional behavior already documented in the schema ("when provided") and says nothing about the form_errors toggle or the url metadata parameter, so it adds little beyond the structured fields.

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?

States a specific verb and resource ("deterministic safe auto-fixes applied to HTML") plus a concrete closed allowlist with named WCAG criteria (1.4.4 zoom, 1.3.5 autocomplete, html lang, empty title). It explicitly distinguishes itself from judgment-based work (alt text, contrast, accessible names) which is what separates it from audit/patch siblings.

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?

Clear about when this tool is the right choice: only for fixes with a unique correct answer, with everything judgment-based routed to not_applied plus remediation. It does not name sibling alternatives (e.g. a11y_patches or a11y_audit_dom) or state preconditions such as 'run the audit first', so the routing is implied rather than explicit.

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

Deploy Server

Other Tools