Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Honest SVG badge

a11y_badge
Read-onlyIdempotent

Generates an accessible SVG accessibility badge with score, date, and screening scope, color-coded by score and deliberately avoiding a conformance claim. Embed it in audited sites or statements.

Instructions

Returns an HONEST accessibility badge as accessible SVG: score, date and scope (automated screening ≈ 1/3 of WCAG), color-coded by score. Deliberately does NOT say "conformant" — the honest seal. Embed it in audited sites or statements. — Scope: the honest SVG seal for audited sites; the machine-readable bundle is a11y_evidence. Returns the honest SVG badge as text content (the agent writes the file).

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": {
      "score": "<score>"
    },
    "name": "a11y_badge"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoISO date (today by default)
langNoBadge language (default en)
scoreYes0-100 (from an audit result)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.14.0
    • addedInput schema / properties / date
      Added value: +{
+  "description": "ISO date (today by default)",
+  "type": "string"
+}
    • removedInput schema / properties / fecha
      Removed value: -{
-  "description": "ISO date (today by default)",
-  "type": "string"
-}
  2. Changed1 schema field changedv4.0.0
    • addedInput schema / properties / lang / description
      Added value: +"Badge language (default en)"
  3. Addedv3.3.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: the tool returns SVG as text content and the agent is responsible for writing the file, and the badge declares scope limitations rather than conformance. Repeating 'HONEST'/'honest seal' several times adds emphasis but no new information.

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

Conciseness3/5

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

Front-loaded with the core capability, but the text is cluttered: 'honest' appears four times, and 'Returns the honest SVG badge as text content' restates the opening sentence. The '— Scope:' fragment reads like appended boilerplate rather than a clean structure.

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 simple one-required-param generator with no output schema, the description covers what is produced (SVG text, agent writes the file), what it contains, and what it does not claim. Only the lang parameter's effect on the output is unaddressed, which is a minor gap.

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% (score 0-100, date ISO default today, lang enum default en), so the schema already carries parameter meaning. The description restates score and date as badge content and says nothing about the lang parameter, so it adds little 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 the specific verb ('Returns') and resource ('accessibility badge as accessible SVG') plus its content (score, date, scope) and even the design stance (deliberately omits 'conformant'). It explicitly separates itself from the sibling a11y_evidence, so an agent can pick it without opening either schema.

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 a concrete use context ('Embed it in audited sites or statements') and explicitly routes the agent to a11y_evidence for the machine-readable bundle. It lacks an explicit when-not case (e.g., don't use before an audit is performed), but the alternative is named and the condition is clear.

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