a11y-toolkit

Overview Schema Source Related Servers Discussions Admin

a11y-toolkit: Accessibility statement (EAA/RD 1112)

a11y_generate_declaration

Idempotent

Generate an accessible legal accessibility statement in HTML for RD 1112/2018 or EAA compliance, optionally saving it to a file.

Instructions

Generates an Accessibility Statement in HTML: art. 10 RD 1112/2018 (Spanish public sector, framework="rd1112") or European Accessibility Act wording (Directive (EU) 2019/882 / Ley 11/2023, framework="eaa"; EN output uses Directive (EU) 2016/2102 / EAA wording). The generated document is itself accessible. Saves to output_path when given. — Legal statement generator; drive inaccessible_content from audit findings and a11y_evidence. Returns {html, summary} — the accessible legal statement; writes a file only when output_path is given.

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": {
      "entity": "<entity>",
      "url": "<url>",
      "status": "<status>"
    },
    "name": "a11y_generate_declaration"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Website URL the statement covers
`lang`	No	Statement language (default en; es uses the Spanish legal wording)
`entity`	Yes	Legal entity name as it should appear in the statement
`method`	No	How conformance was evaluated (e.g. "self-evaluation: a11y-toolkit screening + manual review")
`status`	Yes	Compliance state: full \| partial \| not_conformant (plena \| parcial \| no_conforme, pre-5.11, still accepted as aliases)
`feedback`	No	Contact channel for accessibility feedback (email or URL)
`framework`	No	rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)
`complaints`	No	Claim/complaint procedure URL or address (legally required in several jurisdictions)
`output_path`	No	save the HTML here (optional)
`review_date`	No	ISO date of the next scheduled review
`evaluation_date`	No	ISO date of the last evaluation (YYYY-MM-DD)
`alternative_format`	No	Where to get the content in an alternative accessible format
`inaccessible_content`	No	Non-accessible content list: one string per item, ideally criterion + reason + alternative

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv5.14.0Oct 23, 2026

addedInput schema / properties / alternative_format

Added value: +{
+  "description": "Where to get the content in an alternative accessible format",
+  "type": "string"
+}

addedInput schema / properties / complaints

Added value: +{
+  "description": "Claim/complaint procedure URL or address (legally required in several jurisdictions)",
+  "type": "string"
+}

removedInput schema / properties / disponibilidad_alternativa

Removed value: -{
-  "description": "Where to get the content in an alternative accessible format",
-  "type": "string"
-}

changedInput schema / properties / entity / description

Previous value: -"Legal entity name as it should appear in the statement (company, body…)"New value: +"Legal entity name as it should appear in the statement"

addedInput schema / properties / evaluation_date

Added value: +{
+  "description": "ISO date of the last evaluation (YYYY-MM-DD)",
+  "type": "string"
+}

removedInput schema / properties / fecha_evaluacion

Removed value: -{
-  "description": "ISO date of the last evaluation (YYYY-MM-DD)",
-  "type": "string"
-}

changedInput schema / properties / framework / description

Previous value: -"Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"New value: +"rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"

addedInput schema / properties / method

Added value: +{
+  "description": "How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")",
+  "type": "string"
+}

removedInput schema / properties / metodo

Removed value: -{
-  "description": "How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")",
-  "type": "string"
-}

removedInput schema / properties / reclamacion

Removed value: -{
-  "description": "Claim/complaint procedure URL or address (legally required in several jurisdictions)",
-  "type": "string"
-}

changedInput schema / properties / status / description

Previous value: -"Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)"New value: +"Compliance state: full | partial | not_conformant (plena | parcial | no_conforme, pre-5.11, still accepted as aliases)"

changedInput schema / properties / status / enum

Previous value: -[
-  "plena",
-  "parcial",
-  "no_conforme"
-]New value: +[
+  "full",
+  "partial",
+  "not_conformant"
+]

Changed11 schema fields changedv5.0.0Sep 23, 2026

removedInput schema / properties / contenido_no_accesible

Removed value: -{
-  "description": "Non-accessible content list: one string per item, ideally criterion + reason + alternative",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / entidad

Removed value: -{
-  "description": "Legal entity name as it should appear in the statement (company, body…)",
-  "type": "string"
-}

addedInput schema / properties / entity

Added value: +{
+  "description": "Legal entity name as it should appear in the statement (company, body…)",
+  "type": "string"
+}

removedInput schema / properties / estado

Removed value: -{
-  "description": "Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)",
-  "enum": [
-    "plena",
-    "parcial",
-    "no_conforme"
-  ],
-  "type": "string"
-}

removedInput schema / properties / fecha_revision

Removed value: -{
-  "description": "ISO date of the next scheduled review",
-  "type": "string"
-}

addedInput schema / properties / framework

Added value: +{
+  "description": "Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)",
+  "enum": [
+    "rd1112",
+    "eaa"
+  ],
+  "type": "string"
+}

addedInput schema / properties / inaccessible_content

Added value: +{
+  "description": "Non-accessible content list: one string per item, ideally criterion + reason + alternative",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / marco

Removed value: -{
-  "description": "Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)",
-  "enum": [
-    "rd1112",
-    "eaa"
-  ],
-  "type": "string"
-}

addedInput schema / properties / review_date

Added value: +{
+  "description": "ISO date of the next scheduled review",
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)",
+  "enum": [
+    "plena",
+    "parcial",
+    "no_conforme"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "entidad",
-  "url",
-  "estado"
-]New value: +[
+  "entity",
+  "url",
+  "status"
+]

Changed12 schema fields changedv4.0.0Sep 22, 2026

addedInput schema / properties / contenido_no_accesible / description

Added value: +"Non-accessible content list: one string per item, ideally criterion + reason + alternative"

addedInput schema / properties / disponibilidad_alternativa / description

Added value: +"Where to get the content in an alternative accessible format"

addedInput schema / properties / entidad / description

Added value: +"Legal entity name as it should appear in the statement (company, body…)"

addedInput schema / properties / estado / description

Added value: +"Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)"

addedInput schema / properties / fecha_evaluacion / description

Added value: +"ISO date of the last evaluation (YYYY-MM-DD)"

addedInput schema / properties / fecha_revision / description
```
Added value: +"ISO date of the next scheduled review"
```

addedInput schema / properties / feedback / description

Added value: +"Contact channel for accessibility feedback (email or URL)"

addedInput schema / properties / lang / description

Added value: +"Statement language (default en; es uses the Spanish legal wording)"

addedInput schema / properties / marco / description

Added value: +"Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"

addedInput schema / properties / metodo / description

Added value: +"How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")"

addedInput schema / properties / reclamacion / description

Added value: +"Claim/complaint procedure URL or address (legally required in several jurisdictions)"

addedInput schema / properties / url / description

Added value: +"Website URL the statement covers"

Changed2 schema fields changedv3.3.0Sep 13, 2026

removedInput schema / properties / lang / description

Removed value: -"Idioma de la declaración (es por defecto; en = Directive (EU) 2016/2102 / EAA wording)"

changedInput schema / properties / output_path / description

Previous value: -"Guarda el HTML en esta ruta (opcional)"New value: +"save the HTML here (optional)"

First observedv2.3.0Aug 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and idempotentHint=true, and the description usefully explains why: it returns {html, summary} and writes a file only when output_path is supplied, so the agent knows the mutation is caller-controlled and repeatable. It also discloses that the generated document is itself accessible, a non-obvious guarantee. It does not cover overwrite behavior for an existing output_path, keeping it from a 5.

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

Conciseness4/5

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

The core sentence is front-loaded with the artifact and framework choices, and the trailing block after the em-dash concentrates the return shape and output_path rule. That trailing block partially restates the opening ('Legal statement generator'), costing some efficiency but not clarity.

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?

For a 13-parameter generator with no output schema, the description compensates well by naming the return shape {html, summary} and the file-write condition. Required-field expectations (entity, url, status) and defaults are left to the schema; little else is missing for correct invocation.

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 is already documented, establishing a baseline of 3. The description adds the framework-to-law mapping and a nuance not in the schema ('EN output uses Directive (EU) 2016/2102 / EAA wording'), but it repeats the rest of the enum semantics already present in the schema.

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 and artifact ('Generates an Accessibility Statement in HTML') and immediately disambiguates the two legal frameworks with concrete citations (art. 10 RD 1112/2018 vs Directive (EU) 2019/882 / Ley 11/2023). This distinguishes it from document-generating siblings like a11y_generate_openacr and a11y_generate_vpat, which produce different artifacts.

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?

Gives actionable sourcing guidance ('drive inaccessible_content from audit findings and a11y_evidence') and conditional behavior for when a file is emitted ('Saves to output_path when given'). It stops short of explicitly naming when to prefer this over other statement/VPAT generators, so it is clear context rather than full routing.

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