Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Sealed patch-set (sha-keyed)

a11y_patches
Read-onlyIdempotent

Build a SHA-256-keyed record of deterministic accessibility autofixes, then verify it against HTML to confirm the same page reproduces the fixes and detect stale patch sets before CI/agent use.

Instructions

Sealed patch-set of the deterministic safe fixes: build runs a11y_autofix once and records WHICH fixes were applied to WHICH page (SHA-256-keyed, format a11y-patches/1, engine version stamped); verify re-checks a set against a page — the same page must reproduce the same fixes, a different page is stale (sets never blind-apply). The artifact an agent or CI applies upstream: fixing the original web is the client job, the engine hands over the evidence.

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_patches"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlYesraw HTML
langNooutput language (en default)
titleNotitle for the fixed copy (build only)
actionNobuild: run autofix and seal the record (default); verify: check patch_set against this html
patch_setNoa11y-patches/1 artifact (verify only)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.27.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds real value on top by explaining determinism (same page must reproduce the same fixes), staleness semantics for mismatched pages, SHA-256 keying, format versioning, and engine-version stamping. It does not contradict the annotations: build produces a returned artifact rather than mutating external state. What it omits is the shape of the verify verdict and any cost/size considerations for large pages.

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?

Purpose is front-loaded in the first clause, which is good, but the text is a dense semicolon-chained run-on that mixes operational detail with framing language. The closing sentence ('fixing the original web is the client job, the engine hands over the evidence') is motivational positioning rather than information an agent needs to invoke the tool correctly, so not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 a nested artifact object and no output schema, the description covers the build side well but says nothing about what verify returns (a fresh/stale verdict, a diff of fixes, an error?). That is the main decision an agent makes after calling it, and with no output schema the description carries the burden. It is otherwise adequate given the strong schema coverage.

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 schema already documents all five parameters and the baseline would be 3. The description goes beyond it by explaining that patch_set is the a11y-patches/1 artifact consumed by verify and that the record is keyed to a specific page, which gives the action/patch_set pairing real semantic weight. It still does not say what happens if action is build while patch_set is supplied, or how lang/title interact with the sealed record.

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?

The description names the resource (a sealed patch-set of deterministic safe fixes) and both operations (build seals a record of which fixes hit which page; verify re-checks a set against a page). It also positions the tool relative to a11y_autofix by stating that build runs the autofix once and records the outcome, so an agent can tell it is a provenance/verification layer rather than the fixer itself. The jargon ('sealed', 'SHA-keyed', 'a11y-patches/1') slightly obscures the plain statement of purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: build when you want a reproducible record, verify when you need to check whether a set still matches a page, and the note that 'sets never blind-apply' and 'a different page is stale' hints at the failure mode. However, it never explicitly says when to pick this over siblings like a11y_autofix, a11y_diff, or a11y_evidence, nor does it state prerequisites or ordering beyond build-before-verify.

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