MagentaA11y MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_web_componentsC | List all available web accessibility components from MagentaA11y. Optionally filter by category (e.g., controls, forms, components). |
| get_web_componentB | Get detailed accessibility criteria for a specific web component. Returns acceptance criteria, WCAG mappings, code examples, and implementation guidelines. |
| search_web_criteriaB | Search web accessibility criteria using keywords. Find criteria related to WCAG guidelines, implementation patterns, or specific accessibility requirements. |
| list_native_componentsA | List all available native (iOS/Android) accessibility components from MagentaA11y. Optionally filter by category. |
| get_native_componentA | Get detailed accessibility criteria for a specific native component. Returns iOS and Android implementation details, platform-specific properties, and code examples. |
| search_native_criteriaA | Search native accessibility criteria using keywords. Find platform-specific implementation details for iOS (VoiceOver) and Android (TalkBack). |
| get_component_gherkinB | Get Gherkin-style acceptance criteria for a component. These are detailed Given/When/Then scenarios for testing accessibility. |
| get_component_condensedB | Get condensed acceptance criteria for a component. These are shorter, more focused testing instructions. |
| get_component_developer_notesB | Get developer implementation notes for a component. Includes code examples, WCAG mappings, and technical guidance. |
| get_component_native_notesB | Get platform-specific developer notes for native components (iOS or Android implementation details). |
| list_component_formatsB | List all available content formats for a specific component (e.g., gherkin, condensed, developer notes). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Every tool has a clearly distinct purpose with no ambiguity. The tools are well-organized by target platform (web vs. native) and action type (get details, list components, search criteria), making it easy for an agent to select the right tool for the task. For example, get_web_component retrieves detailed criteria for a specific web component, while search_web_criteria performs keyword searches across web criteria.
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. The naming convention clearly indicates the action (get, list, search) and the target resource (component, criteria), with platform prefixes (web_ or native_) where applicable. This predictability makes the tool set easy to navigate and understand.
With 11 tools, the count is well-scoped for the server's purpose of providing accessibility criteria and components. Each tool earns its place by covering distinct aspects like retrieval, listing, and searching across web and native platforms, without redundancy. This number supports comprehensive functionality while remaining manageable.
The tool surface offers complete coverage for the accessibility domain, with no obvious gaps. It includes CRUD-like operations (get details, list components, search criteria) for both web and native platforms, along with specialized formats (condensed, developer notes, Gherkin). This ensures agents can handle various accessibility tasks without dead ends.