Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: W3C Nu validation

a11y_html_validate
Read-onlyIdempotent

Validate a URL or raw HTML against the W3C Nu Html Checker to find doctype, encoding, structural, and alt/lang/role issues, mapped to WCAG criteria where relevant.

Instructions

The W3C's own parser as a toolkit mode: checks a URL or raw HTML against the Nu Html Checker (validator.w3.org/nu) — doctype, encoding, structural validity, plus alt/lang/role issues from the authoritative source, mapped to WCAG criteria where they overlap. PRIVACY: html mode POSTs the document to the W3C service (url mode shares only the URL, like a11y_audit_url); self-hosted vnu instances supported via base_url for sensitive content. Returns JSON: Nu validator messages mapped to WCAG criteria where they overlap.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "a11y_html_validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoPage URL to validate (shares the URL with the W3C service)
htmlNoRaw HTML to validate — POSTs the content to validator.w3.org/nu; use url or a self-hosted instance for sensitive pages
langNoOutput language (en default)
base_urlNoBase URL of a self-hosted vnu instance (docker ghcr.io/validator/validator) instead of the public W3C service

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely non-derivable behavior: html mode POSTs the document to the third-party W3C service, url mode shares only the URL, and base_url enables a self-hosted vnu. It also states the return shape, disclosing network/privacy implications the annotations cannot express.

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?

Front-loaded with the core purpose, then privacy, then return shape — a logical order with little waste. Minor redundancy: 'mapped to WCAG criteria where they overlap' appears twice (opening and closing sentence).

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?

With no output schema, the description correctly carries the return-value burden ('Returns JSON: Nu validator messages mapped to WCAG criteria'), covers all four parameters' semantics, and discloses the third-party network behavior. An agent has everything needed to invoke it correctly.

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 description coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema by tying url/html to their privacy consequences (URL-only vs full document POST) and explaining base_url's self-hosted purpose. It does not add format or syntax detail for lang beyond the enum.

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+resource (checks a URL or raw HTML) against a named authoritative engine (Nu Html Checker) and enumerates the scope: doctype, encoding, structural validity, plus alt/lang/role issues. An agent can tell this apart from generic audits like a11y_audit_url because it names the specific checker and its WCAG mapping.

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 clear selection context among its own modes (url for URL-only sharing, html POSTs content, base_url for sensitive content via self-hosted vnu) and contrasts privacy behavior with a11y_audit_url. However, it never explicitly states when to prefer this tool over sibling audits like a11y_audit_dom or a11y_audit_url for a given validation goal.

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