a11y-toolkit

Overview Schema Source Related Servers Discussions Admin

a11y-toolkit: VPAT 2.5 report (WCAG edition)

a11y_generate_vpat

Idempotent

Generate a VPAT 2.5 WCAG 2.2 A/AA conformance report from an a11y_evidence pack: the machine fills Remarks, while a qualified human sets the final conformance levels and signs.

Instructions

Generates a VPAT 2.5 (WCAG edition) accessibility conformance report in accessible HTML from an a11y_evidence pack (or raw audit reports): the full 55-criterion WCAG 2.2 A/AA table with Remarks auto-filled from the pack (status, measured values, examples, remaining human effort) and every Conformance Level starting at Not Evaluated — automated fails force Does Not Support, review-level signals stay Not Evaluated with the evidence in Remarks, and a qualified human sets the rest via overrides (supports, partially_supports, does_not_support, not_applicable, not_evaluated). The document is a DRAFT until the signature block, which must reference the pack sha256, is completed. VPAT is the US/ADA counterpart of a11y_generate_declaration (EU/EAA): the machine fills Remarks, the human signs the claim. — The US/ADA counterpart of a11y_generate_declaration; feed it the a11y_evidence pack — levels stay Not Evaluated until a qualified human sets them. Returns {html, summary {level: count}, levels {code: level}, pack_sha256, draft} — the VPAT draft; writes a file only when output_path is given. Run after the audits you trust; a qualified human must set the final levels (overrides) and sign before publishing — the machine fills Remarks, never the claim.

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": {
      "product": "<product>"
    },
    "name": "a11y_generate_vpat"
  }
}

Input Schema

Name	Required	Description
`lang`	No	Document language (default en)
`pack`	No	a11y_evidence output (evidence pack); alternative to reports
`notes`	No	Additional notes to include
`scope`	No	a11y_scope output: human-confirmed exclusions become Not Applicable with their reason (machine proposals never); overrides still win
`contact`	No	Contact information for questions about this VPAT
`methods`	No	Evaluation methods used (default: honest automated-screening note)
`product`	Yes	Product name as it must appear in the VPAT
`reports`	No	Audit report objects to bundle (when pack is not given, the pack is built here first)
`reviewer`	No	{"name":…, "credential":…, "review_date":…} to prefill the signature block
`overrides`	No	Criterion → conformance level set by a qualified human: {"1.1.1": "supports", "1.2.2": "not_applicable", …}
`output_path`	No	save the VPAT HTML here (optional)
`report_date`	No	VPAT report date ISO (default: today)
`product_description`	No	Product description paragraph

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.27.0Nov 10, 2026

addedInput schema / properties / scope

Added value: +{
+  "description": "a11y_scope output: human-confirmed exclusions become Not Applicable with their reason (machine proposals never); overrides still win",
+  "type": "object"
+}

Addedv5.5.0Oct 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only say non-read-only, idempotent, non-destructive; the description adds far more — the DRAFT status until the signature block references the pack sha256, the rule that automated fails force 'Does Not Support' while review-level signals stay 'Not Evaluated', override precedence, and that a file is written only when output_path is supplied. It even documents the return shape ({html, summary, levels, pack_sha256, draft}) in the absence of an output schema. Slight deduction for not stating idempotency or side effects on repeated runs explicitly.

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?

Front-loaded with the core action and the level logic, which is good, but the trailing segment repeats the same idea three times ('a qualified human sets the rest', 'levels stay Not Evaluated until a qualified human sets them', 'the machine fills Remarks, never the claim'). The core rule could be stated once and the definition would be materially shorter without losing information.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with nested objects and no output schema, the description covers inputs, generation logic, draft/signature gating, return shape, and human-in-the-loop preconditions. An agent has everything needed to call it correctly and to know the result is not publishable as-is.

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 baseline is 3; the description still adds real meaning beyond it, notably override value vocabulary and precedence, how scope exclusions become 'Not Applicable' (human-confirmed only, never machine proposals), pack-vs-reports substitution, and what reviewer prefills. It stops short of explaining interaction details such as what happens when both overrides and automated fails target the same criterion.

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 (generates), specific artifact (VPAT 2.5 WCAG edition in accessible HTML), and specific input (a11y_evidence pack or raw audit reports). It also positions itself against the sibling a11y_generate_declaration as the US/ADA counterpart, so an agent can route between the two without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit sequencing rule ('Run after the audits you trust'), an input alternative (pack, or reports which get bundled into a pack), and a routing rule against the EU/EAA sibling. It also states the hard precondition that a qualified human must set levels and sign before publishing.

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