Which integrations are available for this server?

Integrates with Ollama to provide natural-language semantic search and RAG (Retrieval-Augmented Generation) capabilities, enabling users to query WAI-ARIA Authoring Practices Guide (APG) patterns and examples using embeddings.

How do I use accessibility-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@accessibility-mcp show me the keyboard guidance for an accessible accordion" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

accessibility-mcp

by nicolasgalvez

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

accessibility-mcp

A Model Context Protocol server (built with FastMCP) that exposes WAI-ARIA Authoring Practices Guide (APG) patterns: narrative requirements, keyboard/ARIA guidance as Markdown, official example source (HTML, CSS, JS) from w3c/aria-practices, and RAG via Ollama + LangChain.js (apg_semantic_search; the chunk index is prebuilt in data/rag/chunks.json for releases).

This is APG (widget patterns), not the full WCAG spec. For WCAG success criteria text, use W3C’s WCAG materials separately; APG is the right source for patterns like Carousel and the patterns index.

Codebase documentation: docs/README.md (architecture, data pipeline, MCP tools).

Tests: npm test runs unit tests plus an MCP stdio integration check (src/mcp-stdio.integration.test.ts): builds dist/cli.js, spawns the server with @modelcontextprotocol/sdk, completes the initialize handshake, and callTool(apg_meta) — this matches what Claude Code uses at the protocol level. Manual: npm run mcp:try (see Try tools without Claude).

Claude Code CLI (optional): the real claude -p binary can drive the same server with --mcp-config + --strict-mcp-config (see headless / -p). Uses your normal Claude Code login (same as the REPL)—no ANTHROPIC_API_KEY required unless you use --bare (API-key-only / CI). To smoke-test end-to-end:

CLAUDE_CODE_MCP_SMOKE=1 npm run test:claude-mcp

Exits 0 with a skip message if CLAUDE_CODE_MCP_SMOKE is unset (default in CI).

Data / RAG quality: npm run validate:data (structure checks; no Ollama). npm run eval:rag runs a labeled benchmark and writes reports/rag-eval.html (bar chart of top-1 scores + MRR / Hit@k). There is no training loss curve—embeddings are frozen; see docs/evaluation.md.

Dataset

npm run ingest — shallow-clones w3c/aria-practices into .cache/, writes:
- data/manifest.json — compact index (ids, titles, example slugs, bundle paths)
- data/patterns/<id>.md — pattern doc as Markdown (from *-pattern.html)
- data/bundles/<id>/<example>.json — referenced HTML/CSS/JS per demo (binary assets listed but omitted)
npm run rag:index — (after ingest + .env) calls Ollama embeddings and writes data/rag/chunks.json: chunked pattern docs plus one combined text blob per example (HTML/CSS/JS). Maintainers run this before releases; re-run after ingest or when you change OLLAMA_EMBEDDING_MODEL.
Vendored data/ (including data/rag/chunks.json) is committed and published so end users are not required to ingest or index locally.

Related MCP server: aria-mcp

Usage

npm install
npm run ingest   # refresh from GitHub (re-run when you want newer APG)
npm run rag:index # rebuild RAG index (maintainers / custom models; shipped index in releases)
npm run build
npm start        # stdio MCP server

npx (after publish to npm)

npx -y accessibility-mcp

After the package is on npm, most clients can use command + args with npx / -y / accessibility-mcp instead of a local node path.

Publishing (npm tarball)

The package ships dist/, data/manifest.json, data/patterns/, data/bundles/, and data/rag/chunks.json (see files in package.json). That last file is the precomputed embedding index so installers do not need to run npm run rag:index themselves.

Runtime note: apg_semantic_search still uses Ollama to embed the user query at request time (the index only stores chunk vectors). Point OLLAMA_EMBEDDING_* at the same embedding model the index was built with (see embeddingModel inside chunks.json). Users without Ollama can set OLLAMA_SKIP_PULL=1 and use the non-RAG tools only.

Before npm publish:

npm run ingest — refresh APG text and bundles.
npm run rag:index — rebuild data/rag/chunks.json (needs Ollama once, on the maintainer machine).
npm test (optional but recommended).
npm publish — prepack runs npm run build.

Inspect the tarball: npm pack --dry-run.

MCP Inspector (dev)

The MCP Inspector is a dev dependency. After npm run build:

npm run mcp:inspect

Opens a local web UI to exercise tools and resources against node dist/cli.js (Ollama runs on first connect like npm start).

Try tools without Claude (CLI)

npm run mcp:try runs a tiny MCP SDK client that spawns dist/cli.js, completes the handshake, and calls a tool (same mechanism as the integration test).

npm run build
npm run mcp:try -- --list
npm run mcp:try
npm run mcp:try -- apg_list_patterns '{"query":"carousel"}'

See scripts/mcp-client-demo.ts. apg_semantic_search still needs a reachable Ollama embedding endpoint at call time.

Environment (`.env`)

At startup the server loads .env from the package root (same folder as package.json). Copy .env.example → .env and adjust.

Variable	Purpose
`OLLAMA_BASE_URL`	Default Ollama HTTP API root, e.g. `http://127.0.0.1:11434` (no trailing slash). Use your LAN IP if Ollama runs on another machine. Used for chat and embeddings when the overrides below are unset.
`OLLAMA_CHAT_BASE_URL`	Optional. Chat-only host (e.g. a GPU box). Defaults to `OLLAMA_BASE_URL`.
`OLLAMA_EMBEDDING_BASE_URL`	Optional. Embeddings-only host. Defaults to `OLLAMA_BASE_URL`. Set both overrides to split chat vs embed across two servers.
`OLLAMA_CHAT_MODEL`	Chat model id (default `llama3.1:8b`). Pick any Ollama library model you have pulled.
`OLLAMA_EMBEDDING_MODEL`	Embedding model for RAG (default `nomic-embed-text`). Re-run `npm run rag:index` after changing it so vectors match.
`OLLAMA_SKIP_PULL`	If `1` / `true` / `yes`, does not contact Ollama at startup (skips model checks and pulls).
`OLLAMA_VERBOSE`	If `1` / `true` / `yes`, log extra Ollama status to stderr (default: quiet).
`APG_MCP_DATA_DIR`	Optional. Directory that contains `manifest.json` (defaults to `data/` next to `dist/`).

The MCP stdio handshake runs first; Ollama model checks and pulls run after that (async). If Ollama is unreachable, APG list/read tools still work; RAG needs Ollama when invoked.

Without Ollama (no local LLM)

Listing patterns, reading specs, and fetching example sources use only the bundled data/ files—no model and no network at query time.

Install Node.js 20+.
Run the server from the published package, e.g. npx -y accessibility-mcp (after you publish), or node dist/cli.js from a git checkout after npm install + npm run build.
Optionally set OLLAMA_SKIP_PULL=1 so startup never contacts Ollama (otherwise unreachable Ollama only logs a warning by default).

Do not rely on apg_semantic_search without Ollama: it needs a running embedding endpoint at call time. Ignore that tool or expect errors if invoked.

Ollama + LangChain.js helpers (for RAG scripts or future MCP tools):

loadEnv() — load .env explicitly (also runs via getOllamaConfig() / resolveDataDir()).
getOllamaConfig() — parsed { baseUrl, chatBaseUrl, embeddingBaseUrl, chatModel, embeddingModel }.
ensureOllamaModels() — GET /api/tags + POST /api/pull for missing models (same as MCP startup).
createChatOllama() / createOllamaEmbeddings() — @langchain/ollama instances using those settings.

import { createChatOllama, createOllamaEmbeddings } from "accessibility-mcp";

The apg_semantic_search tool calls Ollama at query time (embed query → cosine similarity vs data/rag/chunks.json). npm run rag:index builds that index with createOllamaEmbeddings().

Sanity check (requires Ollama reachable at OLLAMA_CHAT_BASE_URL or OLLAMA_BASE_URL with OLLAMA_CHAT_MODEL pulled):

cp .env.example .env   # then edit if needed
npm run ollama:smoke

IDE and agent setup

MCP wiring differs by product: some use a top-level mcpServers object; VS Code uses servers inside mcp.json. Below, replace /absolute/path/to/accessibility-mcp with your clone (or use npx once published).

Use an absolute path to dist/cli.js in args (or npx -y accessibility-mcp). A relative path like dist/cli.js is resolved from the client’s workspace and usually fails outside this repo.

Shared snippets

Stdio via local build (mcpServers shape — Cursor, Claude Desktop, Claude Code, Gemini CLI):

{
  "mcpServers": {
    "apg-patterns": {
      "command": "node",
      "args": ["/absolute/path/to/accessibility-mcp/dist/cli.js"]
    }
  }
}

Stdio via npx (after npm publish):

{
  "mcpServers": {
    "apg-patterns": {
      "command": "npx",
      "args": ["-y", "accessibility-mcp"]
    }
  }
}

Custom data directory (any client that supports env on the server process):

{
  "mcpServers": {
    "apg-patterns": {
      "command": "node",
      "args": ["/absolute/path/to/accessibility-mcp/dist/cli.js"],
      "env": {
        "APG_MCP_DATA_DIR": "/absolute/path/to/accessibility-mcp/data"
      }
    }
  }
}

Visual Studio Code (GitHub Copilot agent / MCP)

VS Code stores MCP config in mcp.json using a servers object (not mcpServers). See Add and manage MCP servers in VS Code and the MCP configuration reference.

Workspace: .vscode/mcp.json
User: Command Palette → MCP: Open User Configuration

Example (local checkout):

{
  "servers": {
    "apg-patterns": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/accessibility-mcp/dist/cli.js"]
    }
  }
}

Example (npx, after publish):

{
  "servers": {
    "apg-patterns": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "accessibility-mcp"]
    }
  }
}

You can also use MCP: Add Server in the Command Palette or install from the Extensions view (@mcp gallery) if this server is listed there.

Cursor

Cursor merges MCP config from:

Project: .cursor/mcp.json
Global: ~/.cursor/mcp.json (project entries override global)

Use the mcpServers JSON shape from the shared snippets above. See Model Context Protocol (MCP) | Cursor Docs. Restart Cursor after changes if tools do not appear.

Claude Desktop

Edit the Claude desktop config file and merge under mcpServers:

OS	Typical path
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
Linux	`~/.config/Claude/claude_desktop_config.json`

Use the shared mcpServers snippet. Restart Claude Desktop after saving.

Claude Code

Claude Code supports project .mcp.json, local entries in ~/.claude.json, and user scope; stdio servers use command + args like other clients. See Connect Claude Code to tools via MCP.

Prerequisites: npm install, npm run build, and a .env next to package.json (or pass Ollama settings with repeated --env KEY=value; the server also loads .env from the package root automatically).

Put options (--transport, --scope, --env) before the server name; use -- before the process to spawn (documented ordering).

Local / project (from this repo; records a relative dist/cli.js — only works when that workspace is this package):

cd /absolute/path/to/accessibility-mcp
claude mcp add --transport stdio apg-patterns -- node dist/cli.js

claude mcp add --transport stdio apg-patterns --scope project -- node dist/cli.js

User scope (recommended — works from any folder; use your real path):

claude mcp add --transport stdio apg-patterns --scope user -- node /absolute/path/to/accessibility-mcp/dist/cli.js

After publish to npm:

claude mcp add --transport stdio apg-patterns -- npx -y accessibility-mcp

Then claude mcp list or /mcp in Claude Code to confirm. If the server won’t start, check that args points at the built cli.js. npm test and npm run mcp:try exercise the server without the Claude UI.

Gemini CLI

Configure mcpServers in Gemini CLI settings. User vs project scope:

User: ~/.gemini/settings.json
Project: .gemini/settings.json in the repo

Details: MCP servers with the Gemini CLI.

CLI (stdio; user scope — writes ~/.gemini/settings.json):

gemini mcp add --scope user apg-patterns node /absolute/path/to/accessibility-mcp/dist/cli.js

Use --scope project to write .gemini/settings.json instead. Run gemini mcp add --help for flags (-e for env, --trust, etc.).

OpenAI Codex (CLI and IDE extension)

Codex stores MCP servers in config.toml, default ~/.codex/config.toml, or project .codex/config.toml on trusted projects. CLI and IDE share this file. See Model Context Protocol – Codex.

TOML example (stdio):

[mcp_servers.apg-patterns]
command = "node"
args = ["/absolute/path/to/accessibility-mcp/dist/cli.js"]

CLI:

codex mcp add apg-patterns -- node /absolute/path/to/accessibility-mcp/dist/cli.js

Other editors

Windsurf / JetBrains / etc.: If the product documents MCP stdio support, reuse the same command / args as above; the wrapper key name may differ—check that product’s MCP docs.
VS Code discovery: With chat.mcp.discovery.enabled, VS Code can pick up MCP definitions from some other apps (e.g. Claude Desktop). See the VS Code MCP article.

Tools

Tool	Purpose
`apg_meta`	Source commit, generation time, patterns index URL
`apg_list_patterns`	All pattern ids/titles; optional `query` filter
`apg_get_pattern`	Markdown spec + example list (`patternId`, optional `includeMarkdown`)
`apg_get_example`	Example sources (`patternId`, `exampleSlug`, `format`: json \| markdown)
`apg_semantic_search`	RAG: natural-language search (`query`, optional `k`, `maxCharsPerHit`); needs `data/rag/chunks.json` (shipped) + Ollama to embed the query

Resources

apg://manifest — full manifest JSON
apg://pattern/{patternId} — pattern Markdown
apg://example/{patternId}/{slug} — example sources as Markdown

License

ISC (this package). APG content is W3C documentation; see W3C document license.

Available Tools

5 tools

apg_get_exampleA

Read-only

Official example source for one APG demo: HTML plus linked CSS/JS (and placeholders for binary assets).

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	json: structured files array; markdown: one fenced block per file	json
`patternId`	Yes
`exampleSlug`	Yes	Example id, e.g. carousel-1-prev-next (see apg_get_pattern / apg_list_patterns)

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, so the description does not need to reiterate read-only behavior. The description adds that the output includes placeholders for binary assets, which is extra context but not deep behavioral insight. No contradictions with 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, front-loaded sentence with no redundant words. It efficiently conveys the essential 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 tool's simplicity, no output schema, and good annotations, the description is reasonably complete. It states what the output contains (HTML, CSS, JS, placeholders). However, it could be more specific about the response format (e.g., structured files array vs. markdown blocks), which is partially covered by the format parameter description.

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?

The description does not add meaning beyond the input schema. Schema description coverage is 67% (patternId missing description); the tool description does not explain patternId. For format and exampleSlug, schema descriptions are adequate. Thus the description is neutral and does not compensate for gaps.

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 identifies the tool as providing example source code for an APG demo, specifying it includes HTML, CSS, JS, and binary placeholders. It distinguishes from siblings like apg_get_pattern (pattern metadata) and apg_list_patterns (listing patterns). However, it lacks an explicit verb (e.g., 'retrieve') and could be more direct about its action.

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 gives no explicit guidance on when to use this tool versus alternatives. It is implicitly clear that it is for obtaining example source code, but no comparative or contextual usage notes are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apg_get_patternA

Read-only

Full pattern documentation as Markdown (requirements, keyboard, ARIA, etc.) plus example summaries with live URLs.

ParametersJSON Schema

Name	Required	Description	Default
`patternId`	Yes	Pattern folder id, e.g. carousel, dialog-modal
`includeMarkdown`	No	Include the full Markdown body; if false, return metadata and example list only

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, so no destructive behavior. The description adds value by detailing the output format (Markdown, requirements, keyboard, ARIA, example summaries with live URLs), which goes beyond the annotations. No contradictions.

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, clear sentence that front-loads the key purpose and content of the response. No unnecessary words.

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 no output schema, the description adequately describes the response as full pattern documentation in Markdown and example summaries with live URLs. It covers the essential aspects for a retrieval tool, though it could mention the structure or metadata included.

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 100%, so baseline is 3. The description does not add extra semantics beyond what the schema provides for patternId and includeMarkdown; it only reiterates the concept of documentation.

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 returns 'full pattern documentation as Markdown' covering requirements, keyboard, ARIA, etc., plus example summaries with live URLs. This clearly distinguishes it from siblings like apg_list_patterns (which lists patterns) and apg_get_example (which gets a specific example).

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 provide explicit guidance on when to use this tool versus alternatives or when not to use it. While the purpose is clear, there is no mention of prerequisites, context, or exclusion scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apg_list_patternsA

Read-only

List all APG pattern ids and titles. Optional filter matches id or title (case-insensitive substring).

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Optional substring filter on pattern id or title

TDQS

A4.2/5.0

Behavior4/5

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

The description adds value beyond annotations by specifying the behavior of listing all pattern ids and titles with a case-insensitive substring filter. Annotations already mark it as readOnly and not open-world, and the description confirms safe read operation. No contradictions.

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 extremely concise: two sentences, no redundant words. The core purpose is front-loaded in the first sentence, and the filter detail is added immediately. Every word 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 listing tool with one optional parameter and no output schema, the description is complete enough. It explains what is returned (ids and titles) and the filter behavior. It does not specify the response format (e.g., JSON array), but the output is predictable for a list.

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% with a description for the 'query' parameter. The description adds the detail 'case-insensitive substring', which goes beyond the schema's 'optional substring filter'. This extra information helps the agent understand the parameter behavior.

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 'List all APG pattern ids and titles', specifying the verb (list), resource (APG patterns), and output (ids and titles). It includes an optional filter, and the name and description together distinguish from siblings like apg_get_pattern and apg_semantic_search.

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 that this tool is for listing all patterns with optional filtering, but does not explicitly state when to use it vs alternatives such as apg_get_pattern for a single pattern or apg_semantic_search for semantic queries. The context from sibling names helps, but the description itself lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apg_metaA

Read-only

APG dataset metadata: source commit, when generated, and link to the patterns index.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds detail about returned metadata fields, which is helpful and consistent.

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?

Single sentence, no fluff. Efficiently communicates purpose and content.

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?

Zero complexity, no parameters, good annotations. Description fully addresses what the tool does and what it returns.

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?

No parameters exist; schema coverage is 100% by default. Baseline score of 4 applies as no parameter information is needed.

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 returns APG dataset metadata including source commit, generation time, and link to patterns index. It distinguishes itself from sibling tools (list, get, search) by focusing on metadata.

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?

No explicit when-to-use or alternatives mentioned, but with zero parameters and a clear metadata purpose, usage is self-evident. The description implies use for dataset context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apg_semantic_searchA

Read-only

RAG: natural-language search over APG pattern Markdown and example source text. Returns the most similar chunks with patternId (and example slug when applicable). Follow up with apg_get_pattern / apg_get_example for full docs. Requires a pre-built index from npm run rag:index.

ParametersJSON Schema

Name	Required	Description
`k`	No	Number of chunks to return
`query`	Yes	Natural-language question or keywords
`maxCharsPerHit`	No	Truncate each hit text to this many characters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already confirm read-only and non-open-world. Description adds that it is RAG-based, returns similarity chunks with patternId/slug, and requires an index, which is useful behavioral context beyond 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?

Three concise sentences, front-loaded with the core purpose, then output details and prerequisite. No unnecessary words.

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 no output schema, description explains return structure (chunks with patternId, slug). Also mentions follow-up tools and requirement. Could expand on chunk content but adequate for a search tool with clear annotations.

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 covers all 3 parameters with descriptions (100% coverage). Description does not add significant semantic value for parameters beyond what schema already provides, though it hints at output format.

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?

Clearly states it performs natural-language semantic search over APG pattern Markdown and example source text, returning chunks with identifiers. Differentiates from sibling tools like apg_get_pattern (fetch full docs) and apg_list_patterns (list all patterns) by focusing on search.

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?

Provides prerequisite (pre-built index) and suggests follow-up tools for full docs. While it doesn't explicitly exclude other tools, the context and siblings make usage boundaries clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

All five tools have clearly distinct purposes: metadata, listing patterns, getting full pattern docs, getting example source, and semantic search. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent 'apg_verb_noun' pattern in snake_case (e.g., apg_list_patterns, apg_get_example), making the set predictable.

Tool Count5/5

Five tools is well-scoped for a read-only APG dataset access server. Each tool occupies a necessary role without excess or deficiency.

Completeness5/5

The tool surface covers the full lifecycle of discovering and retrieving APG patterns and examples: metadata, list, detail, example source, and semantic search. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MidOS - MCP Community Library A
io.github.MidOSresearch
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Knowledge & Memory RAG Systems Search
28
Jeikin
com.jeikin
Accessibility compliance for AI coding tools. WCAG 2.2 reviews with shared evidence.
Testing & QA Tools Developer Tools
2
saferagenticai-mcp A
io.github.NellInc
Read-only tools over the Safer Agentic AI framework: 238 patterns + 14 heuristics.
Autonomous Agents AI & Machine Learning
122
accessibility-ai A
io.github.groundlogic-ai-source
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Testing & QA Tools Legal & Compliance AI & Machine Learning
421

Related MCP Servers

Components Build MCP
Developer Tools Documentation Access Code Analysis
getlokiui
A
license
B
quality
D
maintenance
Provides AI assistants with tools to grade, generate, and validate UI components against the components.build specification. Supports searching documentation, checking compliance, and generating framework-agnostic accessible components.
Updated 9 months ago (2025-12-03 07:48 UTC)
11
19
Apache 2.0
aria-mcp
Developer Tools Documentation Access Testing & QA Tools
joe-watkins
A
license
A
quality
B
maintenance
Provides comprehensive access to the W3C WAI-ARIA specification for querying roles, states, properties, and accessibility requirements. It enables developers and AI agents to validate ARIA attributes and receive smart role suggestions based on UI component descriptions.
Updated 12 days ago (2026-08-23 01:13 UTC)
21
16
3
MIT
AWP MCP Server
Developer Tools Documentation Access API Testing
agentwebprotocol
A
license
Not graded
quality
D
maintenance
Provides tools for AI assistants to access the Agent Web Protocol (AWP) specification, validate agent.json files, and generate protocol-compliant configurations. It enables developers to integrate the AWP standard into their websites through natural language prompts and automated validation.
Updated 6 months ago (2026-03-18 01:04 UTC)
14
MIT
accessibility-mcp-server
Testing & QA Tools Browser Automation
AiAgentKarl
A
license
A
quality
D
maintenance
Enables AI agents to perform comprehensive web accessibility checks (WCAG 2.1/2.2) including color contrast analysis, ARIA validation, and full accessibility report generation without requiring any API key.
Updated 5 months ago (2026-04-09 07:44 UTC)
8
MIT

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

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

accessibility-mcp

Dataset

Usage

npx (after publish to npm)

Publishing (npm tarball)

MCP Inspector (dev)

Try tools without Claude (CLI)

Environment (.env)

Without Ollama (no local LLM)

IDE and agent setup

Shared snippets

Visual Studio Code (GitHub Copilot agent / MCP)

Cursor

Claude Desktop

Claude Code

Gemini CLI

OpenAI Codex (CLI and IDE extension)

Other editors

Tools

Resources

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Environment (`.env`)