a11y-toolkit

Overview Schema Source Related Servers Discussions Admin

a11y-toolkit: Evidence pack (verifiable handoff)

a11y_evidence

Read-onlyIdempotent

Builds a verifiable WCAG evidence pack from audit reports, mapping all 55 A/AA criteria with human-review effort, hashes, timestamps, and a signature block for vendor-neutral review.

Instructions

Builds the verifiable evidence pack: the machine→human handoff object for WCAG conformance work. Takes one or more audit reports (any mode — static, rendered, reflow, keyboard, scroll) and returns: the full 55-criterion A/AA matrix (automated-fail / automated-review / not-flagged — NOT pass / not-run / manual-only), each row priced with its human-effort class (MIN 1-3 / MED 5-10 / MAX 15-30 min of human review remaining) and total remaining minutes every artifact SHA-256-hashed with timestamps, an empty signature block (name, credential, date) whose statement must reference the pack's own sha256, and the tamper-evidence rule stated. Vendor-neutral: any qualified human can review it. Evidence, never conformance. — The tier-3 handoff object; feed it every audit report you have. Returns the pack JSON (a11y-evidence-pack/2) as text content (the agent writes the file). Run after the audits you trust, and pass verified codes from the manual checklist — agent-verified never erases an automated-fail.

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": {
      "reports": "<reports>"
    },
    "name": "a11y_evidence"
  }
}

Input Schema

Name	Required	Description
`lang`	No	Pack language: matrix status labels and notes (en default)
`build`	No	Build reference sealed into the pack sha — the claim→artifact chain: {"commit":…, "ci_url":…} or {"ref": "git:716d870"}
`scope`	No	a11y_scope output: human-confirmed exclusions become not-applicable rows with their reason (machine proposals never exclude)
`reports`	Yes	audit report objects (any mode)
`reviewer`	No	{"name":…, "credential":…, "review_date":…} to prefill the signature block
`snapshot`	No	a11y_snapshot output (optional)
`verified`	No	Criterion codes an agent/human verified against this sample (manual checklist protocol) — they become agent-verified in the matrix; automated-fail stays fail

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv5.27.0Nov 10, 2026

addedInput schema / properties / build

Added value: +{
+  "description": "Build reference sealed into the pack sha — the claim→artifact chain: {\"commit\":…, \"ci_url\":…} or {\"ref\": \"git:716d870\"}",
+  "type": "object"
+}

addedInput schema / properties / lang

Added value: +{
+  "description": "Pack language: matrix status labels and notes (en default)",
+  "enum": [
+    "en",
+    "es"
+  ],
+  "type": "string"
+}

addedInput schema / properties / scope

Added value: +{
+  "description": "a11y_scope output: human-confirmed exclusions become not-applicable rows with their reason (machine proposals never exclude)",
+  "type": "object"
+}

Changed7 schema fields changedv5.0.0Sep 23, 2026

removedInput schema / properties / evaluador

Removed value: -{
-  "description": "{\"nombre\":…, \"credencial\":…, \"fecha_revision\":…} to prefill the signature block",
-  "type": "object"
-}

removedInput schema / properties / informes

Removed value: -{
-  "description": "audit report objects (any mode)",
-  "items": {
-    "type": "object"
-  },
-  "type": "array"
-}

addedInput schema / properties / reports

Added value: +{
+  "description": "audit report objects (any mode)",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / reviewer

Added value: +{
+  "description": "{\"name\":…, \"credential\":…, \"review_date\":…} to prefill the signature block",
+  "type": "object"
+}

removedInput schema / properties / verificados

Removed value: -{
-  "description": "Criterion codes an agent/human verified against this sample (manual checklist protocol) — they become agent-verified in the matrix; automated-fail stays fail",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedInput schema / properties / verified

Added value: +{
+  "description": "Criterion codes an agent/human verified against this sample (manual checklist protocol) — they become agent-verified in the matrix; automated-fail stays fail",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "informes"
-]New value: +[
+  "reports"
+]

Changed1 schema field changedv4.0.0Sep 22, 2026

addedInput schema / properties / verificados

Added value: +{
+  "description": "Criterion codes an agent/human verified against this sample (manual checklist protocol) — they become agent-verified in the matrix; automated-fail stays fail",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv3.12.0Sep 15, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare this a safe, idempotent, local read; the description carries far more: the pack's schema id (a11y-evidence-pack/2), that output is returned as text content and the agent must write the file, that artifacts are SHA-256 hashed with timestamps, and the explicit 'agent-verified never erases an automated-fail' invariant. The 'Evidence, never conformance' caveat is a genuinely non-obvious behavioral boundary that no annotation conveys.

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 purpose is front-loaded, but the middle is an unpunctuated run-on ('...total remaining minutes every artifact SHA-256-hashed with timestamps...') that is hard to parse. The trailing sentences repeat earlier points ('The tier-3 handoff object', 'Run after the audits you trust') and could be trimmed without losing 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 and seven parameters including nested objects, the description does the heavy lifting: it describes the return payload, its schema id, and the handoff-write responsibility. Minor gaps remain, such as accepted report formats and any size limits, but nothing critical for correct invocation is missing.

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 coverage is 100%, so every parameter including nested build/scope/reviewer objects is already documented in the schema. The description reinforces two semantics (verified codes become agent-verified; scope's human-confirmed exclusions become not-applicable rows) but largely restates what the schema descriptions already state, so it adds little beyond the baseline.

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?

The description names a specific verb and artifact: 'Builds the verifiable evidence pack: the machine→human handoff object for WCAG conformance work.' It also enumerates the return payload (55-criterion matrix, effort classes, SHA-256 hashes, signature block), which sharply separates it from generation siblings like a11y_generate_vpat or a11y_ledger.

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?

It gives clear ordering and input guidance: 'Run after the audits you trust,' 'feed it every audit report you have,' and 'pass verified codes from the manual checklist.' It stops short of naming a specific sibling to use instead for individual audits, but the tier-3 positioning makes the upstream/downstream relationship unambiguous.

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