accessibility-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct aspect of accessibility testing (color contrast, form labels, headings, images, etc.), but check_url_accessibility overlaps with several individual checks (images, headings, forms). Despite this, descriptions clearly distinguish between comprehensive and focused checks, so confusion is limited.
Naming Consistency3/5
Most tools use the verb_noun pattern with 'check_', but there are exceptions: generate_a11y_report, list_wcag_rules, and validate_aria. While names are clear, the mix of verbs and a few underscores with abbreviations (a11y) breaks full consistency.
Tool Count5/5
With 8 tools, the server covers core accessibility checks, a combined scan, rule reference, and ARIA validation. The count is well-scoped for an automated accessibility testing tool, neither too sparse nor too bloated.
Completeness4/5
The set includes essential WCAG checks like color contrast, headings, images, forms, and ARIA, plus a report generator and rule list. However, it lacks checks for keyboard navigation, focus order, or more advanced dynamic content, which are minor gaps for an automated audit.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic check. It does not state limitations (e.g., static pages, invisible elements) or dependencies (e.g., JavaScript execution), leaving the agent with minimal understanding of the tool's 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 short and front-loaded with the essential purpose. The Args/Returns structure is clear. However, the Returns section is vague ('all form elements with label status'), missing detail that could have been included concisely. No extraneous text.
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 the tool's single parameter and existing output schema, the description provides only the high-level purpose and return type. It lacks details about detection methodology, what constitutes an accessible label, handling of dynamic content, or edge cases. This leaves the agent underinformed for effective use.
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 parameter 'url' lacks description in the input schema (0% coverage). The description adds only 'URL to test' in the Args section, which is tautological and adds no meaning beyond the parameter name and type. The tool fails to compensate for the low schema coverage.
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 explicitly states the tool checks all form elements for accessible labels per WCAG 3.3.2, with a specific verb (checks) and resource (form elements). It clearly distinguishes from sibling tools that focus on other aspects like color contrast or heading structure.
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?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit when-to-use, when-not-to-use, or mention of specific conditions like dynamic content or required JavaScript.
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 provided, so the description carries the full burden. It only states that the tool 'checks' images for alt text without disclosing any behavioral traits such as network requests, rate limits, or what constitutes a check (e.g., does it parse the page asynchronously?). This is insufficient for a tool with no built-in safety cues.
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 very short and direct, with separate lines for Args and Returns. No unnecessary words. However, the absence of any explanatory detail beyond the basics slightly reduces the score from a perfect 5.
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 that an output schema exists, the tool does not need to detail return values. However, the description lacks information about the depth of the check, edge cases (e.g., images without alt attribute vs empty alt), or whether it follows the page's redirects. It is minimally complete for a simple tool but leaves 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?
There is only one parameter (url), and the description repeats its name and a generic phrase ('Zu pruefende URL') which adds no meaning beyond the input schema. With 0% schema description coverage, the description fails to provide any additional context about the expected format or constraints of the URL.
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 checks all images on a webpage for alt text, referencing WCAG 1.1.1. It is specific about the verb (prueft) and resource (Bilder einer Webseite) and distinguishes from sibling tools that focus on other accessibility checks.
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 description does not explicitly state when to use this tool versus alternatives like check_color_contrast or check_heading_structure. While the name and context hint at its specific purpose, there is no guidance on prerequisites or situations where it should be avoided.
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 provided, so the description must fully disclose behavioral traits. It only states that the tool creates a report, but does not mention any side effects, required permissions, rate limits, or data handling. As a tool that fetches a URL and runs multiple checks, this is a significant gap.
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 concise and front-loaded with the main purpose. It includes a bullet list of combined checks. However, the language mix (German with some English) might be slightly confusing, and the args/returns section is redundant with structured fields.
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 that an output schema exists, the description does not need to explain return values in detail. It mentions the report includes a total score and recommendations, adding some value. However, without annotations, more behavioral context (e.g., that it fetches a live URL, might be slow) would improve completeness.
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 has zero description coverage for the 'url' parameter. The description adds a brief 'URL to be tested' in the args section, but does not provide format examples, constraints, or valid URL patterns. More detail is needed to compensate for the schema gap.
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 it creates a complete accessibility report for a URL, and explicitly mentions that it combines all checks (URL accessibility, images, forms, headings), distinguishing it from the sibling tools which focus on individual checks.
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 implies this tool is for comprehensive accessibility auditing, while sibling tools are for specific checks. However, it does not explicitly state when to prefer this tool over others, nor does it mention when not to use it.
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 provided, so the description must convey behavioral traits. It only lists return values but omits error handling, prerequisites (e.g., valid hex format), or side effects. This is insufficient for a tool with zero annotation coverage.
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 concise and well-structured with Args and Returns sections. Every sentence is informative and front-loaded. No redundancy.
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 checking tool with an output schema, the description covers the key inputs and outputs. However, it lacks guidance on error cases or edge conditions (e.g., invalid colors). Completeness is high but not perfect.
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?
The schema has 0% coverage (no parameter descriptions), so the description compensates by explaining each parameter with examples and defaults (e.g., '#000000' for foreground). This adds significant meaning beyond the raw 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?
The description clearly states the tool checks color contrast per WCAG 2.1, specifying the verb and resource. It distinguishes from sibling tools like check_heading_structure or check_form_labels.
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?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by the tool's purpose, but alternatives are not mentioned. Sibling tools are listed but not contrasted.
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?
No annotations provided, so description carries the burden. It mentions three specific checks and a returned tree+problems, but lacks details on how the page is fetched, performance, error handling, or limitations.
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 paragraphs: first states purpose and checks, second lists Args and Returns. Every sentence adds value with no redundancy.
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?
Covers main purpose and key checks. With an output schema present, it doesn't need to detail return structure. Could mention prerequisites or error behavior, but overall adequate for a focused tool.
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 has 0% coverage for the 'url' parameter. The description adds 'Zu pruefende URL' (URL to test), which provides basic meaning but no format or constraints, doing the minimum to compensate.
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 analyzes heading hierarchy per WCAG 1.3.1, listing specific checks (H1 uniqueness, no jumps, empty headings). This differentiates it from sibling tools like check_color_contrast or check_form_labels.
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?
No explicit when/when-not or alternative recommendations. While the description implies use for heading structure validation, it does not guide the agent on when to prefer this tool over siblings.
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 provided, and the description does not disclose behavioral traits such as read-only nature, external dependencies, or performance considerations. The tool is likely read-only, but this is not explicitly stated.
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 very concise, consisting of two sentences plus structured Args/Returns. Every part is necessary and there is no extraneous information.
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 the presence of an output schema (context signal), the description does not need to detail return values. It covers the essential purpose and parameter. However, it could mention that the rules follow the WCAG 2.1 standard and lack prerequisites or error handling information.
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?
The input schema has 0% coverage (no enum or description in schema). The description compensates by explaining the 'level' parameter with acceptable values 'A', 'AA', 'AAA' and default 'AA', adding significant meaning beyond the schema's type and default.
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 lists WCAG 2.1 rules for a given conformance level, using specific verbs ('Listet') and resource ('WCAG 2.1 Regeln'). It distinguishes itself from sibling tools (e.g., check_color_contrast) which perform specific checks, not listing rules.
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 description implies usage when needing to fetch WCAG rules by level, but does not provide explicit guidance on when not to use or mention alternative tools. Sibling tools are not referenced, leaving some ambiguity.
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?
No annotations are provided, so the description carries full burden. It declares what is checked but does not disclose behavioral traits such as whether it modifies input or requires authentication. The read-only nature is implied but not explicit, and no side effects are noted.
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 concise, beginning with a clear one-sentence purpose, followed by bullet points of checks, then args and returns sections. Every sentence adds value, with no redundancy or filler.
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 only one parameter and an existing output schema, the description covers the key aspects: purpose, input, and output format. It does not address limitations or edge cases, but for a simple validation tool, it is sufficient.
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?
The schema has 0% description coverage, yet the description adds meaningful context: it clarifies that html_snippet expects an HTML snippet (not a full document) and provides a German explanation. This compensation justifies a score above baseline of 3.
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 explicitly states it validates ARIA attributes in HTML snippets, specifying three checks (aria-* values, role values, required ARIA for roles). This clearly distinguishes it from sibling tools like check_color_contrast or check_heading_structure.
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 description implies usage for ARIA validation but does not explicitly state when to use it versus alternatives like check_form_labels. No exclusions or prerequisites are provided, leaving the agent without clear guidance on when not to use it.
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?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool as performing checks, which implies read-only behavior, but it does not explicitly confirm non-destructiveness or mention any potential side effects, rate limits, or prerequisites.
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 concise and well-structured, with a front-loaded purpose, a bullet list of checks, and clear Args/Returns sections. Every sentence adds value without redundancy.
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 the existence of an output schema for return values, the description adequately covers input and behavior. It could be improved by noting it covers multiple rules comprehensively, but it is largely complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the 'url' parameter. The description compensates fully by explaining 'URL to test' and providing an example format ('https://example.com'), adding clear semantic value beyond 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?
The description clearly states it performs automatic WCAG 2.1 AA accessibility checks for a URL, listing specific checks like image alt texts, headings, etc. It distinguishes from sibling tools that are more specific (e.g., check_color_contrast) by being comprehensive.
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 description implies this tool is for a full accessibility check but does not explicitly state when to use it vs. sibling tools. No guidance on exclusions or alternatives, leaving the agent to infer from context.
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:

[![accessibility-mcp-server MCP server](https://glama.ai/mcp/servers/AiAgentKarl/accessibility-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/AiAgentKarl/accessibility-mcp-server)

Score Badge

Copy to your README.md:

[![accessibility-mcp-server MCP server](https://glama.ai/mcp/servers/AiAgentKarl/accessibility-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/AiAgentKarl/accessibility-mcp-server)

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/AiAgentKarl/accessibility-mcp-server'

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