Skip to main content
Glama
smkbarbosa

guia-wcag-mcp

by smkbarbosa
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

guia-wcag-mcp

CI

Servidor MCP (Model Context Protocol) local, em Node.js/TypeScript, que expõe uma base de conhecimento de acessibilidade web para agentes de IA no VS Code (Cline, Roo Code, prompts locais). O conteúdo é inspirado no formato de cartões do Guia WCAG de Marcelo Sales e cruza critérios de sucesso da WCAG 2.2 com os itens normativos correspondentes da ABNT NBR 17225:2025 (norma brasileira de acessibilidade digital).

⚠️ Este servidor não audita nem certifica acessibilidade sozinho. Todas as tools devolvem, ao final da resposta, o aviso: "LLMs ajudam a planejar testes, mas não comprovam conformidade sozinhas. Realize testes manuais com teclado e tecnologias assistivas. A decisão final é humana."

O que ele expõe

Resource

  • wcag://v2.2/simplified-guide — JSON com os 10 critérios de sucesso cobertos, organizados por princípio (Perceptível, Operável, Compreensível, Robusto), cada um com descrição simplificada, palavras-chave e correlações com a ABNT NBR 17225.

Tools

Tool

Argumento

O que faz

get_criterion_details

criterion (ex.: "1.4.3")

Descrição simplificada do critério + itens ABNT correlacionados.

search_criteria_by_keyword

keyword (ex.: "contraste", "erro")

Filtra os cartões do guia que correspondem à palavra-chave.

generate_manual_test_routine

criterion (ex.: "2.1.1")

Roteiro de teste manual passo a passo (teclado / leitor de tela). A execução e o veredito continuam sendo humanos.

Critérios cobertos hoje: 1.1.1, 1.4.1, 1.4.3, 1.4.11, 2.1.1, 2.4.7, 2.5.8, 3.3.1, 3.3.2, 4.1.2.

As descrições, resumos das correlações ABNT e roteiros de teste foram redigidos neste projeto no mesmo espírito "descomplicado" do guia original — não são cópia literal do site (que é uma SPA renderizada via JS) nem do texto oficial da norma ABNT (protegida por direitos autorais). Para a redação normativa exata, consulte a ABNT NBR 17225:2025 na íntegra.

Related MCP server: w3c-mcp

Requisitos

  • Node.js >= 20 (desenvolvido e testado em Node 22.x e 24.x)

  • npm

Instalação e build

npm ci
npm run build

Rodando os testes

npm test

O script test compila o projeto (pretest) e roda a suíte com Vitest: testes unitários da base de dados e das funções de cada tool, além de um teste de integração que sobe o servidor compilado e conversa com ele via stdio usando JSON-RPC de verdade (o mesmo protocolo que o VS Code usa).

Como configurar o MCP no VS Code

Em todos os casos abaixo, rode npm run build antes (o servidor é iniciado a partir de dist/index.js) e troque /caminho/absoluto/para/guia_wcag_mcp pelo caminho onde você clonou este repositório.

VS Code nativo (GitHub Copilot Chat, modo agente)

O VS Code tem suporte nativo a MCP — não precisa de extensão de terceiros.

Só neste workspace: crie o arquivo .vscode/mcp.json na raiz do projeto:

{
  "servers": {
    "guia-wcag-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["${workspaceFolder}/dist/index.js"]
    }
  }
}

Em todos os workspaces: abra a paleta de comandos (Ctrl+Shift+P / Cmd+Shift+P) e rode MCP: Add Server... → Command (stdio), informando node como comando e o caminho absoluto de dist/index.js como argumento. Isso grava a configuração no mcp.json de usuário (acessível depois via MCP: Open User Configuration).

Em ambos os casos, depois de salvar, abra o painel do Copilot Chat, mude para o modo agente e clique em "Iniciar" ao lado do servidor guia-wcag-mcp (ou rode MCP: List Servers na paleta de comandos para gerenciar/reiniciar).

Cline / Roo Code

Registre o servidor no arquivo de configuração de MCP da extensão (cline_mcp_settings.json para o Cline, mcp_settings.json para o Roo Code — ambos usam a mesma estrutura):

{
  "mcpServers": {
    "guia-wcag-mcp": {
      "command": "node",
      "args": [
        "/caminho/absoluto/para/guia_wcag_mcp/dist/index.js"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}

Depois de salvar, recarregue a extensão (painel "MCP Servers" → Restart).

Estrutura do projeto

src/
  data/
    wcag-guide.ts        # os 10 critérios (dados + tipos)
    wcag-guide.test.ts    # testes de integridade dos dados
  lib/
    wcag-tools.ts         # lógica pura por trás do resource e das tools
    wcag-tools.test.ts    # testes unitários dessa lógica
  index.ts                 # wiring do McpServer (resource + tools + stdio)
  index.integration.test.ts # sobe o servidor compilado e testa via JSON-RPC

CI e segurança da cadeia de suprimentos

O workflow .github/workflows/ci.yml roda em todo push e pull request para main, em dois jobs sequenciais — o build só é considerado aprovado no GitHub se ambos passarem:

  1. security — antes de qualquer build/teste:

    • npm ci --ignore-scripts: instala as dependências sem executar scripts de install/postinstall de terceiros (o vetor mais comum de infostealers e worms publicados no npm; nenhuma dependência deste projeto precisa desses scripts).

    • npm audit signatures: verifica a assinatura/proveniência de cada pacote instalado junto ao registry oficial do npm.

    • npm audit --audit-level=high: falha o build se houver vulnerabilidade conhecida de nível alto/crítico em qualquer dependência.

    • Checagem extra que garante que todo pacote do package-lock.json foi resolvido a partir de registry.npmjs.org (proteção contra dependency confusion / registries substituídos).

  2. build-and-test (depende do job acima) — compila o projeto e roda npm test em Node 22.x e 24.x.

O workflow .github/workflows/codeql.yml roda CodeQL (análise estática de JavaScript/TypeScript) em todo push/PR para main e semanalmente, para pegar padrões de código inseguro.

Além disso, o Dependabot abre PRs semanais para manter as dependências (npm e GitHub Actions) atualizadas.

A branch main exige, via regra do repositório, que os checks de CI e ao menos uma aprovação de PR passem antes do merge.

Essas checagens reduzem o risco, mas não eliminam: sempre revise PRs que alterem package.json/package-lock.json antes de fazer merge.

Licença

ISC — veja package.json.

Available Tools

3 tools
generate_manual_test_routineGerar roteiro de teste manualA

Gera um roteiro de teste manual passo a passo (teclado e leitor de tela) para um critério WCAG. A execução e o veredito continuam sendo humanos.

ParametersJSON Schema
NameRequiredDescriptionDefault
criterionYesNúmero do critério WCAG, ex.: "2.1.1"

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the routine is step-by-step, covers keyboard and screen reader, and importantly states that execution and verdict remain human, preventing misuse as an automated testing tool. It could add more about output structure, but the core behavioral constraint is clearly conveyed.

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 two short sentences with no filler. It front-loads the main output and then adds the crucial human-in-the-loop caveat, making every sentence valuable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description adequately defines the deliverable and its scope. It could further describe the expected structure of the routine or behavior for invalid criteria, but the essential information needed to call the tool correctly is present.

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 criterion is already documented with an example. The description confirms the criterion is a WCAG criterion but does not add significant additional meaning 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 uses a specific verb and resource: it generates a step-by-step manual test routine for a WCAG criterion, with explicit mention of keyboard and screen reader coverage. This clearly distinguishes it from siblings like get_criterion_details and search_criteria_by_keyword, since only this tool produces a test routine.

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 when to use the tool: when a manual WCAG test routine is needed. However, it does not explicitly state when not to use it or mention alternatives such as get_criterion_details for criterion information, so usage guidance is left to inference.

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

get_criterion_detailsDetalhes de um critério WCAGA

Retorna a descrição simplificada do guia e os itens normativos da ABNT NBR 17225 correlacionados a um critério de sucesso da WCAG (ex.: "1.4.3").

ParametersJSON Schema
NameRequiredDescriptionDefault
criterionYesNúmero do critério WCAG, ex.: "1.4.3"

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosing behavior. 'Retorna' clearly signals a read-only retrieval with no side effects, and the response content is described. It does not cover edge cases like invalid criterion numbers or exact-match behavior, but for a simple lookup tool this is adequate.

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 focused sentence with no filler. The core resource, the returned content, and an example are all included efficiently.

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 tool with one required parameter, no output schema, and no nested objects, the description gives enough information for an agent to call it correctly. The only minor gap is the lack of explicit output structure, but the described return content makes the call's purpose and result clear.

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 schema already fully describes the criterion parameter with an example, and the description repeats the WCAG criterion concept without adding new semantic details. At 100% schema description coverage, the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the simplified guide description and ABNT NBR 17225 normative items correlated to a WCAG success criterion. The verb 'Retorna' and the resource are specific, and the example format "1.4.3" disambiguates from the sibling keyword-search tool.

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 intended use is inferred: call it when you have a specific WCAG criterion number and need its correlated NBR details. However, the description does not explicitly state when to prefer this over search_criteria_by_keyword or generate_manual_test_routine, nor does it mention any exclusions or prerequisites.

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

search_criteria_by_keywordBuscar critérios por palavra-chaveA

Filtra os cartões do guia que correspondem a uma palavra-chave (ex.: "contraste", "erro").

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesPalavra-chave a buscar, ex.: "contraste", "erro"

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full behavioral burden. 'Filtra' (filters) conveys a read-only, non-destructive operation and indicates the outcome (matching cards), but it stops short of stating matching semantics (e.g., substring vs. exact, case sensitivity) or whether any side effects occur.

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 that states the operation, the resource, and an example without any filler. It is appropriately sized for a trivial one-parameter search.

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 search tool with one parameter and no output schema, the description adequately communicates the returned resource (matching guide cards). It does not detail the return shape or matching behavior, but given the tool's low complexity this is acceptable.

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 input schema already documents the keyword parameter with 100% coverage, including an example. The tool description repeats the same example without adding new meaning, so it meets the baseline but adds no extra semantic value.

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 uses the specific verb 'filtra' (filters) with the resource 'cartões do guia' and makes the search criterion explicit ('palavra-chave'). This clearly conveys what the tool does, though it does not name the sibling tools or explicitly contrast with them.

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 finding guide cards based on a keyword, but it gives no explicit guidance on when to choose it over get_criterion_details or generate_manual_test_routine. The intended context is inferable from the examples, but exclusions and alternative routing are absent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedgenerate_manual_test_routine
    • First observedget_criterion_details
    • First observedsearch_criteria_by_keyword
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving details for a known criterion, searching by keyword, and generating a manual test routine. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow the same lowercase snake_case verb_noun pattern: get_criterion_details, search_criteria_by_keyword, generate_manual_test_routine. The naming is predictable and consistent.

Tool Count5/5

With only three tools, the server is compact but well-scoped for its niche purpose. Each tool earns its place by covering a distinct aspect of working with WCAG criteria.

Completeness4/5

The server covers the core workflow: finding criteria, retrieving details, and generating manual test routines. A minor gap is the lack of a way to browse or list all criteria at once, but agents can work around this with keyword search.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • w3c-mcp

    shuji-bonji
    A
    license
    A
    quality
    B
    maintenance
    MCP Server for accessing W3C/WHATWG/IETF web specifications. Provides AI assistants with access to official web standards data including specifications, WebIDL definitions, CSS properties, and HTML elements.
    11
    32
    4
    MIT

  • e11y-docs-mcp

    vltansky
    A
    license
    A
    quality
    D
    maintenance
    MCP server that provides access to web accessibility documentation, enabling search and retrieval of W3C WAI-ARIA patterns and accessibility best practices.
    3
    16
    MIT

Latest Blog Posts

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/smkbarbosa/mcp-wcag'

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