Skip to main content
Glama
kinti

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Evidence pack (countersignature-ready)

a11y_evidence
Read-onlyIdempotent

Turn audit reports into a WCAG evidence pack with per-criterion effort estimates, SHA-256 hashes, and a ready signature block for human countersignature.

Instructions

Builds the COUNTERSIGNATURE-READY 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 (the quote input for a review marketplace), 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 countersign it. Evidence, never conformance. — The tier-3 handoff object; feed it every audit report you have.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reportsYesaudit report objects (any mode)
reviewerNo{"name":…, "credential":…, "review_date":…} to prefill the signature block
snapshotNoa11y_snapshot output (optional)
verifiedNoCriterion 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.

  1. Changed7 schema fields changedv5.0.0
    • 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"
+]
  2. Changed1 schema field changedv4.0.0
    • 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"
+}
  3. Addedv3.12.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses rich behavioral traits: the exact 55-criterion matrix values ('automated-fail / automated-review / not-flagged — NOT pass / not-run / manual-only'), per-row human-effort classes, SHA-256 hashing with timestamps, the empty signature block, the tamper-evidence rule, and the core stance 'Evidence, never conformance.' This significantly exceeds what the annotations already provide.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: it front-loads the core purpose, then covers input acceptance, output contents, pricing semantics, hashing, signature requirements, tamper evidence, and vendor neutrality. Despite its length, it is structured as one coherent specification rather than padded prose, which is appropriate for a complex tool with no output schema.

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 complex aggregation tool with nested objects and no output schema, the description is remarkably complete. It specifies what inputs are accepted, exactly what the returned pack contains, how criteria are classified, how human effort is priced, how artifacts are hashed, what the signature block requires, and the tamper-evidence rule. An agent has enough context to invoke it correctly and understand the return value.

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 parameters are already documented in the input schema. The description adds useful context about the reports parameter ('any mode') and the overall purpose of reviewer/snapshot inputs, but it does not substantially enrich the meaning of individual parameters beyond what the schema provides. The brief mention of an 'empty signature block' while the schema has a reviewer parameter for prefilling could cause minor ambiguity but is not contradictory.

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 states a specific action and resource: 'Builds the COUNTERSIGNATURE-READY evidence pack' with a defined role as 'the machine→human handoff object for WCAG conformance work.' It also distinguishes itself from siblings by calling itself 'The tier-3 handoff object' and specifying that it aggregates 'every audit report you have,' which clearly separates it from audit-generation or snapshot tools.

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?

The description gives clear guidance on when to use the tool: 'Takes one or more audit reports (any mode — static, rendered, reflow, keyboard, scroll)' and instructs to 'feed it every audit report you have.' It does not explicitly name excluded scenarios or route to alternatives, but the input conditions and handoff purpose are clear enough for an agent to select it appropriately.

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