Referencia de Configuración

Esta página documenta las variables de entorno que el servidor axe MCP lee, y las instrucciones personalizadas recomendadas para su agente de IA. Estas se aplican a ambas distribuciones de Docker y npm. Para saber dónde colocar estos valores, consulte su guía de configuración del cliente.

Opciones de Configuración

El servidor axe MCP admite varias variables de entorno para la personalización:

AXE_SERVER_URL

El valor predeterminado (https://axe.deque.com) es correcto para la mayoría de los usuarios: aquellos en la instancia compartida de SaaS de EE.UU. de Deque. Si su organización utiliza cualquiera de los siguientes, debe establecer AXE_SERVER_URL a la URL base de su instancia:

• Una instancia de SaaS regional (UE, Australia, Frankfurt, etc.)
• Un cloud privado desplegable
• Una instalación on-premises

Si no está seguro de qué instancia usa su organización, verifique la URL que utiliza para iniciar sesión en el portal de cuentas axe, o pregunte a su administrador.

Establecer AXE_SERVER_URL explícitamente en el env bloque de la configuración de su servidor MCP. Las guías de configuración del cliente incluyen ejemplos que muestran exactamente dónde añadirlo.

AXE_CHROME_PATH

Solo distribución npm. Esto no es compatible en Docker, que siempre usa su navegador incluido: el servidor falla al iniciar si AXE_CHROME_PATH está configurado en la distribución de Docker.

Por defecto, la distribución npm usa la versión de Chromium que usted instala a través de Playwright. Configure AXE_CHROME_PATH con la ruta completa de un binario existente de Chrome/Chromium para usarlo en su lugar y omitir la instalación de Playwright.

• El valor debe ser un archivo binario ejecutable, no un .app paquete o directorio. En macOS, por ejemplo, apunte al binario dentro del paquete: /Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing.
• El binario debe lanzarse y responder a --version. El servidor valida esto al iniciar y falla rápidamente con Unable to find specified chrome instance si no puede.
• Google Chrome de marca estable 137 y posteriores no es compatible. Utilice Chrome para pruebas u otro binario compatible con Chromium.

El analyze y los igt herramientas también aceptan por llamada un chromePath argumento, que tiene prioridad sobre AXE_CHROME_PATH para esa llamada.

Configuración de su agente de IA (Recomendado)

Para asegurar que su agente de codificación de IA utiliza correctamente las herramientas del servidor axe MCP y sigue las mejores prácticas de accesibilidad, puede proporcionarle instrucciones personalizadas. Estas instrucciones ayudan al agente a entender el flujo de trabajo adecuado para analizar y remediar problemas de accesibilidad.

Dónde agregar las instrucciones

El método varía según el cliente:

• VS Code con GitHub Copilot - Añadir a .github/copilot-instructions.md en el directorio raíz de su proyecto
• Cursor - Añadir a "Reglas de Cursor" en la configuración
• Claude Code - Añadir a un CLAUDE.md archivo en el directorio raíz de su proyecto
• Claude Desktop - Añadir a instrucciones personalizadas en la configuración
• Otros clientes MCP - Consulte la documentación de su cliente para la configuración de instrucciones personalizadas

Ejemplo de instrucciones de flujo de trabajo

A continuación se presenta una plantilla recomendada que puede adaptar para su agente:

# Accessibility Testing and Remediation Workflow

## MANDATORY WORKFLOW - DO NOT DEVIATE

When working with accessibility issues, you MUST follow this exact workflow:

### 1. Analysis Phase

When asked to analyze pages for accessibility issues, you MUST:

- Use the `analyze` tool to scan the page
- Do NOT manually identify accessibility issues
- Always provide the complete URL being analyzed

### 2. Authentication & Pre-Scan Setup

When the user's request involves credentials, form input, dismissing
overlays, or waiting for content before the scan, you MUST:

- Pass an ordered `before` array to the `analyze` tool using the
  `click`, `fill`, and `waitFor` actions
- Resolve any references to env vars, `.env*` files, or local
  configuration into literal strings BEFORE calling the tool — the
  server treats `value` as a literal and will not expand `${VAR}`,
  `$VAR`, or `{{VAR}}` syntax
- Use `fill` for secret values so the server's redaction protections
  apply; never embed secrets in a `selector`, which appears in logs
  and error messages
- ASK the user when the source of a credential or value is ambiguous;
  do NOT guess or fabricate values
- Use ONLY selectors the user provided; if a step needs a selector
  the user did not name, ASK rather than guess
- Use `waitFor` after any `click`/`fill` that triggers async UI
  (route changes, late-rendered content) to deterministically gate
  the next step or the scan — pick a selector that exists ONLY in
  the post-interaction state (e.g., a logout button or dashboard
  heading), never a generic one like `body` or `#app` that already
  exists beforehand

### 3. Remediation Phase

When asked to remediate or fix accessibility issues, you MUST:

- Collect ALL violations from the analysis and pass them to the
  `remediate` tool in a SINGLE batched call — do NOT call `remediate`
  once per issue
- Give each issue a unique `id` so each result can be correlated
  back to its input
- Provide the exact HTML element, rule ID, and issue description for
  every issue in the batch
- Review the remediation guidance before making any code changes
- Apply fixes based on the remediate tool's recommendations
- Do NOT manually fix accessibility issues without first using the remediate tool

### 4. Verification Phase

After applying fixes, you MUST:

- Re-run `analyze` to verify all issues are resolved
- Confirm zero violations before considering the task complete

## Required Workflow Example:

1. analyze → Find violations
2. remediate → Pass ALL violations in one batched call to get fix guidance
3. Apply recommended fixes to code
4. analyze → Verify fixes

## Enforcement

- NEVER skip the remediate tool when fixing accessibility issues
- ALWAYS use both analyze and remediate tools as specified
- This workflow ensures proper accessibility best practices and compliance

Por qué es importante

Estas instrucciones aseguran que su agente:

• Usa la experiencia de Deque - Aprovecha modelos de IA entrenados en décadas de datos de evaluación de accesibilidad en lugar de conocimiento general de LLM
• Sigue las mejores prácticas - Aplica correcciones consistentes que cumplen con WCAG en lugar de soluciones genéricas
• Verifica los cambios - Siempre confirma que las correcciones realmente resolvieron los problemas
• Evita la falsa confianza - No asume que sabe cómo solucionar problemas de accesibilidad sin orientación experta

Aunque es opcional, proporcionar estas instrucciones mejora significativamente la calidad y fiabilidad de las correcciones de accesibilidad en tu código.