a11y-toolkit

by kinti

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.3.0
Disambiguation4/5
Although several tools audit pages (a11y_audit_url vs a11y_snapshot) or compare snapshots (a11y_diff vs a11y_diff_urls), the outputs target different concerns: WCAG signal checks versus DOM structure and tab order. Pair/image contrast checks have clear distinct purposes, though the two aria-live diagnostic tools could be confused if descriptions were less explicit.
Naming Consistency5/5
Every tool follows a consistent a11y_ prefix and verb_noun snake_case pattern (e.g., a11y_suggest, a11y_snapshot, a11y_contrast_pair). The lone aria-live helper is a11y_aria_live_snippet, which still matches the prefix and naming convention.
Tool Count4/5
Nine tools form a coherent toolkit for accessibility auditing: generating declarations, auditing URLs, snapshots, comparisons, contrast checks, and an ARIA-live injection helper. The count is well within the 3-15 expected range, though one or two more accessibility checks (e.g. keyboard support) could still be justified.
Completeness4/5
The core accessibility surface is well covered: automated WCAG-style checks, snapshot comparisons, color-to-contrast checks, and text-contrast checks. Missing are dedicated tools for things like heading structure, page titles, or semantics, but the snapshot tool captures much of this structural data, so agents can work around it.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are entirely absent, so the description bears the full burden of behavioral disclosure. It states the tool 'generates an HTML declaration' and that the HTML is accessible, but it doesn't disclose side effects such as whether it writes to a file (output_path), what the return value looks like, any permissions or prerequisites, or what happens when required fields are missing. The description only scratches the surface of behavior.
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 description is compact—two sentences—with the main purpose front-loaded and no filler. It efficiently conveys the legal compliance aspect and the output format. It loses a point because it omits usage guidance and parameter details that could be briefly integrated, but as a concise statement it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 13 parameters and no output schema, but the description provides almost no context about how those parameters influence the generated declaration, what the required inputs are for, or what the output looks like beyond being HTML. With no annotations and no output schema, the description is grossly incomplete for an agent to correctly invoke this tool, especially given its complexity. It leaves the agent to guess at critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 15%, so the description must compensate for the undocumented parameters, but it barely does. It mentions 'marco="eaa"' inline, which clarifies that parameter, but it does not explain the meaning of entidad, url, estado, metodo, feedback, reclamacion, etc. The phrase 'Campos legales incluidos' suggests some legal fields are used but does not map them to the schema. The description adds almost no parameter semantics beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an HTML accessibility declaration under two legal frameworks (RD 1112/2018 and EAA), using a specific verb ('Genera') and resource ('Declaración de Accesibilidad'). It distinguishes itself from sibling tools like a11y_audit_url or a11y_snapshot, which are about auditing or capturing, not generating declarations. However, it doesn't explicitly name any sibling alternatives, but the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling tools. The description mentions the two legal frameworks (marco) which could hint at a usage condition (choose the appropriate framework), but it doesn't state scenarios like 'use this when you need a formal accessibility statement' or contrast with other tools. An agent would have to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of explaining behavior. It only states the action and the Playwright requirement; it does not disclose whether the operation is read-only, what the output looks like, or any side effects. The 'Requiere Playwright' is a prerequisite but not behavioral transparency. Thus insufficient.
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 description is a single, concise sentence that states the core function and gives a concrete example. No waste, front-loaded with the primary action. It also includes the Playwright requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the tool returns, failure conditions, or how the diff result is presented. Since there's no output schema, the agent has to guess what the call produces. The example gives some context, but the overall operational context (side effects, output format, prerequisites beyond Playwright) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only has url_a and url_b with no descriptions Particular. The description merely says 'dos URLs' without adding meaning beyond that. It doesn't clarify order, format, or expected input conventions. With 0% schema coverage, the description should compensate but doesn't.
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?
Description clearly states the tool snapshots two URLs and diffs them in a single call, with a concrete example (staging vs production). This is a specific verb+resource pair that distinguishes it from single-URL snapshot tools like a11y_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an example use case (staging vs producción) which implies when to use, but no explicit guidance on when not to use or comparison with sibling tools like a11y_snapshot or a11y_diff. It's implied rather than explicit, so it's usable but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sin anotaciones, la descripción carga con todo el peso y aporta datos genuinos: desvela que la búsqueda es de mínima distancia a fg y fija el valor por defecto del ratio en 4.5 (estándar AA para texto normal). Esto es información que ni el nombre ni el esquema ofrecen. Para una función pura el listón es más bajo (no hay efectos laterales que advertir), pero hay vacíos que pesan: no se dice quién gana si ya se cumple el ratio, el espacio de color de la distancia, el formato de retorno del color sugerido, ni los límites del parámetro 'target'. Con cobertura de esquema al 0% y sin anotaciones, un contrato de retorno habría redondeado el comportamiento.
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?
Una sola frase densa en información con cero desperdicio. Ordena perfectamente los elementos: el criterio de proximidad ('más cercano a fg'), la condición ('que alcance el ratio objetivo'), la referencia ('contra bg') y la regla de defecto (4.5). Cada palabra aporta valor y el defecto aparece al final, donde debe estar.
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?
Aunque no hay esquema de salida, la descripción sí que cubre el contrato de retorno de forma implícita: 'color más cercano a fg' es la especificación del valor devuelto, y además fija el defecto. Para una función pura con tres parámetros planos y sin enums ni objetos anidados, el barrido de escenarios sobre los que comunicar es bajo y la cobertura es suficiente. Los únicos vacíos reales que evitan el 5 son la serialización de la salida y el comportamiento en casos límite (por ejemplo, si fg ya cumple el ratio o si target no es alcanzable).
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?
Con 0% de cobertura en el esquema, la descripción es la única fuente semántica y compensa en parte: aclara que fg es el color de referencia a aproximar, bg es el fondo contra el que se mide el contraste y target es el ratio con defecto 4.5. Aun así, no hay ningún detalle de formato: ¿cómo se serializan los colores (hex, rgb, nombres CSS)? ¿Qué rango admite target? Al ser la descripción la única vía para entender los parámetros, la ausencia de formato deja lagunas que el agente deberá asumir.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
La descripción es técnicamente precisa: expresa el verbo implícito ('sugerir'), el recurso (un color) y la restricción exacta que define la operación (el color más cercano a fg que alcance el ratio contra bg, con defecto 4.5). Comunica claramente una función de optimización de contraste, no una simple verificación. Sin embargo, le falta un verbo explícito y no diferencia a propósito de hermanos como a11y_contrast_pair o a11y_contrast_image, que es exactamente donde necesita orientar al agente.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
El contexto de uso se infiere de la claridad del propósito: un agente que necesite un color que cumpla el contraste contra un fondo sabrá que esta es la herramienta. La función se describe de forma tan específica que el caso de uso está implícito. No obstante, no hay ninguna orientación sobre cuándo NO usarla o qué alternativas existirían. Dado un conjunto de 8 herramientas hermanas en el dominio de accesibilidad con solapamiento real (contrast_pair, contrast_image), el silencio sobre alternativas es un vacío que evita el 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the method ('muestrea píxel a píxel' — samples pixel by pixel) and the output metrics (ratio worst/median/p95 and % area passing AA). Since no annotations are provided, the description carries the full burden, and it does convey meaningful behavioral traits beyond a mere 'checks contrast.' It does not mention performance or side effects, but for a read-only analysis tool this is acceptable, and the heavy-sampling note hints at computational cost.
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 description is a single, dense sentence that front-loads the purpose, then lists outputs, and ends with the region hint. Every clause adds meaning, with no filler or repetition. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 5 parameters, no output schema, and no annotations, the description is incomplete. It omits the meaning of 'sample' and 'lang', does not state the format for 'text_color' (e.g., hex/rgba) or 'path', and does not describe the return structure beyond the metrics. While it gives a region syntax example, it lacks enough detail for a fully autonomous agent to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It covers only 'region' (with syntax and recommendation), while 'sample', 'lang', and the exact format of 'path' and 'text_color' are left undefined. The description adds some value for region but fails to clarify the others, leaving an agent to guess about the number of samples or language options.
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?
The description clearly states the tool's purpose: 'Contraste de TEXTO SOBRE IMAGEN' (text-over-image contrast). It specifies the action (sampling pixel-by-pixel), the resource (image background), and the outputs (worst/median/p95 ratio, % area passing AA). This distinguishes it from siblings like a11y_contrast_pair (which likely works on solid colors) and a11y_audit_url (which audits a URL).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is implied by the phrase 'TEXTO SOBRE IMAGEN' — it should be used when checking contrast of text over an image background, not solid colors. However, it does not explicitly mention alternatives or when-not-to-use conditions. The only explicit guidance is the recommendation for the 'region' parameter, which is parameter-level advice rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well by disclosing the exact outputs: ratio, verdicts per criterion, and a conditional closest-color suggestion when AA fails. It omits details like accepted color formats and exact response structure, but the core behavior is transparent.
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?
Two concise sentences with no filler. The main action and criteria are front-loaded, and the conditional suggestion behavior is added as a brief second sentence. Every phrase contributes to understanding how the tool behaves.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a useful high-level summary of return values and criteria. It is not fully complete because it does not describe the response format in detail, accepted color input syntax, or language behavior beyond what the schema already states for lang.
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 low (33%) because fg and bg have no descriptions, so the description must compensate. It adds the meaning that fg and bg form a color pair for contrast evaluation, which is valuable, but it does not specify accepted color formats or clarify the exact roles beyond the parameter names.
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?
The description states a specific operation: WCAG 2.2 contrast checking of a color pair, with exact ratio and per-criterion verdicts (1.4.3 AA, 1.4.6 AAA, 1.4.11 non-text). This clearly differentiates it from siblings like a11y_audit_url and a11y_contrast_image, even though the suggestion behavior may overlap with a11y_suggest_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The functionality makes the primary use case evident: checking contrast for a foreground/background color pair. However, there is no explicit guidance about when to choose this over a11y_suggest_color or a11y_contrast_image, and no conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is transparent about behavior: it fetches the page, checks specific automatic signals, returns findings by severity, and explicitly disclaims being a full verdict. It also discloses its limited coverage (~1/3 of WCAG), which is crucial for setting expectations.
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 description is structured with a list of checks and a clear caveat, making it easy to scan. It is slightly long due to the enumeration of WCAG references, but these are informative and not redundant. The length is acceptable given the need to convey scope.
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?
The description covers the tool's purpose, the checks it performs, and the nature of its output ('findings by severity'), plus a limitation note. However, it lacks details about the return format or structure, and parameter descriptions are missing. For the tool's specialized use, it is fairly complete but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the URL as the target but does not elaborate on the parameter itself (e.g., expected format). The optional 'lang' parameter is not mentioned at all, despite being defined in the schema with an enum. The description adds no semantic value beyond what the schema already provides.
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?
The description clearly states the tool performs an accessibility audit of a URL, listing specific WCAG criteria it checks. It distinguishes itself from siblings by focusing on automated checks and explicitly mentioning 'Express' in the name, making the verb and scope unambiguous.
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?
The description provides usage guidance by noting 'Filter, not verdict' and that automation covers only ~1/3 of WCAG, implying this is a quick pre-scan rather than a comprehensive audit. However, it does not explicitly contrast it with sibling tools or state when to prefer it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the comparison logic and output categories, and clarifies input formats. However, it does not state whether the operation is read-only, what the exact return structure is, or how errors like invalid JSON or missing files are handled.
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?
Two sentences, no filler. The main purpose and output categories are front-loaded, followed by input format constraints. Every sentence earns its place.
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 two-parameter tool with no output schema, the description covers the core purpose, input formats, and high-level output categories. It is slightly incomplete regarding the exact return format and prerequisites for obtaining snapshots, but overall it gives an agent enough to invoke the tool 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 coverage is 100%, so the baseline is 3. The description adds meaningful detail beyond the schema by specifying that inline JSON should start with '{' and that file paths are accepted. It also reinforces the before/after ordering implied by the parameter names.
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?
The description states a specific verb ('Compara') and resource ('dos snapshots de accesibilidad'), and details exactly what is compared: added/removed/renamed interactives and focus order changes. This clearly distinguishes it from siblings like a11y_diff_urls, which operate on URLs rather than snapshots.
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?
The description gives a clear usage context: comparing accessibility snapshots before/after a deploy. It also specifies accepted input forms (inline JSON or file paths). It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'Devuelve el código JavaScript', not that it executes anything, and describes what the injected code does: 'registra cada anuncio de regiones dinámicas con hora, cortesía, rol y texto'. This gives the agent a solid understanding of the output and its behavior without contradicting any annotations.
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 description is a single well-structured sentence that front-loads the main action ('Devuelve el código JavaScript') and then efficiently packs the essential details: injection contexts, the monitored topic, and the recorded fields. There is no filler or redundant content; every part earns its place.
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?
For a tool with one optional parameter, no output schema, and no annotations, the description is fully complete. It explains what is returned, how it is meant to be used, and what the returned code does. An agent has enough information to select and invoke this tool correctly in its context.
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%, and the single parameter 'lang' is fully described in the schema with an enum and a clear explanation. The tool description itself adds no additional parameter semantics, so the baseline 3 applies. There is no gap for the description to compensate for.
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?
The description uses a specific verb and resource: 'Devuelve el código JavaScript del monitor de anuncios aria-live', clearly stating that the tool returns a JavaScript snippet rather than performing an audit or analysis. It also explains the snippet's purpose, distinguishing it from siblings like audit, snapshot, and contrast tools. There is no ambiguity about what the tool produces.
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?
The description explicitly states the intended use: 'para inyectar en una página (bookmarklet o page.evaluate)', giving clear context for when an agent should invoke it. It does not explicitly name alternatives or exclusions, but among the siblings none obviously overlaps with generating an aria-live monitoring snippet. This is clear context without a need for deeper exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes the full burden. It clearly communicates what the tool does and even discloses an operational prerequisite: 'Requiere Playwright instalado localmente.' It lacks details about where the snapshot is stored or whether the operation is idempotent, but it is candid about core 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?
Three sentences, each earning its place: the snapshot content, the intended deployment workflow with a11y_diff, and the Playwright requirement. No filler or repetition.
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?
Given a single required parameter and no output schema, the description is nearly complete: it names the exact data captured and the companion tool for comparison. It could more clearly state the return format or persistence behavior, but the remaining gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must explain the URL parameter. It only says 'de una URL,' which adds almost nothing beyond the schema property name 'url'. It does not mention accepted URL formats, whether HTTPS is required, or any page-load expectations.
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?
The description clearly states 'Captura un snapshot de accesibilidad de una URL' and enumerates the captured content: interactive elements (tag, role, accessible name, href) and real tab order. This specific language differentiates it from sibling tools like a11y_audit_url and a11y_diff.
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?
The description gives an explicit workflow: save this snapshot before a deploy, then compare later with a11y_diff. This immediately tells an agent when to choose this tool versus an audit or a comparison tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![a11y-toolkit MCP server](https://glama.ai/mcp/servers/kinti/a11y-toolkit/badges/card.svg)](https://glama.ai/mcp/servers/kinti/a11y-toolkit)

Score Badge

Copy to your README.md:

[![a11y-toolkit MCP server](https://glama.ai/mcp/servers/kinti/a11y-toolkit/badges/score.svg)](https://glama.ai/mcp/servers/kinti/a11y-toolkit)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kinti/a11y-toolkit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server