Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Applicability scope (semi-automatic)

a11y_scope
Read-onlyIdempotent

Proposes accessibility applicability exclusions from audit evidence, then requires human confirmation before confirmed exclusions become not-applicable in conformance reports.

Instructions

Semi-automatic applicability scoping — the layer between the audit and the conformance claim (the pattern of the Government of Canada CIO wizard for EN 301 549, informed by the audit instead of 118 hand-answered questions). Reads the features block of the reports (media elements, form controls — positive evidence of what the audit SAW) and proposes the structural exclusions: no video anywhere → 1.2.x proposed-excluded, no form controls → 3.3.x proposed-excluded. The machine PROPOSES, the human CONFIRMS via answers {"1.2.4": {"status": "excluded", "reason": "…"}} — only confirmed exclusions may become not-applicable downstream (a11y_evidence, a11y_generate_vpat, a11y_generate_openacr); a proposal never excludes. standard=en301549 adds the EN 301 549 V4.1.1 (2026) clause to every row (9.x web / 10.x documents / 11.x software — numbering verified 55/55 A/AA) and the EN-only families (5, 6, 7, 8, 12, 13) as honest applicability rows this toolkit does not evaluate. Live counter: N of 55 criteria in scope. — The applicability layer before conformance: run after the audits, confirm the machine proposals via answers, then feed the scope here — a11y_evidence/vpat/openacr turn confirmed exclusions into not-applicable with their reason. Returns JSON: {format: a11y-scope/1, standard, target, criteria [{criterion, level, status, clause?, evidence?, reason?}], counters, en301549_families?, sha256} — statuses in-scope|proposed-excluded|excluded; only human-confirmed exclusions count downstream. Run after the audits, before any conformance artifact: confirm the machine proposals via answers, then pass the scope to a11y_evidence — only human-confirmed exclusions become not-applicable, and each exclusion carries its reason.

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

Input Schema

NameRequiredDescriptionDefault
langNooutput language (en default)
targetNoICT target: web=9.x clauses (default), documents=10.x, software=11.x
answersNohuman confirmations keyed by criterion code: status in-scope|proposed-excluded|excluded
reportsYesaudit report objects (any mode; reports carrying the features block power the machine proposals)
targetsNocombined scope across ICT targets (like GSA ART multi-item); rows carry a clauses dict per target
standardNowcag22 (default), en301549 (clause refs + EN families) or rgaa (French 106-criterion checklist)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.27.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower; the description adds the non-obvious propose/confirm semantics and downstream effect on not-applicable statuses. It is less explicit about counter behavior or how EN-only family rows are marked, minor gaps against strong annotation coverage.

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

Conciseness2/5

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

Repeats the same sequencing rule (run after audits, confirm via answers, only confirmed exclusions count) and the return-shape summary two to three times. The intent is front-loaded but the description is bloated for a scoping tool.

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?

Describes the return JSON structure and status enum even without an output schema, covering what an agent needs to interpret results. The duplication is a style problem rather than a missing-information gap.

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 adds meaning by explaining that the features block of reports powers proposals, showing the answers shape with a concrete example, and clarifying what target/targets and standard (clause refs, EN-only families) do.

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 (scope applicability) and resource (criteria sets from audit reports), and positions itself as the layer between audits and conformance artifacts. Names downstream siblings (a11y_evidence, a11y_generate_vpat, a11y_generate_openacr) so the agent can tell it apart from them.

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?

Explicit sequencing: run after the audits, confirm machine proposals via answers, then feed the scope here. Also states negative conditions — a proposal never excludes, only human-confirmed exclusions become not-applicable downstream.

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