**axe MCP Server**
Überblick
Der axe MCP Server ist ein Model Context Protocol (MCP) Server, der die barrierefreie Prüfung auf Unternehmensniveau direkt in Ihren Entwicklungsworkflow integriert. Basierend auf der bewährten axe-Plattform ermöglicht er Entwicklern, umfassende Barrierefreiheits-Scans durchzuführen und fundierte Unterstützung zur Behebung von Problemen direkt in ihrer IDE zu erhalten.
Der Server bietet drei Funktionen – analyze, remediateund igt.
Diese Tools integrieren sich nahtlos mit MCP-kompatiblen Clients (wie Claude Desktop, VS Code mit Copilot oder Cursor) und berücksichtigen die axe-Konfigurationseinstellungen Ihrer Organisation.
Zugang erhalten
Der axe MCP Server ist im Axe DevTools für Web Paket. Ein Abonnement, das den Zugriff auf den axe MCP-Server ermöglicht, wird durch ein Gespräch mit einem Deque-Vertriebsmitarbeiter eingerichtet.
Tools & Funktionen
Das analyze Tool
Das analyze Tool führt eine umfassende Barrierefreiheitsanalyse von Webseiten durch, indem es einen Scan über die axe DevTools Browser-Erweiterung in einer realen Browserumgebung durchführt. Es funktioniert nahtlos mit sowohl lokalen Entwicklungs-URLs (z. B. localhost:3000) als auch mit Remote-Produktions-URLs.
Was es macht
- Authentifizierung - Validiert die Benutzerdaten (entweder einen API-Schlüssel oder ein OAuth 2.0-Zugriffstoken), um autorisierten Zugang sicherzustellen
- Konfigurationsabfrage - Ruft die organisationsspezifische axe-Konfiguration Einstellungen des Benutzers ab, einschließlich:
- Barrierefreiheits-Standard (z. B. WCAG 2.2 AA)
- axe-core Version
- Bedarf an Überprüfung / bewährte Praktiken
- Browserbasierte Analyse - Startet eine Browser-Instanz im Hintergrund mit der montierten axe DevTools-Erweiterung
- Seitennavigation - Navigiert zur vom Benutzer im Prompt an den KI-Agenten bereitgestellten URL
- Barrierefreiheits-Scan - Führt eine vollständige Barrierefreiheitsanalyse auf der gerenderten Seite durch, indem die axe DevTools Browser-Erweiterung verwendet wird und sichergestellt wird, dass die tatsächliche Benutzererfahrung getestet wird (nicht nur statisches HTML)
- Ergebnisauslieferung - Gibt umfassende Analyseergebnisse in einem strukturierten Format an den Agenten zurück
Reaktionsfähiges Testen
Das analyze Tool unterstützt optionale viewportWidth und viewportHeight Parameter, die es Ihnen ermöglichen, Seiten bei spezifischen Viewport-Dimensionen zu testen. Dies ist nützlich, um Barrierefreiheitsprobleme zu erkennen, die nur bei bestimmten Bildschirmgrößen wie mobilen oder Tablet-Auflösungen auftreten.
Analyze http://localhost:3000 for accessibility issues at a mobile viewport of 375x812Wenn diese Parameter weggelassen werden, verwendet der Browser seine Standard-Viewport-Größe.
Teilschrittscans
Standardmäßig scannt das analyze Tool die gesamte Seite. Um den Scan auf einen bestimmten Bereich zu beschränken, geben Sie den optionalen selector Parameter — nützlich, um sich auf eine einzelne Komponente zu konzentrieren oder störende, nicht zugehörige Teile der Seite aus den Ergebnissen auszuschließen.
-
Ein einzelner CSS-Selektor-String richtet sich auf ein Element im oberen Rahmen:
{ "url": "http://localhost:3000", "selector": "#main" } -
Ein Array von CSS-Selektoren durchläuft iframe- oder Shadow-DOM-Grenzen — jeder Abschnitt wählt den Host für den nächsten. Verwenden Sie ein Array nur, wenn das Ziel innerhalb eines iframes oder Shadow-Root liegt:
{ "url": "http://localhost:3000", "selector": ["iframe#checkout", "#payment-form"] }
Ein Array unterstützt bis zu 10 Segmente. Wenn der Selektor kein Element auf der Seite trifft, gibt der Scan einen Fehler zurück. Wenn selector weggelassen wird, wird die gesamte Seite gescannt.
Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:
Scan only the #main region of http://localhost:3000 for accessibility issuesBrowser-Interaktionen vor dem Scannen
Das analyze Tool unterstützt ein optionales before Array von Interaktionsschritten, die nach dem Laden der Seite aber vor dem Barrierefreiheits-Scan. Dies öffnet mehrere reale Testszenarien:
- Anmeldeseiten — füllen Sie Anmeldedaten aus und senden Sie sie ab, bevor Sie die Seite nach der Anmeldung scannen
- Cookie/Einwilligungsbanner — schließen Sie Banner, die sonst den Seiteninhalt überlagern oder verdecken würden
- Dynamische Inhalte — warten Sie, bis vom Client gerenderte Inhalte (Routenänderungen, spät injizierter DOM) erscheinen, bevor Sie scannen
Schritte werden in Array-Reihenfolge im gleichen Browserkontext wie der Scan ausgeführt, sodass Cookies, localStorageund alle durch click oder fill im Scan erhalten bleiben.
Das before Array unterstützt bis zu 20 Schritte. Jeder Schritt erhält seine eigene Timeout-Zeit von BROWSER_TIMEOUT_MS (Standard 30000 ms); es gibt keine individuellen Überschreibungen für Schritte.
Unterstützte Aktionen
| Aktion | Erforderliche Felder | Optionale Felder | Zweck |
|---|---|---|---|
click |
selector |
Klicken Sie auf das Element, das dem CSS entspricht selector (z. B. eine Senden-Schaltfläche, eine „Schließen“-Schaltfläche auf einem Banner). |
|
fill |
selector, value |
Ein Eingabefeld ausfüllen, das selector entspricht, mit value. Verwenden Sie dies für Anmeldedaten, Suchanfragen oder Formularfelder. Ein leerer String löscht die Eingabe. |
|
waitFor |
selector |
state — eines von "visible" (Standard), "attached", "hidden", "detached" |
Warten auf das Element, das zu selector passt, um statezu erreichen. Verwenden Sie dies, um den nächsten Schritt oder den Scan selbst zu ermöglichen. Wählen Sie einen Selector, der nur im Zustand nach der Interaktion existiert (z. B. eine Abmelde-Schaltfläche oder eine Dashboard-Überschrift) — generische Selektoren wie body oder #app existieren bereits vor der Interaktion und lösen sich sofort auf, sodass sie nichts steuern. |
Beispiel: Anmeldung vor dem Scannen
Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:
Analyze http://localhost:3000 for accessibility issues. Before running
the analysis, fill in the #username and #password fields with USERNAME
and PASSWORD from ./.env.local, click the button[type=submit] button,
and wait for #main-content to appear.Der Agent löst die Eingabeaufforderung auf und ruft das analyze Werkzeug mit einer Nutzlast auf, die ungefähr wie folgt aussieht:
{
"url": "http://localhost:3000",
"before": [
{
"action": "fill",
"selector": "#username",
"value": "<resolved-from-.env.local>"
},
{
"action": "fill",
"selector": "#password",
"value": "<resolved-from-.env.local>"
},
{ "action": "click", "selector": "button[type=submit]" },
{ "action": "waitFor", "selector": "#main-content" }
]
}fill.value wird als sensibel behandelt. Der axe MCP Server protokolliert niemals fill.value, gibt es nie in Fehlermeldungen aus und sendet es niemals an Telemetrie. Verwenden Sie fill für alle vom Benutzer bereitgestellten oder geheimen Eingaben (Passwörter, API-Token usw.), damit Geheimnisse im gesamten Prozess verborgen bleiben — und betten Sie niemals sensible Werte in ein selectorein, was erscheint in Protokollen und Fehlermeldungen.
Der Agent löst value, nicht der Server. Der axe MCP Server behandelt value als einen literalen String — er liest nicht Dateien, erweitert keine Umgebungsvariablen und interpretiert keine Platzhaltersyntax wie ${VAR}, $VARoder {{VAR}}. Ihr KI-Agent (Claude, Copilot, Cursor usw.) ist dafür verantwortlich, die Absicht des Nutzers in einen konkreten String umzusetzen, bevor das Tool aufgerufen wird.
In der Praxis bedeutet das:
- Formulieren Sie Aufforderungen natürlich — „verwende BENUTZERNAME/PASSWORT aus
.env.local“ funktioniert. Der Agent liest die Datei mit seinen eigenen Dateisystemtools und ersetzt die Werte. - Platzhaltersyntax nicht einfügen — das Schreiben von
value: "${USERNAME}"in einer Aufforderung bewirkt, dass der literale String${USERNAME}in das Eingabefeld eingegeben wird. - Seien Sie explizit bei mehrdeutigen Quellen — wenn Sie sagen „verwende meine gespeicherten Anmeldedaten“ ohne den Agenten auf eine Datei oder Umgebungsvariable hinzuweisen, wird ein gut funktionierender Agent nachfragen, anstatt zu raten. Sagen Sie ihm, wo er suchen soll.
Einige Authentifizierungsprozesse werden nicht unterstützt. before Aktionen steuern die Seite durch Playwright-ähnliche Interaktionen in einer Dockerisierten Chromium-Instanz. Folgende Punkte liegen absichtlich außerhalb des Geltungsbereichs:
- Captcha -Herausforderungen (reCAPTCHA, hCaptcha usw.)
- 2FA / TOTP / SMS Bestätigungscodes
- Drittanbieter-SSO Umleitungslisten (z. B. „Mit Google anmelden“, von Okta gehostete Anmeldeseiten)
Wenn Ihr eigentlicher Anmeldevorgang ein oben genanntes Element benötigt, prüfen Sie einen alternativen Einstiegspunkt:
- Eine vorab authentifiziertes Sitzungscookie in einer Staging-Umgebung integriert
- Eine Sitzungstoken oder Umgehungs-URL , die Ihr Team für automatisierte Tests verwendet
- Eine Staging-URL mit deaktivierter Authentifizierung für Barrierefreiheitstests
Wichtige Vorteile
- Echtbrowser-Tests - Testet die tatsächlich gerenderte Seite, nicht nur den Quellcode, um genaue Ergebnisse zu gewährleisten
- Organisationsstandards - Respektiert die axe-Konfigurationseinstellungen Ihres Teams für konsistentes Testen über alle Benutzer hinweg
- Umfassende Abdeckung - Nutzt die branchenführende axe-Plattform
- Reaktionsfähiges Testen - Testen bei bestimmten Ansichtsgrößen, um aufbruchsspezifische Barrierefreiheitsprobleme zu erkennen
- Gezielte Scans - Beschränken Sie einen Scan auf einen bestimmten Bereich, ein iframe oder eine Shadow-Root mit dem
selectorParameter - Authentifizierte & Interaktive Seiten - Scannen Sie Seiten hinter einem Login, schließen Sie Cookie-Banner oder warten Sie auf dynamische Inhalte mithilfe von
beforeAktionen
Ausgabe
Das Tool gibt eine strukturierte JSON-Antwort zurück, die Folgendes enthält:
- Alle festgestellten Barrierefreiheitsverletzungen
- Schweregrad der Verstöße (kritisch, ernst, moderat, geringfügig)
- Spezifische Elementselektoren und Quellcode
- Regel-IDs und Beschreibungen
Das remediate Tool
Das remediate Tool nimmt eines oder mehrere Barrierefreiheitsprobleme, die vom analyze oder igt Tool identifiziert wurden, und generiert kontextbezogene, KI-gestützte Lösungsempfehlungen, die von Codierungsagenten in tatsächliche Code-Fixes übersetzt werden können. Probleme werden als Batch übermittelt, sodass ein einziger Aufruf Korrekturen für alle auf einer Seite gefundenen Verstöße zurückgeben kann.
Was es macht
- Authentifizierung - Validiert die Anmeldeinformationen des Benutzers – entweder einen API-Schlüssel oder ein OAuth 2.0-Access-Token –, um autorisierten Zugriff sicherzustellen
- AI-Guthaben Verbrauch - Jedes Problem im Batch verbraucht KI-Credits aus der Zuteilung Ihrer Organisation, was den Einsatz fortschrittlicher KI-Modelle ermöglicht, die auf Deques umfangreichem Barrierefreiheitswissen trainiert sind
- KI-erzeugte Behebung - Erstellen qualitativ hochwertige, umsetzbare Barrierefreiheitskorrekturen, die von Codierungsagenten interpretiert und im Quellcode umgesetzt werden können
Wenn die AI-Credits aufgebraucht sind, funktioniert das remediate Tool nicht mehr, bis Ihre Credits wieder aufgeladen sind (entweder durch Zukauf oder durch Rücksetzung Ihres monatlichen Zyklus). Jedoch wird das analyze Tool weiterhin funktionieren.
Batch-Behebung
Das Tool akzeptiert ein issues Array. Übermitteln Sie alle Probleme eines einzigen analyze oder igt Durchlaufs gemeinsam in einem Aufruf, anstatt das Tool einmal pro Problem aufzurufen – ein Batch unterstützt zwischen 1 und 25 Probleme.
Jedes Problem hat die folgenden Felder:
| Feld | Erforderlich | Beschreibung |
|---|---|---|
id |
Ja | Eine vom Anrufer gewählte Kennung, die innerhalb des Batchs einzigartig ist (z. B. die Regel-ID plus ein Zähler: color-contrast-0). Dient nur dazu, jedes Ergebnis mit seinem Eingang zu korrelieren. |
rule |
Ja | Die axe Regel-ID aus dem analyze/igt Ausgabe (z. B. color-contrast, image-alt). |
elementHtml |
Ja | Das HTML-Snippet des verletzenden Elements. |
remediation |
Ja | Eine Beschreibung dessen, was falsch ist und was behoben werden muss, aus der Zusammenfassung des Problems (wahlweise angereichert mit dessen Beschreibung, Hilfetext oder KI-Begründung). |
pageUrl |
Nein | Die URL der Seite, die behoben wird, aus dem analyze Antwort. |
Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf – er erstellt das Batch aus den Analyseergebnissen:
Analyze http://localhost:3000 and remediate every issue foundDer Agent löst die Eingabeaufforderung auf und ruft das remediate Werkzeug mit einer Nutzlast auf, die ungefähr wie folgt aussieht:
{
"issues": [
{
"id": "color-contrast-0",
"rule": "color-contrast",
"elementHtml": "<span style=\"color: #aaa\">Sign up</span>",
"remediation": "Increase the contrast ratio to at least 4.5:1",
"pageUrl": "http://localhost:3000"
},
{
"id": "image-alt-1",
"rule": "image-alt",
"elementHtml": "<img src=\"logo.png\">",
"remediation": "Add alt text describing the image"
}
]
}Ausgabe
Das Tool gibt ein Array von ergebnisspezifischen Resultaten zurück, die jeweils über idmit ihrem Input verknüpft sind. Ein Resultat hat eine von zwei Formen:
- Erfolg —
status: "ok", mit einemremediationObjekt, das eine allgemeine Beschreibung, die Behebungsschritte und einen konkreten Code-Fix enthält - Fehler —
status: "error", mit einemerrorObjekt (codeundmessage) für ein Problem, das nicht behoben werden konnte
{
"data": [
{
"id": "color-contrast-0",
"status": "ok",
"remediation": {
"general_description": "...",
"remediation": "...",
"code_fix": "<span style=\"color: #595959\">Sign up</span>"
}
},
{
"id": "image-alt-1",
"status": "error",
"error": { "code": "LLM_ERROR", "message": "..." }
}
]
}Ergebnisse sind unabhängig: Ein Fehler bei einem Problem blockiert keine Hinweise für die anderen.
Credit-Nutzung
Das remediate Tool ist Teil des AI-Credit-Management-Systems. Jedes Problem in einem Batch verbraucht Credits aus dem monatlichen Kontingent Ihrer Organisation. Administratoren können den Credit-Verbrauch über das axe-Konto-Portal überwachen.
Das igt Tool
Das igt Tool führt Deques Automatisierte Intelligente Geführte Tests (IGTs) gegen eine Webseite aus Ihrer IDE aus. Während die axe DevTools Browser-Erweiterung einen Entwickler normalerweise mit manuellen Eingabeaufforderungen durch ein IGT führt, igt führt das Tool den Test automatisch aus und liefert strukturierte Ergebnisse, auf die ein Coding-Agent reagieren kann.
Derzeit unterstützt das Tool das Tastatur-IGT, das bewertet, ob die interaktiven Elemente auf einer Seite ausschließlich mit der Tastatur erreicht und bedient werden können.
Was es macht
- Authentifizierung - Validiert die Benutzeranmeldedaten—entweder einen API-Schlüssel oder ein OAuth 2.0 Zugriffstoken—, um autorisierten Zugang sicherzustellen
- Browser-basierter Lauf - Tests im selben Chromium-Instanz mit der eingebauten axe DevTools-Erweiterung, die das
analyzeTool verwendet - Seitennavigation - Navigiert zur vom Benutzer im Prompt an den KI-Agenten bereitgestellten URL
- Automatisiertes Tastatur-IGT - Durchgeht die Seite per Tabulator, während KI jeden Tabstopp analysiert, um die Fokusreihenfolge und Tastaturoperabilität zu bewerten—kein manuelles Eingreifen erforderlich
- Ergebnisauslieferung - Gibt strukturierte Befunde an den Agenten zurück
Verbrauch
Das Tool akzeptiert ein url und ein igtTools Array, das angibt, welche IGTs ausgeführt werden sollen. Derzeit ist das Tastatur-IGT der einzige unterstützte Wert:
{
"url": "http://localhost:3000",
"igtTools": ["keyboard"]
}Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf—der Agent übersetzt Ihre Absicht in den Tool-Aufruf:
Run the keyboard IGT on http://localhost:3000Browser-Interaktionen vor dem Testen
Wie das analyze Tool, igt akzeptiert ein optionales before Array von Interaktionsschritten, die nach dem Laden der Seite aber bevor der geführte Test ausgelöst wird. Dies erlaubt es Ihnen, einen geführten Test gegen seiten mit Login-Schranken durchzuführen, Cookie-Banner zu entfernen oder zu warten, bis dynamische Inhalte zuerst erscheinen.
Die Schritte laufen in derselben gleichen Browserkontext wie der Test (sodass Cookies, localStorageund Routenänderungen bestehen bleiben), verwenden die gleichen click, fillund waitFor Aktionen und sind gleichzeitig auf das gleiche Limitiert 20 Schritte. Siehe Unterstützte Aktionen unter dem analyze Tool für die vollständige Referenz, einschließlich der Behandlung sensibler Werte von fill.value und der Selektor-Regeln.
{
"url": "http://localhost:3000",
"igtTools": ["keyboard"],
"before": [
{ "action": "fill", "selector": "#username", "value": "<resolved-from-.env.local>" },
{ "action": "click", "selector": "button[type=submit]" },
{ "action": "waitFor", "selector": "#main-content" }
]
}Ausgabe
Das Tool gibt eine strukturierte JSON-Antwort zurück:
{
"pageUrl": "http://localhost:3000",
"data": {
"keyboard": {
"issues": [],
"unanalyzedElements": [],
"terminatedReason": "keyboard-trap"
}
}
}issues- Während des Laufs gefundene Verstöße gegen die TastaturzugänglichkeitunanalyzedElements- Tabstopps, die die KI nicht analysieren konnte. Diese werden separat vonissuesgemeldet, sodass sie manuell überprüft werden können, anstatt fälschlicherweise als bestanden oder durchgefallen eingestuft zu werden.terminatedReason- Präsentieren nur wenn der Lauf abgebrochen wurde, bevor jeder Tabstopp analysiert wurde. Der aktuelle Wert ist"keyboard-trap", was bedeutet, dass der Test auf eine Keyboard-Falle gestoßen ist, aus der er nicht entkommen konnte; die verbleibenden Schritte werden abgebrochen und die bis zu diesem Zeitpunkt analysierten Tabstopps werden inissues.
Credit-Nutzung
Das igt Tool ist ein KI-gestütztes Feature und Teil der AI-Credit-Management-Systems. Jeder Lauf verbraucht KI-Guthaben aus dem monatlichen Kontingent Ihrer Organisation. Administratoren können die Kreditnutzung über das axe-Konto-Portal überwachen.
Wenn die AI-Credits aufgebraucht sind, funktioniert das igt Tool nicht mehr, bis Ihre Credits wieder aufgeladen sind (entweder durch Zukauf oder durch Rücksetzung Ihres monatlichen Zyklus). Jedoch wird das analyze Tool weiterhin funktionieren.
Erste Schritte
Die Einrichtung des axe MCP Servers umfasst drei unabhängige Entscheidungen:
- Wählen Sie eine Distribution — Docker oder npm
- Richten Sie die Authentifizierung ein — einen API-Schlüssel oder OAuth 2.0
- Konfigurieren Sie Ihren Client — VS Code mit Copilot, Cursoroder **Claude Code**
Für Umgebungsvariablen und empfohlene Anweisungen für den KI-Agenten siehe die Konfigurationsreferenz. Wenn etwas schiefgeht, siehe Fehlerbehebung.
Beispielaufforderungen
Sicherstellen, dass die erwarteten Werkzeuge aufgerufen werden
In vielen IDEs wird durch die Verwendung der folgenden Syntax (Präfix „#“) sichergestellt, dass die Werkzeuge des axe MCP Servers wie erwartet aufgerufen werden:
#analyze the http://localhost:3033/ web page for accessibility issues and #remediate any violations foundEine localhost-URL auf Barrierefreiheitsprobleme analysieren:
Analyze http://localhost:3000 for accessibility issuesAnalyse mit Behebung:
Analyze https://example.com for accessibility issues and fix any issues foundEine Seite hinter einer Login-Schranke analysieren:
Analyze http://localhost:3000 for accessibility issues. Before running the
analysis, fill in the #username and #password fields with USERNAME and
PASSWORD from ./.env.local, click the button[type=submit] button, and
wait for #main-content to appear.Ein Cookie-Banner vor dem Scannen schließen:
Analyze https://example.com for accessibility issues, but first click the
#cookie-dismiss button to dismiss the cookie consent banner.Support
Für Fragen, Probleme oder Feedback bezüglich des axe MCP Servers:
- Technischer Support: helpdesk@deque.com
- Allgemeine Anfragen: helpdesk@deque.com
- Vertriebsfragen: sales@deque.com
Sicherheit & Datenschutz FAQ
Erfasst oder speichert axe MCP Server unseren Quellcode?
Nein. Der MCP-Server von Axe erfasst oder speichert Ihren Quellcode in keiner Datenbank oder permanentem Speicher.
Wenn das analyze Tool ausgeführt wird, enthält die Antwort den HTML-Quellcode der Elemente mit Barrierefreiheitsproblemen zu Kontext- und Debugging-Zwecken. Diese Daten jedoch:
- Werden nur in der unmittelbaren API-Antwort an Ihr KI-Agent zurückgegeben
- Werden nie in von Deque verwalteten Datenbanken gespeichert
- Bleiben innerhalb Ihrer lokalen Entwicklungsumgebung
- Werden nach Abschluss der Analyse verworfen
Wie lange bleiben MCP-Testergebnisse in der von Deque verwalteten Infrastruktur?
Tun sie nicht. MCP-Testergebnisse werden in keiner von Deque verwalteten Datenbank oder Speichersystem gespeichert.
Das analyze Tools:
- Läuft vollständig auf Ihrem Rechner — in einem Docker-Container oder als lokaler Node.js-Prozess mit der npm-Distribution
- Gibt die Ergebnisse direkt an Ihr KI-Agent zurück
- Sendet keine Analyseergebnisse an Deque-Server
Die einzige Ausnahme ist, wenn Sie das remediate Tool aufrufen, das minimale Metadaten von Verstößen (siehe unten) umfassen kann, um KI-gestützte Korrekturanleitungen zu erstellen.
Welche Daten werden an Deque-Server gesendet?
Nur bei Verwendung des remediate Tools:
Die folgenden Daten werden an den KI-Remediation-Endpunkt von Deque gesendet, um Korrekturanleitungen zu erstellen:
- Regel-ID - Die spezifische Barrierefreiheitsregel, die verletzt wurde
- Element-HTML - Das HTML-Markup des oder der betroffenen Elemente
- Metadaten zu Problemen - Beschreibung der Verstöße und Leitfaden zur Abhilfe von axe-core
Diese Daten werden ausschließlich zur Erstellung von Korrekturanleitungen verwendet und nicht langfristig in Deque-Datenbanken gespeichert.
Das analyze Tool sendet keine Daten an Deque-Server über Authentifizierungsanforderungen hinaus (Gültigkeitsprüfung Ihres API-Schlüssels oder OAuth 2.0-Zugriffstokens).
Welches Zugriffslevel benötigt das KI-Agent, um zu funktionieren?
Das KI-Agent (Claude, Copilot, Cursor usw.) benötigt Zugriff auf:
-
MCP-Server-Kommunikation - Das Agent muss in der Lage sein, die Tools des MCP-Servers über das Model Context Protocol aufzurufen
-
Tool-Antwortdaten - Das Agent erhält:
- Daten zu Barrierefreiheitsverstößen von
analyzeAufrufen - Leitlinien zur Abhilfe von
remediateAufrufen - Diese Daten sind für das Agent erforderlich, um Probleme zu verstehen und Codekorrekturen zu generieren
- Daten zu Barrierefreiheitsverstößen von
-
Ihr Codebase (optional) - Wenn Sie möchten, dass das Agent automatisch Codekorrekturen vornimmt, benötigt es Zugriff auf Ihre Quellcodedateien
- Dies ist Standard für KI-Coding-Assistenten in IDEs (VS Code, Cursor usw.)
- Nicht erforderlich, wenn Sie die Tools nur zur Analyse und Anleitung verwenden (z.B. über die Claude Desktop-App)
Der MCP-Server selbst benötigt Zugriff auf:
- Von Ihnen zum Testen angegebene URLs (unterstützt sowohl lokal als auch remote)
- Ihre axe-Anmeldedaten: entweder ein API-Schlüssel (generiert im axe-Kontoportal) oder ein OAuth 2.0-Zugriffstoken (erhalten über
@deque/axe-auth); bereitgestellt über Umgebungsvariable
Wichtig: Der MCP-Server läuft lokal auf Ihrem Rechner — in einem Docker-Container oder als Node.js-Prozess mit der npm-Distribution. Er erfordert keinen umfassenden Dateisystemzugriff oder erhöhte Privilegien.
Best Practices
- Anmeldedatensicherheit - Speichern Sie Ihren
AXE_API_KEYoderAXE_ACCESS_TOKENals Umgebungsvariable, nicht im Code. Mit OAuth 2.0@deque/axe-authspeichert es Tokens in Ihrem OS-Schlüsselbund und injiziert bei jedem Start ein neues Zugriffstoken, sodass kein langzeitiger Geheimcode in Ihrer Konfiguration vorhanden sein muss - Lokale Tests - Testen Sie lokale Entwicklungs-URLs (localhost) oder Staging, um sensiblen Vorproduktion-Code isoliert zu halten
- Netzwerkisolation - Der MCP-Server kommuniziert nur mit:
- URLs, die Sie ausdrücklich zur Analyse anfordern
- Deque-Server für Authentifizierung (API-Schlüssel- oder OAuth 2.0-Token-Validierung) und Behebung (bei Aufruf)
- Ihrem lokalen AI-Agenten über das MCP-Protokoll
- Überprüfen vor der Anwendung - Überprüfen Sie immer von KI-generierte Codeänderungen, bevor Sie sie in Ihr Code-Repository übernehmen
