Configuratie Referentie
Deze pagina documenteert de omgevingsvariabelen die de axe MCP Server leest, en de aanbevolen aangepaste instructies voor uw AI-agent. Deze zijn van toepassing op zowel de Docker- en npm-distributies. Voor waar u deze waarden kunt plaatsen, zie uw handleiding voor het instellen van de client.
Configuratieopties
De axe MCP Server ondersteunt verschillende omgevingsvariabelen voor aanpassing:
| Omgevingsvariabele | Beschrijving | Standaard |
|---|---|---|
AXE_API_KEY |
API-sleutel voor authenticatie (zie API-sleutel). Wederzijds exclusief met AXE_ACCESS_TOKEN. |
|
AXE_ACCESS_TOKEN |
OAuth 2.0 Bearer-token voor authenticatie (zie OAuth 2.0). Wederzijds exclusief met AXE_API_KEY. |
|
AXE_SERVER_URL |
De basis-URL van het axe Account Portal van uw organisatie. Alleen vereist als uw organisatie niet de standaard gedeelde US SaaS-instantie gebruikt. Zie hieronder voor details. | "https://axe.deque.com" |
AXE_CHROME_PATH |
Pad naar een Chrome/Chromium-binary om te gebruiken in plaats van de Playwright-beheerde installatie. alleen npm-distributie. Zie hieronder voor vereisten. | |
BROWSER_TIMEOUT_MS |
Het aantal milliseconden dat we browserinteracties toestaan te wachten voordat ze verlopen | 30000 |
LOG_LEVEL |
Volgt het Syslog-protocol; ondersteunde waarden zijn "debug", "info", "warn", en "error" |
"info" |
AXE_SERVER_URL
De standaardwaarde (https://axe.deque.com) is correct voor de meeste gebruikers — degenen op Deque's gedeelde US SaaS-instantie. Als uw organisatie een van de volgende gebruikt, moet u AXE_SERVER_URL instellen op de basis-URL van uw instantie:
- Een regionale SaaS-instantie (EU, Australië, Frankfurt, etc.)
- Een private cloud implementatie
- Een on-premises installatie
Als u niet zeker weet welke instantie uw organisatie gebruikt, controleer dan de URL die u gebruikt om in te loggen bij het axe Account Portal, of vraag het uw beheerder.
Stel AXE_SERVER_URL expliciet in de env blok van uw MCP-serverconfiguratie. De handleidingen voor clientsetup bevatten voorbeelden die precies laten zien waar het moet worden toegevoegd.
AXE_CHROME_PATH
alleen npm-distributie. Dit wordt niet ondersteund in Docker, dat altijd zijn gebundelde browser gebruikt — de server start niet op als AXE_CHROME_PATH is ingesteld onder de Docker-distributie.
Standaard gebruikt de npm-distributie de Chromium-build die u installeert via Playwright. Stel AXE_CHROME_PATH in op het volledige pad van een bestaande Chrome/Chromium-binaire om die te gebruiken en de Playwright-installatie over te slaan.
- De waarde moet een uitvoerbaar binair bestandzijn, geen
.appbundel of directory. Wijs op macOS bijvoorbeeld naar de binaire binnen de bundel:/Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing. - Het binaire bestand moet starten en reageren op
--version. De server valideert dit bij het opstarten en faalt snel metUnable to find specified chrome instanceals dit niet kan. - Branded Google Chrome stabiel 137 en later wordt niet ondersteund. Gebruik Chrome voor testen of een andere Chromium-compatibele binaire.
De analyze en igt tools accepteren ook een argument per oproep, chromePath welk voorrang heeft boven AXE_CHROME_PATH voor die oproep.
Uw AI-agent configureren (Aanbevolen)
Om ervoor te zorgen dat uw AI-coderingsagent de Axe MCP Server-tools correct gebruikt en de beste toegankelijkheidspraktijken volgt, kunt u deze voorzien van aangepaste instructies. Deze instructies helpen de agent om de juiste workflow te begrijpen voor het analyseren en verhelpen van toegankelijkheidsproblemen.
Waar instructies toe te voegen
De methode verschilt per client:
- VS Code met GitHub Copilot - Voeg toe aan
.github/copilot-instructions.mdin de hoofdmap van uw project - Cursor - Voeg toe aan „Cursorregels“ in instellingen
- Claude Code - Voeg toe aan een
CLAUDE.mdbestand in de hoofdmap van uw project - Claude Desktop - Voeg toe aan aangepaste instructies in instellingen
- Andere MCP-clients - Raadpleeg de documentatie van uw client voor configuratie van aangepaste instructies
Voorbeeldwerkstroominstructies
Hieronder staat een aanbevolen sjabloon dat u kunt aanpassen voor uw agent:
# 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 complianceWaarom dit belangrijk is
Deze instructies zorgen ervoor dat uw agent:
- Gebruik maakt van Deque's expertise - Benut AI-modellen getraind op tientallen jaren toegankelijkheidsdatabasegegevens in plaats van algemene LLM-kennis
- Volgt de beste praktijken - Past consequente, WCAG-conforme oplossingen toe in plaats van generieke oplossingen
- Verifieert wijzigingen - Bevestigt altijd dat de oplossingen daadwerkelijk de problemen hebben opgelost
- Vermijdt valse zekerheid - Neemt niet aan dat het weet hoe toegankelijkheidsproblemen moeten worden opgelost zonder deskundige begeleiding
Hoewel optioneel, verbetert het verstrekken van deze instructies de kwaliteit en betrouwbaarheid van toegankelijkheidsoplossingen in je codebase aanzienlijk.
