Skip to main content
Glama
kinti

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Deterministic safe auto-fixes

a11y_autofix
Read-onlyIdempotent

Applies deterministic safe HTML accessibility fixes for WCAG 1.4.4 zoom and 1.3.5 autocomplete, filling missing lang and title. Returns fixed_html plus applied and not_applied lists 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}]} — writes a file only when output_path is given.

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

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely useful behavior – the allowlist boundary, that rejections carry remediation text, and the {fixed_html, applied, not_applied} shape. However it claims it 'writes a file only when output_path is given' while no output_path parameter exists in the schema, and a file write would also sit awkwardly against readOnlyHint=true, so an agent could be misled about side effects.

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 core purpose is front-loaded, but the text repeats itself: 'Returns fixed_html + applied + not_applied' is immediately followed by a second 'Returns JSON: {fixed_html, applied, not_applied}' block, and the allowlist-only constraint is stated twice with an em-dash. Roughly a third of the text is duplication rather than new information.

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 correctly carries the return-shape burden and explains what appears in applied vs not_applied. For a 5-parameter mutator it is nearly complete, but the phantom output_path reference and the untouched default behavior of form_errors leave a small gap an agent would have to resolve from the schema alone.

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 is 3; each parameter is already documented in the schema ('only if provided and <title> is empty', 'default: (html)'). The description restates the lang/title conditions and the default-true form-error layer without adding syntax, format, or interaction detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource combination (deterministic safe auto-fixes applied to HTML) and immediately bounds it: a closed allowlist of unique-answer fixes (1.4.4 zoom, 1.3.5 autocomplete, html lang, empty title). It implicitly distinguishes itself from the audit/check siblings by declaring judgment fixes out of scope, but never names a sibling tool explicitly, so the differentiation is inferential rather than stated.

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?

Gives a clear when-to-use condition (only issues with a provably unique fix) and an explicit when-not (alt text, contrast, accessible names are NOT touched, returning not_applied with remediation). It does not route the agent to a specific sibling for the judgment cases, which keeps it below a 5.

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