Skip to main content
Glama
kinti

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Express WCAG audit

a11y_audit_url
Read-onlyIdempotent

Audit a URL or HTML string for WCAG 2.2 accessibility issues, returning 20+ automated signals with a weighted score and remediation steps.

Instructions

Express WCAG 2.2 audit of a URL or an HTML string: 20+ automated signals with a weighted 0-100 score — images without alt (1.1.1), controls without accessible names (4.1.2), form fields without labels (3.3.2), missing autocomplete on user-data fields (1.3.5), click handlers on non-interactive elements (2.1.1), unknown ARIA roles and broken aria-labelledby (4.1.2), duplicated unnamed landmarks, timed meta refresh (2.2.1), missing skip mechanism (2.4.1), lang/title (3.1.1, 2.4.2), heading structure (1.3.1), blocked zoom (1.4.4), captions (1.2.2), autoplay audio (1.4.2), generic/duplicated link text (2.4.4), target=_blank without warning (3.2.5), positive tabindex (2.4.3), aria-hidden on focusable elements, tables without th, duplicate ids, duplicate accesskeys. Each finding includes concrete remediation. Filter, not verdict: automation covers ~1/3 of WCAG; query a11y_criterion for what a criterion means. — Prefer a11y_audit_dom when JS renders the content or contrast/2.5.8/focus matter; use pages for light multi-page sampling. Static CANNOT measure class/var() CSS contrast (1.4.3): the report's not_measured says so — a 100 is never 'contrast is fine'. Returns JSON: {mode, url|file, score 0-100, findings [{criterion, severity, signal, issue, remediation}], summary {high, medium, low}, limits, score_note}.

Input Schema

NameRequiredDescriptionDefault
urlNoURL to fetch and audit
htmlNoraw HTML to audit directly (overrides url)
langNooutput language (en default)
pagesNolight same-domain crawl: audit up to N pages, aggregated by score and recurring signals (default 1, max 20)
timeoutNofetch timeout seconds (30 default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.5.0
    • addedInput schema / properties / pages / maximum
      Added value: +20
    • addedInput schema / properties / pages / minimum
      Added value: +1
  2. Changed1 schema field changedv3.12.0
    • changedInput schema / properties / lang / description
      Previous value: -"output language (es default)"New value: +"output language (en default)"
  3. Changed6 schema fields changedv3.3.0
    • addedInput schema / properties / html
      Added value: +{
+  "description": "raw HTML to audit directly (overrides url)",
+  "type": "string"
+}
    • addedInput schema / properties / lang / description
      Added value: +"output language (es default)"
    • addedInput schema / properties / pages
      Added value: +{
+  "description": "light same-domain crawl: audit up to N pages, aggregated by score and recurring signals (default 1, max 20)",
+  "type": "integer"
+}
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "fetch timeout seconds (30 default)",
+  "type": "number"
+}
    • addedInput schema / properties / url / description
      Added value: +"URL to fetch and audit"
    • removedInput schema / required
      Removed value: -[
-  "url"
-]
  4. First observedv2.3.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered by structured data. The description still adds genuinely useful behavioral context beyond that: static analysis cannot measure class/var() CSS contrast, the report's not_measured field reflects this, and a score of 100 must not be read as "contrast is fine." That is meaningful disclosure, though it stops short of rate limits or fetch failure behavior.

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 purpose, the sibling routing, and the caveat all appear before the long criterion enumeration, so the actionable content is front-loaded. The criterion list is dense but each entry pairs a signal with its WCAG success criterion, which is the detail an agent needs to match findings to a request.

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, the description carries the burden of describing the return value and does so in detail ({mode, url|file, score, findings[{criterion, severity, signal, issue, remediation}], summary, limits, score_note}), plus explains the limits field's meaning. Minor gap: timeout and lang behavior are left entirely to the schema.

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 every parameter is already documented, including that html overrides url and that pages is a light same-domain crawl. The description restates "URL or an HTML string" and clarifies pages is a sampling mode, but adds no syntax or format detail beyond the schema — baseline 3 applies.

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 resource ("Express WCAG 2.2 audit of a URL or an HTML string") plus concrete scope (20+ automated signals, weighted 0-100 score) and enumerates the checks it performs. It is immediately distinguishable from a11y_audit_dom and the multi-page siblings it names.

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?

Explicitly routes between alternatives: "Prefer a11y_audit_dom when JS renders the content or contrast/2.5.8/focus matter; use pages for light multi-page sampling," and points to a11y_criterion for criterion definitions. It also sets expectations on when this tool is insufficient ("automation covers ~1/3 of WCAG").

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