bugAgent

Verbinde bug Agent mit jedem MCP-kompatiblen KI-Client.

Erfasse, klassifiziere und verwalte Bugs, Feature-Anfragen und mehr direkt über deinen KI-Coding-Assistenten. Kein Kontextwechsel, kein Kopieren und Einfügen – beschreibe einfach das Problem, und bug Agent erledigt den Rest.

Externe MCP-Clients sind unabhängig vom Dashboard-KI-Assistenten von bug Agent. Der Dashboard-Assistent ist in allen Tarifen standardmäßig deaktiviert und muss für den Workspace ausdrücklich aktiviert werden; sein ai_assistant-Gate deaktiviert weder MCP noch Integrationen. MCP-Authentifizierung, Berechtigungen, Workspace-/Projektberechtigungen und tool-spezifische Berechtigungen gelten weiterhin.

Erste Schritte

bug Agent betreibt den gehosteten MCP-Server, damit KI-Clients über das Model Context Protocol Bug-Berichte, Feature-Anfragen, Erweiterungen und mehr erstellen, abfragen und verwalten können. Clients verbinden sich direkt mit dem gehosteten Streamable-HTTP-Endpunkt.

API-Schlüssel abrufen

Erstelle ein kostenloses Konto; neue Workspace-Inhaber werden direkt zur Einrichtung des API-Schlüssels weitergeleitet. Wiederkehrende Benutzer können unter Einstellungen → Entwickler → API-Schlüssel einen Schlüssel erstellen.

KI-Client konfigurieren

Füge bug Agent als MCP-Server zur Konfiguration deines Clients hinzu (siehe Einrichtung unten).

Bugs erfassen

Beschreibe einen Bug in natürlicher Sprache, und bug Agent klassifiziert, ergänzt und speichert ihn automatisch.

# Create a bug report
"File a bug: Login button is unresponsive on iOS Safari.
Steps: tap login, nothing happens. Expected: navigate to
dashboard. Severity: high."

# bugAgent auto-classifies as UI bug, severity high

# File a feature request
"Feature request: Add dark mode toggle to the
settings page. Users have asked for this in surveys."

# Auto-classified as feature-request, severity medium

Einrichtung

Plugin für gezielte Bug-Erfassung

Sieh dir den öffentlichen Plugin-Quellcode und die Einrichtungs-Checkliste an. Dies ist eine Vorschau des Quellcodes; die gehostete OAuth-Verifizierung und die Veröffentlichung im OpenAI-Verzeichnis stehen noch aus.

Der fokussierte Endpunkt https://mcp.bugagent.com/mcp/capture bietet nur capture_get_profile, capture_list_projects, capture_search_reports, capture_get_report und capture_create_report. Er stellt keine Verwaltungsfunktionen, Löschvorgänge, Kommentare oder Testausführungen bereit. Die Verfügbarkeit im OpenAI-Verzeichnis hängt von einer separaten Prüfung und Veröffentlichung ab.

Stelle die Verbindung über OAuth her. Capture-Berechtigungen sind an diesen Endpunkt gebunden und können nicht für den vollständigen Endpunkt /mcp verwendet werden. Lesezugriffe erfordern bugs:read; zum Erstellen ist bugs:write erforderlich. Workspace-API-Schlüssel werden weiterhin mit reports:read und reports:write unterstützt und sind auf ihren Workspace beschränkt.

Wähle zuerst einen autorisierten Workspace und ein Projekt aus. Suchvorgänge und das Lesen von Berichten erfordern ausdrücklich workspace_id und project_id; Ergebnisse sind begrenzt und paginiert. Suchergebnisse sind mögliche Treffer und keine Garantie dafür, dass kein Duplikat existiert.

Prüfe vor dem Erstellen Ziel, Titel, Beschreibung, Typ und Schweregrad. Sende approved: true und eine stabile UUID request_id zusammen mit dieser genehmigten Nutzlast. Verwende dieselbe Anfrage-ID nur für einen identischen Wiederholungsversuch; eine geänderte Nutzlast wird abgelehnt. Bestehende Tariflimits und die konfigurierte Jira-Weiterleitung gelten weiterhin.

Die Bildinterpretation kann beim Verfassen eines Entwurfs helfen, aber dieser Endpunkt lädt keine Anhänge hoch. Öffne das erstellte Ticket, um vertrauliche Nachweise anzuhängen. Füge niemals Passwörter, Tokens oder andere Geheimnisse in die Unterhaltung ein.

Empfohlen: gehostetes Streamable HTTP

Stelle direkt eine Verbindung zu https://mcp.bugagent.com/mcp her. Du musst nichts installieren oder lokal ausführen. Füge deinen Workspace-API-Schlüssel als Bearer-Token hinzu:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

💡

Ersetze ba_live_YOUR_KEY_HERE durch deinen tatsächlichen API-Schlüssel aus Einstellungen → Entwickler.

Optional: stdio-Bridge

Verwende die veröffentlichte Bridge nur, wenn ein Client stdio erfordert und keine Verbindung zu einem entfernten HTTP-Server herstellen kann. Führe sie bei Bedarf mit npx -y bugagent-mcp aus:

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "bugagent-mcp"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Mit dem Server verbinden

Tippe im Dashboard auf Touch-Geräten einmal auf eine Seitenleistenbeschriftung, um zu navigieren. Optionen und Wiederherstellen sind separate Steuerelemente, die auch per Tastatur erreichbar sind. Die Sichtbarkeit der Seitenleiste gewährt oder entzieht keine MCP-Berechtigungen.

Der MCP-Server von bug Agent ist unter https://mcp.bugagent.com/mcp über den Streamable-HTTP-Transport verfügbar. Verbinde dich mit einem der acht unten aufgeführten Clients – wähle den passenden für deinen Arbeitsablauf.

Eine kompakte, direkt kopierbare Konfiguration, Hinweise zu eingeschränkten Schlüsseln und sichere Starter-Prompts findest du im öffentlichen MCP-Schnellstart.

🔑

Rufe zuerst deinen API-Schlüssel ab. Melde dich unter Einstellungen → Entwickler an, klicke auf API-Schlüssel erstellen, wähle die benötigten Berechtigungen für deinen Client aus und kopiere den Wert (beginnt mit ba_live_). Du kannst ihn nur einmal sehen, also füge ihn an einem sicheren Ort ein. MCP-Clients zeigen nur Tools an, die durch diese Berechtigungen freigegeben sind. Die folgenden Verbindungsbeispiele verwenden diesen Schlüssel; Prompts, die eine interaktive OAuth-/Sitzungsauthentifizierung oder eine Berechtigung für einen kostenpflichtigen Tarif erfordern, sind separat gekennzeichnet.

Option 1 — MCP Inspector (Web-UI, für erste Tests empfohlen)

Das offizielle Anthropic-Tool. Startet eine lokale Web-UI, in der du alle Tools durchgehen, Parameter eingeben und Antworten ansehen kannst. Keine Konfiguration, keine IDE erforderlich.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell oder CMD)

npx @modelcontextprotocol/inspector

In der geöffneten Browser-UI:

1. Transport Type: Wähle Streamable HTTP
2. URL: https://mcp.bugagent.com/mcp
3. Connection Type: Wähle Proxy (Standard – der Inspector leitet die Verbindung über einen lokalen Node-Prozess weiter, um die Browser-CORS-Beschränkung zu umgehen)
4. Öffne Server Settings → Custom Headers und füge Folgendes hinzu:
   • Header Name: X-Api-Key
     • Value: ba_live_YOUR_KEY_HERE (ohne Präfix Bearer)
5. Klicke auf Connect. Im linken Bereich werden die bug Agent-Tools angezeigt, die durch die ausgewählten API-Schlüsselberechtigungen freigegeben sind.
6. Klicke auf ein beliebiges Tool (z. B. list_bug_reports), gib die Parameter ein und klicke auf Run Tool. Die Antwort wird rechts angezeigt.

Voraussetzungen: MCP Inspector v2 erfordert Node.js 22.19 oder höher. Installiere eine aktuelle Node.js-Version von nodejs.org, falls noch nicht vorhanden.

Wenn Inspector invalid_client zurückgibt, versucht er, eine gespeicherte OAuth-Verbindung statt der API-Schlüsselauthentifizierung zu verwenden. Entferne den gespeicherten Server (oder lösche seinen gespeicherten OAuth-Status), füge ihn erneut hinzu und verwende den obigen benutzerdefinierten Header X-Api-Key. Trage keinen ba_live_-Schlüssel in ein OAuth-Feld client_id ein.

Option 2 — Claude Desktop (Mac + Windows)

Wenn du die Claude-Desktop-App verwendest, kannst du bug Agent als permanenten MCP-Server hinzufügen. Mit einem Workspace-API-Schlüssel erhält Claude nur die Tools, die durch die Berechtigungen dieses Schlüssels freigegeben sind. Delegiertes OAuth stellt den vollständigen interaktiven Katalog bereit.

macOS

1. Öffne Claude Desktop → Menüleiste Claude → Settings → Developer → Edit Config. Dadurch wird ~/Library/Application Support/Claude/claude_desktop_config.json geöffnet.
2. Füge den bug Agent-Eintrag unter mcpServers hinzu:

   {
     "mcpServers": {
       "bugagent": {
         "type": "http",
         "url": "https://mcp.bugagent.com/mcp",
         "headers": {
           "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
         }
       }
     }
   }
   

3. Speichere die Datei und beende Claude Desktop vollständig (Cmd+Q, nicht nur das Fenster schließen).
4. Starte Claude Desktop erneut. Das Werkzeugsymbol mit dem Hammer unten im Chat-Eingabefeld sollte nun die bug Agent-Tools anzeigen.
5. Probiere es aus: Gib „Liste meine 5 neuesten Bug-Berichte auf“ ein – Claude ruft list_bug_reports automatisch auf.

Windows

1. Öffne Claude Desktop → File → Settings → Developer → Edit Config. Dadurch wird %APPDATA%\Claude\claude_desktop_config.json geöffnet (normalerweise C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
2. Füge denselben JSON-Block wie im macOS-Abschnitt hinzu.
3. Speichere die Datei und beende Claude Desktop vollständig über die Taskleiste (Rechtsklick auf das Claude-Symbol → Quit), starte die App anschließend erneut.
4. Das Werkzeugsymbol mit dem Hammer zeigt die bug Agent-Tools an.

Option 3 — Claude Code (CLI)

Wenn du Claude Code im Terminal verwendest (die CLI-Version von Claude), registriere den bug Agent-Server mit einem Befehl. Funktioniert unter macOS, Linux und Windows identisch.

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp \
  --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Starte anschließend deine Claude-Code-Sitzung neu. Überprüfe die Verbindung:

claude mcp list

In der Liste sollte bugagent mit einem grünen Punkt angezeigt werden. Beginne mit einem Prompt, der mit einem API-Schlüssel funktioniert: „Liste meine 5 neuesten offenen Bug-Berichte auf.“

Verbunden, aber einige Tools fehlen?

Prüfe die Tool-Anzahl des Servers unter /mcp, nicht nur die Tools, die bereits in der Unterhaltung geladen wurden. Claude Code kann Tools bei Bedarf über die Tool-Suche entdecken. Bitte es, bugAgent nach list_test_cases, list_test_suites oder get_test_run_plan zu durchsuchen. Siehe die Dokumentation zur Tool-Suche in Claude Code.

Der Katalog wird anhand der API-Schlüsselberechtigungen gefiltert. Zum Lesen von Testfällen ist test_cases:read erforderlich; zum Lesen von Suites/Ausführungen ist test_runs:read erforderlich. Fordere nur die Schreibberechtigungen an, die du tatsächlich benötigst. Vergleiche das authentifizierte tools/list mit demselben Endpunkt und Schlüssel wie bei deinem Client; eine anonyme Erkennung oder ein anderer Schlüssel ist kein gültiger Vergleich. Prüfe, ob eine Konfiguration auf Projektebene deine Verbindung auf Benutzerebene überschreibt, und stelle nach Änderungen an den Anmeldedaten die Verbindung erneut her oder starte den Client neu.

Wenn der authentifizierte Serverkatalog ein Tool enthält, der Client es aber weiterhin nicht entdecken kann, notiere Client-Version, Server-Version, Tool-Namen/-Anzahl und etwaige Schemafehler. Entferne dabei Anmeldedaten und Kundendaten. Eine mit ENABLE_TOOL_SEARCH=false claude gestartete Sitzung kann zwischen verzögerter Erkennung und Ladeproblemen unterscheiden, lädt jedoch alle Tool-Definitionen und verbraucht mehr Kontext. Verwende sie nur vorübergehend zur Diagnose. Erweitere Berechtigungen nicht und teile Endpunkte nicht auf, nur um die Tool-Anzahl zu erhöhen.

So entfernst du den Server später:

claude mcp remove bugagent

Option 4 — OpenAI Codex CLI

Wenn du die OpenAI Codex CLI verwendest, exportiere deinen API-Schlüssel und füge bug Agent zu ~/.codex/config.toml hinzu.

Dauerhafte Registrierung (zur Konfiguration hinzufügen)

[mcp_servers.bugagent]
url = "https://mcp.bugagent.com/mcp"
bearer_token_env_var = "BUGAGENT_API_KEY"

API-Schlüssel festlegen

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Starte Codex in dieser Umgebung oder starte es neu. Codex löst Tool-Aufrufe automatisch anhand deines Prompts in natürlicher Sprache auf. Probiere es aus: „Liste meine offenen Bugs nach Schweregrad sortiert auf.“

Option 5 — Cursor (Mac + Windows)

Cursor bietet integrierte MCP-Unterstützung. Mit einem passend eingeschränkten Workspace-API-Schlüssel kann der KI-Assistent in Cursor Bugs erfassen, Berichte auflisten und unterstützte Automatisierungsabläufe ausführen, ohne den Editor zu verlassen. Sicherheits-, Leistungs- und explorative Scans erfordern delegiertes OAuth und den entsprechenden Tarifzugriff.

1. Öffne Cursor → Settings (Cmd+, auf dem Mac / Ctrl+, unter Windows) → MCP in der linken Seitenleiste.
2. Klicke auf + Add new MCP server.
3. Wähle den Transporttyp HTTP.
4. Gib Folgendes ein:
   • Name: bugagent
     • URL: https://mcp.bugagent.com/mcp
     • Header name: Authorization
     • Header value: Bearer ba_live_YOUR_KEY_HERE
5. Klicke auf Save. Cursor zeigt bei bestehender Verbindung eine grüne Anzeige.
6. Öffne den Cursor-Chat (Cmd+L / Ctrl+L) und gib „Erstelle einen Bug-Bericht mit dem Titel ‚Anmeldung funktioniert nicht‘ und dem Schweregrad ‚hoch‘.“ ein. Cursor ruft create_bug_report auf.

Alternative: Cursor liest auch ~/.cursor/mcp.json (Mac) oder %USERPROFILE%\.cursor\mcp.json (Windows). Füge dasselbe JSON-Format wie im Abschnitt zu Claude Desktop hinzu.

Option 6 — VS Code mit der Continue-Erweiterung (Mac + Windows)

Wenn du VS Code bevorzugst, unterstützt die Continue-Erweiterung MCP-Server nativ.

1. Installiere die Erweiterung Continue über den VS-Code-Marktplatz.
2. Öffne die Continue-Konfiguration: Befehlspalette (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Open config.json. Die Datei befindet sich unter:
   • macOS: ~/.continue/config.json
     • Windows: %USERPROFILE%\.continue\config.json
3. Füge einen Eintrag mcpServers hinzu:

   {
     "mcpServers": [
       {
         "name": "bugagent",
         "type": "streamable-http",
         "url": "https://mcp.bugagent.com/mcp",
         "requestOptions": {
           "headers": {
             "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
           }
         }
       }
     ]
   }
   

4. Speichere die Datei. Continue lädt automatisch neu und zeigt die bug Agent-Tools in der Seitenleiste an.
5. Öffne das Continue-Chatfenster und probiere Folgendes aus: „Liste meine 5 neuesten offenen Bug-Berichte auf.“

Weitere MCP-fähige VS-Code-Erweiterungen: Cline, Roo Code und Windsurf (Fork) verwenden ähnliche JSON-Konfigurationsmuster mit einem Schlüssel mcpServers und HTTP-Transport.

Option 7 — OAuth-fähige Hosts (Claude.ai Web als Beispiel)

Einige MCP-Hosts authentifizieren sich über OAuth 2.0 und verlangen vorab ein statisches client_id und client_secret, statt einen Bearer-API-Schlüssel zu akzeptieren. Erstelle im bug Agent-Dashboard ein Connector-Anmeldedatenpaar und füge es in das Connector-Formular des Hosts ein. Das Paar identifiziert den MCP-Client; nach der Zustimmung werden Tools im Namen des angemeldeten Benutzers und dessen aktivem bug Agent-Workspace ausgeführt. Die folgende Anleitung verwendet die Claude.ai-Web-App als häufigstes Beispiel.

i

An eine Ressource gebundenes OAuth. Die Kennung der geschützten Ressource lautet https://mcp.bugagent.com/mcp. Standardskonforme Hosts ermitteln sie über /.well-known/oauth-protected-resource/mcp und senden sie als RFC-8707-Parameter resource. bug Agent stellt undurchsichtige Tokens aus, die an diese Ressource, den OAuth-Client, den angemeldeten Benutzer und die erteilten Berechtigungen gebunden sind. Ein Token kann weder bei einem anderen Dienst wiederverwendet noch von einem anderen Client eingelöst werden.

1. Öffnen Sie in bug Agent Settings → Developers → MCP Connectors. Klicken Sie auf Generate connector, geben Sie einen Namen ein, der den Host beschreibt (z. B. „Claude.ai (work)”), fügen Sie die vom MCP-Host benötigte Redirect-URI ein (für die Claude.ai-Web-App ist das https://claude.ai/api/mcp/auth_callback — weitere finden Sie in der Connector-Dokumentation Ihres Hosts) und wählen Sie als Authentifizierungsmethode Confidential. Kopieren Sie die client_id und client_secret, die einmalig auf der Erfolgsseite angezeigt werden.
2. Fügen Sie in den Connector-/OAuth-Einstellungen Ihres MCP-Hosts Folgendes ein:
   • Server-URL: https://mcp.bugagent.com/mcp
     • Client-ID + Client-Secret: aus Schritt 1
     • Autorisierungs-URL: https://mcp.bugagent.com/authorize
     • Token-URL: https://mcp.bugagent.com/token
     • Geschützte Ressource / Zielgruppe, falls angefordert: https://mcp.bugagent.com/mcp Für Claude.ai: Rufen Sie claude.ai/customize/connectors auf und klicken Sie auf Add MCP connector.
3. Speichern Sie die Einstellungen. Der Host leitet Sie zu bug Agent weiter, damit Sie sich anmelden (mit Google oder E-Mail/Passwort — je nachdem, welche Methode Sie für das Dashboard verwenden) und die Einwilligung bestätigen können. Anschließend wird der OAuth-Handshake abgeschlossen.
4. Verwalten Sie generierte Connectors auf derselben Settings-Seite. Nur der Ersteller kann einen Tenant-Connector widerrufen; Workspace-Administratoren erhalten keinen Zugriff, um die Registrierung eines anderen Mitglieds zu widerrufen. Nach bestätigtem Widerruf wird die Registrierung aus der aktiven Liste entfernt. Separate Registrierungen mit demselben Namen bleiben eigenständig: Vergleichen Sie ihre Client-IDs. Kann der Widerruf nicht bestätigt werden, zeigt die Seite einen Fehler statt einer Erfolgsmeldung an. Durch den Widerruf wird eine neue Connector-Authentifizierung verhindert. Zuvor ausgestellte Zugriffstokens können bis zu ihrem Ablauf gültig bleiben.

Hinweis: Claude Code, Cursor, VS Code und der MCP Inspector benötigen diesen Ablauf nicht — sie übernehmen die dynamische Client-Registrierung (RFC 7591) automatisch und authentifizieren sich wie oben gezeigt per API-Schlüssel. Das Formular MCP Connectors ist nur für Hosts vorgesehen, die statische OAuth-Anmeldedaten erfordern.

OAuth-Zugriffs- und Refresh-Werte werden nur dem Host angezeigt. Sie sind undurchsichtig, werden beim Refresh rotiert und von bug Agent nur als Einweg-Hashes gespeichert; die Refresh-Anmeldedaten der vorgelagerten Identität werden im Ruhezustand verschlüsselt. Kopieren Sie niemals ein OAuth-Token in eine REST-API-Anfrage oder auf einen anderen MCP-Server.

Option 8 — Direktes HTTP mit curl (Terminal)

Wenn Sie den Server direkt ohne Client testen oder in ein Skript integrieren möchten, können Sie mit curl den HTTP-Endpunkt aufrufen. Das MCP-Protokoll verwendet JSON-RPC 2.0 über Streamable HTTP.

macOS / Linux

# Set your API key as a variable
export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

# 1. Initialize the MCP connection
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl-example","version":"1.0.0"}}}'

# 2. List tools visible to this key
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# 3. Call a tool — list 5 reports from a specific project
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc":"2.0",
    "id":3,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

# Set your API key
$env:BUGAGENT_API_KEY = "ba_live_YOUR_KEY_HERE"

# Use Invoke-RestMethod (PowerShell's curl equivalent)
$headers = @{
  "Authorization" = "Bearer $env:BUGAGENT_API_KEY"
  "Content-Type" = "application/json"
  "Accept" = "application/json, text/event-stream"
}

# 1. Initialize
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"powershell-example","version":"1.0.0"}}}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 2. List tools visible to this key
$body = '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 3. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 3
  method = "tools/call"
  params = @{
    name = "list_bug_reports"
    arguments = @{ project = "bugagent"; limit = 5 }
  }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

Antworten können JSON oder Server-Sent Events sein. Jeder SSE-Chunk ist eine Zeile mit dem Präfix data:, gefolgt von einem JSON-Objekt. Standardskonforme Clients sollten Accept: application/json, text/event-stream senden; bug Agent normalisiert derzeit fehlende oder unvollständige Accept-Werte aus Kompatibilitätsgründen.

ℹ️

Fehlerbehebung bei 401 Unauthorized: Prüfen Sie, ob Ihr API-Schlüssel unter Settings → Developers widerrufen wurde. Schlüssel beginnen mit ba_live_. Wenn das Problem weiterhin besteht, generieren Sie den Schlüssel neu und versuchen Sie es erneut.

Zugriffsmodell und Least-Privilege-Scopes

Der vollständige OAuth-Katalog enthält 141 Tools. Ein Workspace-API-Schlüssel sieht nur Tools, die einem seiner ausgewählten Scopes zugeordnet sind. Bei einer nicht authentifizierten Erkundung werden möglicherweise Tool-Metadaten angezeigt, aber tools/call erfordert immer einen API-Schlüssel oder ein OAuth-Token.

Fehlerberichte lesen und Projekte auflösen reports:read

Fehlerberichte erstellen und aktualisieren reports:read, reports:write

Nutzungsmonitor usage:read

Jira-Synchronisierungsstatus prüfen jira:read

Jira-Berichte synchronisieren oder zusammenführen jira:write

Web-Automatisierungen erstellen automations:write

Web-Automatisierungen ausführen und Ausführungen lesen automations:run

Mobile Assets und Ausführungen überwachen mobile:read

Mobile Assets verwalten mobile:read, mobile:write

Mobile Automatisierung ausführen mobile:read, mobile:run

Testkatalog verwalten reports:read, test_cases:read, test_cases:write

Externer Testausführungs-Worker test_runs:read, test_runs:write

API-Schlüssel sind an den Workspace gebunden, in dem sie erstellt wurden. Tool-Eingaben können einen Aufruf auf ein autorisiertes Projekt beschränken, aber den Schlüssel nicht zu einem anderen Workspace wechseln. Lösen Sie Projekt-UUIDs mit list_projects auf und weisen Sie mehrdeutige Namen zurück.

Tool-Titel und Anmerkungen

Jedes von tools/list zurückgegebene Tool enthält einen verständlichen Titel sowie Hinweise zum Lesen und Schreiben. Fehlende Lesehinweise stammen aus einer ausdrücklich geprüften Liste, nicht aus Tool-Namenspräfixen oder API-Schlüssel-Scopes. Explizite Anmerkungen, einschließlich false, bleiben erhalten.

• readOnlyHint: true beschreibt ein Tool, das seine Umgebung nicht verändert.
• readOnlyHint: false mit destructiveHint: false beschreibt additive Schreibvorgänge, keine schreibgeschützte Operation.
• readOnlyHint: false mit destructiveHint: true beschreibt potenziell destruktive Schreibvorgänge. Nicht klassifizierte Tools verwenden diese konservativen Standardwerte. Der Hinweis auf destruktive Vorgänge ist nur bei Schreibvorgängen relevant.

login ist nicht schreibgeschützt: Im stdio-Modus speichert es Anmeldedaten. analyze_fix_area und check_config_drift sind potenziell destruktive Schreibvorgänge, da sie gespeicherte Analyseergebnisse oder Konfigurations-Baselines ersetzen.

Anmerkungen gewähren keinen Zugriff und ersetzen weder Authentifizierung noch Workspace-/Projektberechtigungen, API-Schlüssel-Scopes oder Berechtigungsprüfungen. Ob Bestätigungsaufforderungen angezeigt werden, hängt von der Berechtigungsrichtlinie des Clients und den Benutzereinstellungen ab; die Hinweise garantieren nicht, ob ein Aufruf eine Aufforderung auslöst.

Laden Sie für die programmatische Erkundung und Prüfung die generierte mcp-tool-index.json herunter. Sie erfasst alle 141 Laufzeit-Tools, den Zugriff über API-Schlüssel-Scopes oder ausschließlich OAuth, die Berechtigungsfamilie, Eingabenamen, den Ausgabeschema-Modus und explizit deklarierte MCP-Anmerkungen. Eine null-Anmerkung bedeutet, dass sie am Aufrufort nicht deklariert ist; verwenden Sie die Antwort tools/list des verbundenen Servers, um die effektiven Anmerkungen nach Anwendung der Standardwerte zu erhalten.

!

Nur über OAuth verfügbare Tools: Konto-, API-Schlüssel- und Teamverwaltung, Jira-Verbindungsverwaltung, andere Integrationen, Premium-Teststeuerungen, Notizen, Zeiterfassung und andere interaktive Vorgänge werden nicht durch das Hinzufügen von API-Schlüssel-Scopes freigeschaltet. Jira-Berichtsprüfungs-, Synchronisierungs- und Zusammenführungstools sind die eng begrenzte Ausnahme über jira:read und jira:write.

Ausprobieren — Prompts in natürlicher Sprache

Nach der Verbindung müssen Sie weder Tool-Namen noch Parameter kennen. Beschreiben Sie in natürlicher Sprache, was Sie möchten, und Ihr KI-Assistent ruft automatisch das passende bug Agent-Tool auf.

Prompts für Fehlerberichte, bereichsbezogenes Testmanagement, Playwright-Automatisierung, mobile Automatisierung und Nutzung stehen API-Schlüsseln mit den passenden Scopes zur Verfügung. Für Sicherheit, Performance, explorative Tests, Konto, Team, Notizen, Zeiterfassung und andere Einträge ohne benannten API-Schlüssel-Scope sind delegiertes OAuth und gegebenenfalls eine entsprechende Planberechtigung erforderlich.

Fehlerberichte

List my 5 most recent bug reports
Show all open critical bugs in the Auth project
Create a bug titled "Login broken on Safari" with severity s2
Update TEST-451 status to in-progress and assign it to me
Add a comment to TEST-451: "root cause confirmed — null check missing in auth middleware"
Show me everything filed this week, grouped by severity

Testmanagement

Create a test suite called "Smoke Tests" with cases for login, checkout, and account settings
Run the Regression suite and list all failures
Use Hermes to execute the curated "Checkout smoke" suite and report every result to bugAgent
Show failing test cases from the last 7 days
Which test cases have never been run in the past 90 days?
Get a pass-rate trend for this month vs last month

Sicherheit und Performance

Run a security scan on https://app.example.com
Get this month's security scan results — show only high and critical findings
Create a performance test for the landing page and check Lighthouse scores
What are the Core Web Vitals for our checkout flow?

Playwright-Automatisierung

Create a Playwright script that logs in and verifies the dashboard loads
Run the checkout automation on iPhone 15 Pro on a real device
Optimize the login automation script
Show runs for the checkout automation — any failures?
Schedule the smoke test suite to run every weekday at 6 AM UTC

Explorative KI

Run an exploratory AI session on https://app.example.com with 5 parallel agents
Get the latest exploration run results — list any bugs that were filed
What testing strategies did the agents use and which found the most issues?

Nutzung und Statistiken

Check my plan usage for this month
Show team bug stats for this week broken down by severity and type
List all team members and their roles
How many security scans do I have left this month?

Kurzübersicht

Einrichtungsreferenzen für alle acht Verbindungsoptionen. API-Schlüssel-Clients verbinden sich über Streamable HTTP mit https://mcp.bugagent.com/mcp und dem Header Authorization: Bearer ba_live_YOUR_KEY_HERE; OAuth-fähige Hosts verwenden im Dashboard generierte Connector-Anmeldedaten.

Claude Desktop — macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop — Windows %APPDATA%\Claude\claude_desktop_config.json

Claude Code (CLI) claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_..."

Codex CLI ~/.codex/config.toml

Cursor — macOS Settings → MCP UI oder ~/.cursor/mcp.json

Cursor — Windows %USERPROFILE%\.cursor\mcp.json

VS Code + Continue ~/.continue/config.json (macOS) / %USERPROFILE%\.continue\config.json (Windows)

OAuth-fähiger Host Settings → Developers → MCP Connectors — generieren Sie die client_id und client_secret des Hosts

Direktes HTTP (curl) curl / Invoke-RestMethod — fügen Sie Accept: application/json, text/event-stream hinzu

Fehlerbehebung

401 Unauthorized Schlüssel ist falsch, abgelaufen oder widerrufen. Prüfen Sie Settings → Developers — Schlüssel beginnen mit ba_live_. Generieren Sie bei Bedarf einen neuen Schlüssel.

Tools werden im Client nicht angezeigt API-Schlüssel-Clients listen nur Tools auf, die durch die ausgewählten Scopes des Schlüssels erlaubt sind. Prüfen Sie den Schlüssel unter Settings → Developers und beenden Sie den Client vollständig, bevor Sie ihn nach einer Konfigurationsänderung neu starten. In Claude Desktop verwenden Sie Cmd+Q (nicht nur das Fenster schließen). Prüfen Sie in Cursor unter Settings → MCP, ob ein grüner Punkt angezeigt wird.

Feld fehlt im Client Vergleichen Sie das Schema des Clients mit dem rohen tools/list desselben Endpunkts. Wenn sie voneinander abweichen, aktualisieren Sie den Tool-Katalog oder verbinden Sie ihn erneut und starten Sie einen neuen Chat. Besteht das Problem weiterhin, erfassen Sie den Endpunkt, die Client-Version und die rohe Antwort tools/list; ein veralteter Cache ist nur eine mögliche Ursache.

Accept header required Senden Sie Accept: application/json, text/event-stream für standardskonformes Streamable HTTP. bug Agent normalisiert derzeit fehlende oder unvollständige Werte, aber Integrationen sollten sich nicht auf dieses Kompatibilitätsverhalten verlassen.

Daten aus dem falschen Workspace Jeder API-Schlüssel ist auf einen Workspace beschränkt. Generieren Sie unter Settings → Developers einen neuen Schlüssel aus dem Workspace, den Sie abfragen möchten.

Tools werden angezeigt, aber Aufrufe schlagen unbemerkt fehl Prüfen Sie die Antwort auf isError: true und den zurückgegebenen Inhalt. Ein sichtbares Tool kann dennoch aufgrund von Plan, Rolle, Funktionsberechtigung, Projektmitgliedschaft, Eigentümerschaft oder ungültiger Eingabe abgelehnt werden. Prüfen Sie den Serverstatus erst, nachdem Sie den Tool-Fehler gelesen haben.

CORS-Fehler im MCP Inspector Wählen Sie in der Inspector-Benutzeroberfläche unter Connection Type Proxy (nicht Direct). Der Inspector leitet die Anfrage über einen lokalen Node-Prozess weiter, um Browser-CORS-Beschränkungen zu umgehen.

MCP Inspector v2 wird mit Code 5 beendet Inspector v2 gibt einen Exit-Code ungleich null zurück, wenn eine Tool-Antwort isError: true enthält. Lesen Sie die Antwortnachricht auf Plan-, Berechtigungs-, Eingabe- oder Laufzeitfehler; Inspector v1 konnte für dieselbe fehlgeschlagene Tool-Antwort den Exit-Code 0 zurückgeben.

Codex CLI — Tools werden nicht erkannt Prüfen Sie, ob ~/.codex/config.toml [mcp_servers.bugagent] verwendet, legen Sie bearer_token_env_var = "BUGAGENT_API_KEY" fest und exportieren Sie diese Variable, bevor Sie Codex starten. Prüfen Sie codex --version, wenn die Tools weiterhin nicht angezeigt werden.

MCP-Funktionen

Konversationssitzungen bleiben ein auf Workspace beschränkter Pilot. Zum Speichern eines in einer Sitzung erstellten Skripts ist die ausdrückliche Workbench-Genehmigung des Eigentümers über den nur für Sitzungen vorgesehenen Endpunkt zum Speichern von Skripten erforderlich. Es gibt kein MCP-Genehmigungstool: Einen Agenten um einen Skriptentwurf zu bitten, erstellt oder plant keine Automatisierung.

Das Behalten eines Cloud-Browser-Screenshots erstellt nur einen Entwurf für einen Befund über den Aufbewahrungsendpunkt für die Sitzung des Eigentümers. Eine Live-Aktualisierung ersetzt den ausgewählten Screenshot nicht; zum Speichern sind weiterhin der aktuelle Zugriff des Eigentümers, die ursprüngliche autorisierte Browser-Generation und eine verfügbare Quelle erforderlich. Der Eigentümer muss den Screenshot in der Workbench prüfen und genehmigen, bevor ein Fehlerbericht mit den privaten Nachweisen eingereicht wird. Es gibt kein MCP-Tool zum Aufbewahren von Frames oder Umgehen dieser Genehmigung.

Auch die Zustimmung zum Starten eines Browsers ist ausschließlich dem Dashboard-Eigentümer vorbehalten. API-Schlüssel, MCP-Tools und allgemeine Chat-Antworten können sie nicht erteilen. Die Genehmigung umfasst einen schreibgeschützten Browser und die private Screenshot-Erfassung, nicht jedoch Anmeldungen, Formularaktionen oder die Aufzeichnung von Besprechungen. Der Produktions-Cloud-Browser-Host wird durch diese Zustimmungssteuerungen nicht aktiviert.

Der vollständige interaktive/OAuth-Katalog enthält 141 Tools. Workspace-API-Schlüssel erkennen nur die Least-Privilege-Teilmenge, die durch ihre ausgewählten Scopes erlaubt ist; Konto-, API-Schlüsselverwaltungs-, Teamverwaltungs-, Premium-Test-, Notiz- und Zeiterfassungstools sind nur in interaktiven Sitzungen verfügbar, sofern ein Eintrag nicht ausdrücklich einen API-Schlüssel-Scope nennt.

🐛

Fehlerberichtverwaltung

Aktualisierungen von Fehlerberichten erfassen tatsächliche Vorher-/Nachher-Werte atomar, einschließlich Reproduktionsfeldern, internen Notizen und Tags. Unveränderte Werte und fehlgeschlagene Schreibvorgänge erzeugen keine Einträge im Feldverlauf. Das Änderungsprotokoll im Dashboard klappt reine Textunterschiede auf und blättert durch ältere Einträge. Der Anhangsverlauf speichert beschreibende Metadaten, aber keine signierten URLs oder gelöschten Dateien. Fehlende historische Werte werden nicht nachträglich ergänzt. Es wird weder ein MCP-Verlaufstool noch ein Protokoll für Konflikte bei Live-Bearbeitungen hinzugefügt; autorisierte Clients können den REST-Endpunkt für den Berichtsverlauf verwenden.

update_bug_report akzeptiert außerdem die String-Felder steps_to_reproduce, expected_result und actual_result. Nicht angegebene Felder bleiben erhalten; ein leerer String löscht den Text. Bei Aktualisierungen bleiben die bestehende Workspace-/Projektberechtigung und die Anforderungen an den Geltungsbereich von reports:write bestehen.

Fortsetzbare Google-Sheets-Screenshot-Importe verwenden den separaten REST-Endpunkt POST /api/reports/import-attachment mit reports:write und rufen den Status mit GET und reports:read ab. Es wird kein MCP-Tool für den Screenshot-Import hinzugefügt. Diese API, die nur JPEG/PNG unterstützt, überprüft den privaten Speicher und das exakt zugeordnete Jira-Issue, bevor sie den Abschluss meldet; der Upload von Legacy-Berichten bleibt auf Sitzungen beschränkt.

Private Links zu Berichts- und Testlauf-Anhängen prüfen beim Öffnen erneut die aktive Workspace-Mitgliedschaft und die aktuellen Projektberechtigungen. Für Testlauf-Downloads ist eine Dashboard-Sitzung erforderlich, kein MCP-API-Schlüssel. Bereits ausgestellte Speicherlinks können bis zu 60 Sekunden gültig bleiben und sollten nicht weitergegeben werden.

• create_bug_report — Einen neuen Bericht mit automatischer Klassifizierung in 19 Typen erstellen — darunter Bugs, Feature-Anfragen, Verbesserungen, technische Schulden und mehr (Titel: 3–500 Zeichen). Das optionale Array attachments akzeptiert Base64-kodierte Dateien mit bis zu 400 MB pro Datei: beliebige Bilder, Videos, Audiodateien, PDFs oder Text/JSON. Setze format_description: true, um die Beschreibung mithilfe von KI automatisch in eine strukturierte Vorlage umzuformatieren. Übergib time_spent_seconds, um den QA-Aufwand zu erfassen. Übergib priority (urgent / high / normal / low), um die Dringlichkeit der Fehlerbehebung unabhängig vom Schweregrad festzulegen. Übergib is_epic: true, um ein Epic zu erstellen, oder parent_epic_id (UUID/kurze ID), um ein untergeordnetes Element im selben autorisierten Projekt zu erstellen. Die Antwort enthält Hierarchiefelder sowie project_id, project, short_id, legacy_short_id und project_short_id.
• list_bug_reports — Berichte auflisten und filtern (max. 100 pro Seite). Projektfilter werden serverseitig vor der Paginierung angewendet. Filtern nach project (UUID, Slug, exakter Name oder Ticketpräfix), project_id, project_slug, project_prefix, workspace (UUID, exakter Name oder Workspace-Ticketpräfix), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause oder reporter_user_id. Der Filter search durchsucht Berichtstexte; eine Eingabe, die nur aus Ziffern besteht, wie 366, führt eine exakte Suche sowohl in Legacy- als auch in Projektticketnummern durch, sodass nicht zusammenhängender Text mit diesen Ziffern ausgeschlossen wird. Jedes Ergebnis enthält mandantenbezogene Personen-/Projektkennungen sowie is_epic, parent_epic_id, parent_epic und begrenzte Werte für epic_progress. Tools zum Lesen von Berichten geben keine E-Mail-Adressen von Mitgliedern preis.
• pick_next_bug — Gibt die nächsten Bugs zurück, an denen die Agentenschleife arbeiten sollte, sortiert nach Priorität (S1 → S2 → S3, innerhalb jeder Gruppe die ältesten zuerst). Automatisch auf deinen Workspace beschränkt — gibt Tickets aus allen Projekten deines Teams mit status new, awaiting-triage oder confirmed und Schweregrad S1–S3 zurück. Nur lesend — Tickets werden nicht atomar beansprucht. Optional: severity (einzelne Stufe), limit (1–50, Standardwert 1). Gibt ein Objekt mit count und bugs zurück; jeder Bug ist eine reduzierte Warteschlangen-Zeile und nicht die vollständige Form von list_bug_reports. Für das Muster „erst lesen, dann beanspruchen“ mit claim_bug kombinieren.
• claim_bug — Übergang eines Bugs von status new, awaiting-triage oder confirmed zu status='in-progress' atomar durchführen, assigned_to auf den aufrufenden Benutzer setzen und claimed_at=NOW() stempeln. Durch das UPDATE-WHERE-RETURNING-Muster von Postgres frei von Race Conditions — wenn zwei Agents kurz nacheinander claim_bug für dieselbe ID aufrufen, erhält genau einer claimed:true mit dem Bug-Inhalt, der andere claimed:false mit einer Begründung. Erfolgreiche Antworten enthalten reporter_user_id, reporter_name, assigned_to und assignee_name. Ein pg_cron-Bereinigungsprozess gibt veraltete Beanspruchungen (status= in-progress + claimed_at älter als 30 Minuten) automatisch an new zurück, sodass die Tickets eines abgestürzten Agents ohne manuelles Eingreifen wieder in die Warteschlange gelangen. Eingaben: id (UUID oder kurze ID).
• get_bug_report — Vollständige Details eines Berichts anhand der UUID oder einer kurzen Workspace-/Projekt-ID abrufen. Gibt die standardmäßigen Personen-/Projekt-/Qualitätsfelder sowie is_epic, die übergeordnete Identität, den aggregierten Fortschritt und eine begrenzte erste Seite untergeordneter Elemente für Epics zurück.
• Native Berichtstags: create_bug_report und update_bug_report akzeptieren tags als String-Array, zum Beispiel {"tags":["login","regression"]}. Vor der Deduplizierung werden höchstens 20 Rohwerte akzeptiert. Strings werden getrimmt, müssen nicht leer sein und dürfen höchstens 50 Unicode-Codepoints enthalten. ASCII-Steuerzeichen (U+0000 bis U+001F oder U+007F) sind unzulässig. Exakte Duplikate werden nach dem Trimmen entfernt; die Groß-/Kleinschreibung bleibt erhalten, und Login unterscheidet sich von login. Bei einer Aktualisierung ersetzt das Array alle Tags, [] löscht sie und bei Auslassung bleiben sie erhalten. Beim Erstellen bedeutet Auslassung, dass keine Tags gesetzt werden. null und ungültige Elemente werden abgelehnt. Ergebnisse von Erstellen, Abrufen, Auflisten und Aktualisieren enthalten native tags.
• Tag-Filterung: Rufe list_bug_reports mit {"project":"bugagent","tags":["login","regression"]} auf, um vor der Paginierung alle angeforderten Tags unter Beachtung der Groß-/Kleinschreibung abzugleichen. Es gelten dieselben Tag-Beschränkungen; bei Auslassung oder [] wird kein Tag-Filter angewendet. Bestehende Bereiche reports:read / reports:write und die Workspace-/Projektberechtigungen bleiben unverändert. Dadurch werden weder eine visuelle Tag-Oberfläche noch ein automatischer Import, eine Synchronisierung oder ein Backfill von Jira-Labels hinzugefügt.
• get_epic — Ein Epic direkt mit dem erforderlichen id (UUID oder kurze Workspace-/Projekt-ID) lesen. Gibt nur den Epic-Datensatz zurück, ohne untergeordnete Berichte implizit zu laden. Erfordert Zugriff auf den Workspace und das Projekt; Aufrufer mit API-Schlüssel benötigen reports:read. Verwende list_epic_children separat, um untergeordnete Elemente zu lesen.
• list_epic_children — Untergeordnete Berichte eines Epics mit id, limit (1–100) und offset paginieren. Gibt children, total, has_more und das per SQL aggregierte epic_progress zurück, ohne jeden untergeordneten Bericht zu laden.
• update_bug_report — Standardmäßige Berichtsfelder sowie is_epic und parent_epic_id aktualisieren. Übergib parent_epic_id: null, um die Zuordnung aufzuheben; das Ändern oder Aufheben der übergeordneten Zuordnung erfolgt atomar und erfordert eine Autorisierung für denselben Workspace und dasselbe Projekt. Wird ein Bericht zu einem Epic hochgestuft, wird eine bestehende übergeordnete Zuordnung aufgehoben; ein Epic mit untergeordneten Elementen kann nicht herabgestuft werden. Die bestehenden Regeln für Status/Auflösung/Ursachenanalyse und Benachrichtigungen bei Zuweisungen gelten weiterhin. Eine Änderung von status bei einem mit Jira verknüpften Bericht wird über die Workflow-Übergänge des Jira-Issues an dieses gespiegelt, wenn genau ein zulässiger Übergang dem zugeordneten Status entspricht; andernfalls bleibt das Issue unverändert.
• add_comment — Einen Kommentar zu einem Bug-Bericht hinzufügen (UUID oder kurze ID, Text mit 1–10.000 Zeichen). Wenn der Bericht mit Jira synchronisiert ist, wird der Kommentar automatisch an das verknüpfte Jira-Issue übertragen. Markdown für private Anhänge wie ![proof](/api/attachments/ATTACHMENT_UUID) wird in Jira zu einem absoluten, authentifizierten bugAgent-Smart-Link. Betrachter müssen sich bei bugAgent anmelden und Zugriff auf den Workspace und das Projekt des Berichts haben; native Inline-Vorschauen in Jira sind nicht garantiert.
• list_comments — Den gespeicherten Kommentarverlauf eines Berichts auflisten, älteste zuerst — jeder Kommentar mit Autorname, parentId (Antworten in Threads), createdAt und updatedAt. Kommentare sind nicht Teil von get_bug_report; so liest du die Diskussion zu einem Ticket. Akzeptiert eine UUID oder kurze ID. Dieser Lesevorgang aktualisiert Jira nicht. Geplante Integrationen, die aktuelle Jira-Kommentare benötigen, können zuerst POST /api/jira/comments-refresh mit einem autorisierten, managerverwalteten API-Schlüssel aufrufen. Verwende Kommentar-IDs und Inhaltsrevisionen, um neue Kommentare von Bearbeitungen zu unterscheiden, und gib keinen vollständigen Aktivitätsbericht aus, wenn die Aktualisierung fehlschlägt.
• link_bug_reports — Einen gerichteten semantischen Link zwischen zwei Berichten im selben autorisierten Projekt erstellen. Bei parent-of muss der Ausgangsbericht ein Epic und der Zielbericht ein standardmäßiges untergeordnetes Element sein. Verwende beim Erstellen/Aktualisieren für die Epic-Zuordnung vorzugsweise parent_epic_id.
• unlink_bug_reports — Einen zuvor erstellten Bug-Berichtslink anhand seiner UUID entfernen (link_id, zurückgegeben von link_bug_reports oder list_bug_report_links).
• list_bug_report_links — Alle von Benutzern kuratierten Links auflisten, die einen Bug-Bericht betreffen. Gibt jeden Link aus der Perspektive des angegebenen Berichts zurück — z. B. wird eine gespeicherte duplicate-of-Zeile, bei der dieser Bericht das Ziel ist, als duplicated-by dargestellt; parent-of, bei der dieser Bericht das Ziel ist, als subtask-of; depends-on, bei der dieser Bericht das Ziel ist, als blocks; testing-blocked-by, bei der dieser Bericht das Ziel ist, als blocks-testing. related-to ist symmetrisch. Ergänzt das automatisch erkannte Feld similar_reports, das von get_bug_report zurückgegeben wird.
• classify_bug — Eine Beschreibung mit Konfidenzwert einem von 19 Berichtstypen zuordnen (Bugs, Features, Verbesserungen usw.)
• flush_reports — Alte Berichte gesammelt löschen (nur Admins)

📊

Nutzung & Analysen

• get_usage — Nutzung im Verhältnis zu den Tariflimits prüfen. Aufrufer mit API-Schlüssel benötigen usage:read.
• get_stats — Tägliche Anzahl sowie Aufschlüsselungen nach Typ/Schweregrad/Status

📁

Projektverwaltung

• list_projects — Zugängliche Projekte mit id, name, slug, ticket_prefix, Beschreibung und Standardstatus auflisten. Verwende diese Werte mit Bug-Berichts- und Testkatalog-Tools, um das richtige Projekt anzusprechen.
• create_project — Ein neues Projekt erstellen (wird automatisch zum Standardprojekt, wenn es das erste ist)
• delete_project — Ein Projekt und alle zugehörigen Daten dauerhaft löschen (Bug-Berichte, Automatisierungen, Testfälle, mobile Apps, Zeitpläne, Geo-Snaps, Notizen, Zeiteinträge). Nur Eigentümer/Manager. Das letzte Projekt kann nicht gelöscht werden. Speicherplatz wird automatisch freigegeben.
• export_okf_bundle — Das QA-Wissen eines Projekts — Bug-Berichte, Testfälle, Automatisierungen sowie Performance-, Sicherheits- und explorative Tests — als OKF/OQA-Markdown-Bundle exportieren (das Open Query Agent-Format von oqa.ai). Standardmäßig wird das aktive Projekt verwendet; übergib das optionale project (Slug oder Name), um ein anderes zu exportieren. Gibt die Dateiliste des Bundles sowie das Bundle selbst als Base64-kodiertes ZIP zurück.

🔐

Authentifizierung & Konto

• register_account — Ein neues Konto erstellen (Passwort: 8–128 Zeichen, ratenbegrenzt: 5/15 Min.)
• login — Anmelden und Zugriffstoken erhalten (ratenbegrenzt: 5/15 Min.)
• update_profile — Anzeigenamen aktualisieren
• change_password — Kontopasswort ändern
• get_settings — Profil und Benachrichtigungseinstellungen lesen.
• update_settings — Unterstützte Profil- und Benachrichtigungseinstellungen aktualisieren. Nur OAuth-Mutation.

🔑

API-Schlüsselverwaltung

• generate_api_key — Einen benannten API-Schlüssel erstellen
• list_api_keys — Aktive Schlüssel auflisten (nur Präfix)
• regenerate_api_key — Einen Schlüssel widerrufen und ersetzen
• delete_api_key — Einen Schlüssel dauerhaft widerrufen

👥

Teamverwaltung

• list_workspaces — Die Workspaces auflisten, denen du angehörst, deine Rolle in jedem Workspace und den Workspace, den die Sitzung standardmäßig verwendet. Hosts mit mehreren Workspaces können eine Anfrage mit dem Header X-BugAgent-Workspace festlegen (nur für aktive Mitglieder).
• list_team_members — Alle Mitglieder deines Workspaces mit Rollen, Status und Booster-Kennzeichnungen auflisten
• invite_team_member — Einen Benutzer per E-Mail einladen (Manager können Mitwirkende und Manager einladen; nur Eigentümer können Admins einladen). Einladungslink mit 5 Tagen Gültigkeit

🎯

Integrationen

Die Jira-Cloud-Berichtsynchronisierung ist in Free und Enterprise enthalten. Ein Workspace-Manager muss Jira zuerst im Dashboard verbinden. Workspace-API-Schlüssel können dann jira:read zum Vergleichen und jira:write zum Synchronisieren/Zusammenführen verwenden; die Tarif- und API-Limits von Atlassian gelten weiterhin.

• sync_to_jira — Einen Bericht über die gemeinsame Verbindung des Teams an Jira senden. Leitet an das Jira-Projekt weiter, das dem bugAgent-Projekt des Berichts zugeordnet ist (als Fallback gilt das Standardprojekt des Arbeitsbereichs), und verwendet dessen Feldzuordnung: v2 trennt Priorität und benutzerdefinierten Schweregrad, während nicht versionierte Zuordnungen die ältere Übersetzung von Schweregrad zu Priorität beibehalten. Optional kann projectKey nur diese konfigurierte Zuordnung oder das Standardprojekt des Arbeitsbereichs auswählen; beliebige Jira-Projekte werden abgelehnt. Das ist normalerweise nicht nötig: Wenn der Synchronisierungsmodus des Projekts auto_new oder auto_all ist, werden erstellte Berichte automatisch übertragen — rufe dieses Tool für eine manuelle Übertragung im Modus manual auf.
• check_jira_sync — Schreibgeschützter Vergleich von Titel und zugeordnetem Status, Priorität und Schweregrad für einen autorisierten verknüpften Bericht. Verwendet das gespeicherte Projekt und die Jira-Verbindung des Berichts. Version 2 ordnet Jira Priority getrennt einem unterstützten benutzerdefinierten Severity-Feld zu; nicht versionierte Zuordnungen behalten das ältere Verhalten bei, bei dem Priorität in Schweregrad übersetzt wird. Dieses Tool vergleicht keine Kommentare, Anhänge, Typen oder sämtliche Jira-Felder.
• merge_jira_sync — Diese zugeordneten Felder zusammenführen: Mit prefer: jira Jira-Werte abrufen oder mit prefer: bugagent lokale Werte übertragen. Statusübertragungen verwenden zulässige Jira-Workflow-Übergänge. Nicht zugeordnete Konflikte bei ausgehenden Änderungen, fehlgeschlagene Schreibvorgänge auf dem Remotesystem und gleichzeitige lokale Änderungen führen zu Fehlern, statt fälschlich zu melden, dass alles synchron ist. Kommentare und Anhänge bleiben separate Synchronisierungsabläufe im Dashboard. Schreibvorgänge über mehrere Systeme hinweg sind nicht atomar.
• push_to_claude — Die Entwicklernotizen für einen Fehlerbericht erstellen (oder neu erstellen) — Ursache, Lösungsvorschlag, Verifizierungsschritte und Risikobewertung. Akzeptiert UUID oder Kurz-ID (WRKID-545). Verwendet Plattformschlüssel — keine Claude-Verbindung pro Team erforderlich. Führt eine adaptive Kette aus: drei Schritte bei Fehlern der Stufen s3 / medium oder s4 / low (Sonnet-Entwurf → OpenAI-Kritik gpt-5 → Sonnet-Synthese), fünf Schritte bei den beiden höchsten Schweregradstufen — s1 / critical oder s2 / high — (Entwurf → Kritik → Sonnet-Erwiderung → Claude-Opus-Schlichter, der das vollständige Transkript liest und die endgültigen Notizen mit eigenständiger Beurteilung verfasst). Die Antwort enthält jede Runde: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model sowie ein debated-Flag. Schlägt ein Schritt fehl, wird mit der nächstbesten Antwort fortgefahren. Wird bei der Erstellung eines Fehlers automatisch ausgelöst; wird normalerweise nur für eine manuelle Neuerstellung aufgerufen.
• analyze_fix_area — Den Unterabschnitt „Wahrscheinlicher Lösungsbereich“ der Entwicklernotizen erstellen (oder neu erstellen) — eine knappe Sonnet-Ausgabe, die angibt, wo in der Codebasis die Lösung wahrscheinlich hingehört. Akzeptiert UUID oder Kurz-ID. Verwendet den Anthropic-Plattformschlüssel. Wenn für das Team eine github_connections-Zeile vorhanden ist und dem Projekt ein github_repo zugeordnet ist, stützt sich die Ausgabe auf echte Dateiausschnitte aus dem verbundenen Repository; andernfalls werden allgemeine Hinweise mit der Empfehlung ausgegeben, ein Repository zu verbinden. Gibt den Text likely_fix_area, generated_at, repo_used und ein grounded-Flag zurück. Wird bei der Erstellung eines Fehlers automatisch ausgelöst — Agents müssen dieses Tool normalerweise nur für eine manuelle Neuerstellung aufrufen.
• upgrade_plan — Den Anmeldelink für die Enterprise-Registrierung mit Vertriebsunterstützung abrufen

⚡

Leistungstests

• create_performance_test — Eine Leistungstestkonfiguration mit URL, Gerät, virtuellen Benutzern, Dauer, Schwellenwert für die Bewertung und Option zur automatischen Fehlererstellung erstellen. Optional akzeptiert project eine Projekt-UUID, einen Slug, einen exakten Namen oder ein Ticketpräfix im aktuellen Arbeitsbereich. Wenn nicht angegeben, wird das Standardprojekt des Arbeitsbereichs verwendet, danach das älteste Projekt; der Aufrufer muss Zugriff haben. Mit list_projects ein Projekt auswählen. Ein leeres, unbekanntes oder nicht zugängliches Projekt wird abgelehnt. name darf nicht leer sein und wird von Leerzeichen am Anfang und Ende bereinigt. Namen von Leistungstests müssen innerhalb des Arbeitsbereichs und Projekts eindeutig sein; Groß-/Kleinschreibung sowie Leerzeichen am Anfang und Ende werden ignoriert. Bei einem Konflikt wirst du aufgefordert, einen anderen Namen zu wählen. Nur Enterprise
• run_performance_test — Ein Seitenaudit und einen Lasttest für einen Web-Leistungstest auslösen. Gibt eine Lauf-ID zurück, mit der die Ergebnisse abgefragt werden können. Profiling-Läufe für mobile Apps werden über das Dashboard ausgelöst
• get_performance_results — Vollständige Ergebnisse abrufen, einschließlich Lighthouse-Bewertungen (Performance, Accessibility, Best Practices, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) und Lasttestmetriken (VUs, Anfragen, RPS, p50/p90/p95/p99-Latenzen)
• list_performance_tests — Alle Leistungstestkonfigurationen des aktuellen Teams auflisten
• get_performance_usage — Monatliche Nutzung von Leistungstests prüfen. Leistungstests sind nur für Enterprise verfügbar. Free=0, Enterprise=unbegrenzt

Beispielablauf

1. get_performance_usage → verbleibendes Kontingent prüfen
2. create_performance_test → einen Test für deine URL konfigurieren
3. run_performance_test → Audit und Lasttest auslösen
4. get_performance_results → Bewertungen und Vitalwerte prüfen

🛡

Sicherheitsscans

• create_security_scan — Eine Sicherheitsscan-Konfiguration erstellen. Web-Scans verwenden Quick Scanner + Nuclei (über 4.000 Vorlagen) mit drei Tiefenstufen und optionaler authentifizierter Prüfung. Mobile Scans verwenden MobSF zur Analyse von APK-/IPA-Binärdateien. Die automatische Fehlererstellung mit Schweregradschwellenwerten ist konfigurierbar. Optional akzeptiert project eine Projekt-UUID, einen Slug, einen exakten Namen oder ein Ticketpräfix im aktuellen Arbeitsbereich. Wenn nicht angegeben, wird das Standardprojekt des Arbeitsbereichs verwendet, danach das älteste Projekt; der Aufrufer muss Zugriff haben. Mit list_projects ein Projekt auswählen. Ein leeres, unbekanntes oder nicht zugängliches Projekt wird abgelehnt. name darf nicht leer sein und wird von Leerzeichen am Anfang und Ende bereinigt. Namen von Sicherheitsscans müssen innerhalb des Arbeitsbereichs und Projekts eindeutig sein; Groß-/Kleinschreibung sowie Leerzeichen am Anfang und Ende werden ignoriert. Sie werden unabhängig von Leistungstestnamen behandelt. Bei einem Konflikt wirst du aufgefordert, einen anderen Namen zu wählen. Nur Enterprise
• run_security_scan — Einen Schwachstellenscan auslösen. Für Web-Scans ist eine DNS-Domainverifizierung erforderlich. Für Mobile Scans muss eine App hochgeladen sein. Gibt eine Lauf-ID zurück, mit der die Ergebnisse abgefragt werden können
• get_security_results — Vollständige Ergebnisse abrufen, einschließlich Sicherheitsbewertung (0-100), nach Schweregrad kategorisierten Befunden (Critical, High, Medium, Low, Info) mit CWE-Referenzen, OWASP-Zuordnungen, Nachweisen und Hinweisen zur Behebung
• list_security_scans — Alle Sicherheitsscan-Konfigurationen des aktuellen Teams mit letzter Bewertung und Kennzeichnungen für Authentifizierung und Tiefe auflisten
• get_security_usage — Monatliche Nutzung von Sicherheitsscans prüfen. Sicherheitsscans sind nur für Enterprise verfügbar. Enterprise=unbegrenzt
• list_security_schedules — Alle geplanten Sicherheitsscans des Teams mit Cron-Ausdruck, Zeitzone, aktiviertem Status, nächstem Lauf und Benachrichtigungseinstellungen auflisten. Verknüpft die übergeordnete Scan-Konfiguration (Name, scan_type, target_url)
• create_security_schedule — Einen wiederkehrenden Zeitplan für einen Sicherheitsscan erstellen. Erfordert scan_id und cron_expression. Ein Zeitplan pro Scan-Konfiguration. Optional: timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id. Jeder Lauf wird auf dein monatliches Kontingent angerechnet; Admin-Benutzer umgehen das Kontingent. Die Scantiefe wird zum Zeitpunkt des Laufs immer aus der Scan-Konfiguration übernommen
• delete_security_schedule — Einen geplanten Sicherheitsscan löschen. Die übergeordnete Scan-Konfiguration und abgeschlossene Läufe bleiben davon unberührt

Beispielablauf

1. get_security_usage → verbleibendes Kontingent prüfen
2. create_security_scan → einen Scan für deine URL oder dein Repository konfigurieren
3. run_security_scan → einen einmaligen Schwachstellenscan auslösen
4. create_security_schedule → wiederkehrende Läufe automatisieren (z. B. wöchentliches SAST auf dem Main-Branch)
5. get_security_results → Befunde und Behebungsmaßnahmen prüfen

📖

Code-Review

• list_code_reviews — Die letzten KI-Code-Reviews des Teams auflisten. Gibt Qualitätsbewertungen, Schweregradanzahlen, PR-Informationen und Zeitstempel zurück. Nur Enterprise
• get_code_review — Ein Code-Review mit allen Befunden abrufen. Jeder Befund enthält Schweregrad, Kategorie (bug/security/performance/style/logic/maintainability), Titel, Beschreibung, Codevorschlag, Dateipfad und Zeilennummern
• get_code_review_usage — Die Nutzung von Code-Reviews prüfen. KI-Code-Reviews sind nur für Enterprise verfügbar; bei Enterprise unbegrenzt
• get_code_review_analytics — Review-Analysen abrufen: Trends, Befundkategorien/-quellen, Aufschlüsselung nach Schweregrad, Geschwindigkeitsmetriken, führende Repositories/Autoren. Unterstützt Rückblicke über 7/30/90 Tage

Beispielablauf

1. get_code_review_usage → verbleibende Reviews prüfen
2. Einen PR im Dashboard unter /dashboard/code-review prüfen
3. list_code_reviews → letzte Reviews anzeigen
4. get_code_review → Befunde und Vorschläge abrufen

🔍

Explorative KI

Autonomer Multi-Agent-Finder für Website-Fehler mit bis zu 10 parallelen Agents, die jeweils eine andere Teststrategie verwenden.

• list_explorations — Explorative-KI-Konfigurationen des Teams auflisten
• create_exploration — Eine neue Exploration erstellen. Akzeptiert agent_count (1–10, maximal 10), um mehrere parallele Agents mit jeweils einer eigenen Strategie auszuführen: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Mit diesem Tool können keine Anmeldedaten oder Authentifizierungsmodi konfiguriert werden. Nur Anmeldeablauf testen muss ausdrücklich über das Dashboard oder REST konfiguriert und gestartet werden. Verwende anschließend get_exploration und get_exploration_run, um Konfiguration und Ergebnisse zu prüfen. Leite den Modus niemals aus Anweisungen ab und gib keine Anmeldedaten in MCP-Argumenten an. Für die standardmäßige anmeldeinformationsbasierte Exploration ist weiterhin eine wiederverwendbare Sitzung erforderlich.
• get_exploration — Die Explorationskonfiguration mit Agent-Einstellungen, sicheren Authentifizierungsmetadaten und letzten Läufen abrufen. Passwörter und Chiffretexte werden niemals zurückgegeben.
• get_exploration_run — Laufergebnisse mit Fortschritt pro Agent, Phasendaten, Befunden mit Agent-Zuordnung (agent_index, agent_strategy) und verknüpften Fehlern abrufen
• get_exploration_usage — Monatliche Nutzung prüfen. Explorative KI ist nur für Enterprise verfügbar; Enterprise: unbegrenzt (10 Agents)

Beispielablauf

1. create_exploration mit agent_count: 5 → 5 parallele Agents konfigurieren
2. Einen Lauf über das Dashboard oder mit POST /api/explorations/run auslösen
3. get_exploration_run → Fortschritt und Befunde der einzelnen Agents abrufen
4. Deduplizierte Befunde mit Agent-Zuordnung im Dashboard anzeigen

📝

Notizen

• list_notes — Notizen mit optionalen Filtern für Stichwort, Projekt, Sichtbarkeit, Ordner, Tag, Archiv, Wiki, Datumsbereich und Sortierung auflisten. Gibt Notizen zurück, die dem Benutzer gehören oder mit ihm geteilt wurden.
• create_note — Eine Notiz in einem von 5 Formaten erstellen: markdown, plain, bugtemplate, checklist, outline. visibility auf private oder shared setzen. Wenn kein Titel angegeben ist, wird er automatisch aus den ersten 30 Zeichen erstellt. Das optionale Array attachments akzeptiert Base64-kodierte Dateien mit einer Größe von jeweils bis zu 400 MB: beliebige Bilder, Videos, Audiodateien, PDFs oder Text-/JSON-Dateien. time_spent_seconds übergeben, um den QA-Aufwand zu erfassen.
• get_note — Vollständige Notizdetails einschließlich Inhalt und Anhängen abrufen. Erfordert id.
• update_note — Titel, Inhalt, Format, Sichtbarkeit, Projekt oder time_spent_seconds aktualisieren. Ein Array attachments übergeben, um der Notiz neue Dateien hinzuzufügen (maximal 400 MB pro Datei), ohne die vorhandenen Anhänge zu ersetzen. Nur der Autor kann die Notiz aktualisieren. Erfordert id.
• delete_note — Eine Notiz und ihre Anhänge dauerhaft löschen. Nur der Autor kann die Notiz löschen. Erfordert id.
• list_note_folders — Notiz-/Wiki-Ordner auflisten, optional auf ein Projekt beschränkt.
• create_note_folder — Einen projektbezogenen Notiz-/Wiki-Ordner mit optionalen Einstellungen für übergeordneten Ordner, Sichtbarkeit, Favoriten und Teamzugriff erstellen.

Beispielablauf

1. create_note → eine Notiz für eine Testsitzung beginnen
2. update_note → während des Testens Beobachtungen hinzufügen
3. list_notes → frühere Notizen nach Stichwort oder Projekt durchsuchen
4. get_note → vollständige Notiz mit Anhängen abrufen

🤖

Automatisierung

• create_automation — Eine neue Automatisierung mit einem benutzerdefinierten Playwright-Skript erstellen (keine FAB-Aufzeichnung erforderlich). Erfordert name. Optional: target_url (wird automatisch aus der ersten page.goto(...)-URL im Skript abgeleitet, falls nicht angegeben), script (Node.js/JavaScript/TypeScript oder Python — die Sprache wird automatisch erkannt; standardmäßig wird ein Platzhalter verwendet), status (draft oder active, Standard: draft), project_id. Gibt die Automatisierung id zurück. Tipp — Automatisierung duplizieren: Mit get_automation das ursprüngliche Skript abrufen und anschließend create_automation aufrufen, wobei name auf "[Copy] Original Name" gesetzt wird. Dabei script, target_url und project_id des Originals übergeben. Das Duplikat startet mit dem Status draft und ohne Versionsverlauf.
• list_automations — Playwright-Automatisierungsskripte auflisten. Nach project_id oder status filtern (draft, active, paused). Gibt ein Array von Automatisierungen mit name, target_url, last_run_status und run_count zurück.
• get_automation — Vollständige Automatisierungsdetails einschließlich Playwright-Skript und letzter Ausführungen abrufen. Erfordert id. Gibt die Automatisierung mit dem aktuellen script, einem script_versions-Stack (älteste zuerst, bis zu 100 vorherige Einträge, jeweils { script, source, timestamp }) und einem recent_runs-Array zurück, in dem jede Ausführung das ausgeführte script_version_label / script_version_source enthält. Vor run_automation aufrufen, wenn eine bestimmte historische Version ausgewählt werden soll.
• run_automation — Eine Playwright-Testausführung sofort starten. Erfordert automation_id. Selbstheilende Locators (automatisch): Wenn bei einer Locator-Aktion eine Zeitüberschreitung auftritt, bittet der Runner Claude um einen funktionierenden Selektor und wiederholt den Schritt einmal — Assertions werden nie automatisch korrigiert, sodass echte Regressionen weiterhin fehlschlagen — und jede Korrektur wird in der Run-Ausgabe protokolliert. Emulationsmodus (Standard): optional device für ein emuliertes Geräteprofil (z. B. desktop, iphone-15). Realmodus: browserstack: true mit bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) und bs_os_version setzen, um die Ausführung in einem echten Desktop-Browser zu starten. Echtes Mobilgerät: bs_os: "android" setzen (Geräte: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") oder bs_os: "ios" (Geräte: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") und den Gerätenamen in bs_os_version übergeben. Beide Modi werden im Hintergrund ausgeführt; „Real“ bezeichnet die Ausführungsumgebung, keine sichtbare interaktive Sitzung. Node.js-Skripte werden über browserstack-node-sdk ausgeführt (unterstützt Desktop, Android und iPhone). Python-Skripte werden über browserstack-sdk (pytest-playwright) ausgeführt und unterstützen nur Desktop — echte Mobilgeräte werden mit Python nicht unterstützt, da browser_type.connect() von pytest-playwright die Real-Mobile-Endpunkte von BrowserStack nicht ansteuern kann. Video- und Netzwerkprotokolle werden automatisch erfasst; Konsolenprotokolle nur auf dem Desktop. Versionswiederholung: script_versions mit get_automation prüfen und anschließend das bevorzugte dauerhafte version_label übergeben (zum Beispiel "v103"). Das ältere version_index wird weiterhin unterstützt, darf aber nicht mit version_label kombiniert werden. Standard: Wenn beide Selektoren fehlen, wird das aktuell gespeicherte Skript ausgeführt. Entfernte Labels und ungültige Indizes werden zurückgewiesen, statt stillschweigend das aktuelle Skript auszuführen. Der Ausführungsdatensatz speichert den exakten ausgeführten Snapshot, und jeder automatisch erstellte Fehlerbericht zu einer fehlgeschlagenen Ausführung enthält einen Deep Link zu dieser Version im Editor.
• list_automation_runs — Letzte Ausführungen einer Automatisierung auflisten. Erfordert automation_id. Gibt Ausführungen mit status, duration_ms und error_message zurück.
• list_schedules — Alle geplanten Web-Automatisierungsausführungen mit nullable cron_expression, nullable run_at, once_status, Zeitzone, Gerät und Benachrichtigungseinstellungen auflisten. Wiederkehrende Einträge behalten null run_at und once_status; einmalige Einträge haben null cron. Status einmaliger Ausführungen: pending, claimed, missed, dispatched, failed, uncertain. Dies sind Dispatch-Status, keine Testergebnisse; Ergebnisse unter list_automation_runs prüfen.
• Wiederkehrende Web-Zeitpläne: create_schedule validiert fünf numerische Cron-Felder und die Zeitzone und gibt einen zukünftigen UTC-Wert next_run_at zurück. Monatliche und jährliche Wiederholungen werden unterstützt. Beispielsweise bedeutet 30 12 23 9 * in America/Toronto den 23. September um 12:30 Uhr jedes Jahr, nicht eine einmalige Ausführung. Ungültige oder unmögliche Zeitangaben werden vor der Erstellung zurückgewiesen. Wenn sowohl der Monatstag als auch der Wochentag eingeschränkt sind, müssen beide übereinstimmen. Nicht existierende Zeiten bei der Sommerzeitumstellung werden übersprungen; wiederholte Uhrzeiten können zweimal auftreten. Der Dispatch erfolgt beim nächsten Abruf durch den Scheduler, nicht unbedingt genau zur angegebenen Minute. Das bestehende Verhalten wiederkehrender Zeitpläne bleibt unverändert.
• Einmalige Web-Zeitpläne: create_schedule mit { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" } aufrufen, ein zukünftiges Datum wählen und cron_expression weglassen. Genau ein Zeitangabenfeld angeben. run_at erfordert einen zukünftigen ISO-8601-Zeitstempel mit Zeitzonenoffset (expliziter Offset oder Z); die IANA-Zeitzone dient der Anzeige. Ein aktivierter, ausstehender Zeitplan wird beim ersten Cron-Abruf nach dem Fälligkeitszeitpunkt ausgeführt; bei mehr als einer Stunde Verspätung wird er als missed markiert. Er wird atomar beansprucht und vor dem Dispatch deaktiviert und kann nach dem Verbrauch nicht erneut aktiviert werden. Eindeutige Dispatch-Fehler haben den Status failed; ein mehrdeutiger Dispatch hat den Status uncertain und wird niemals automatisch wiederholt. Vor dem Planen eines weiteren Versuchs die Ausführungen prüfen. dispatched bedeutet nicht, dass die Ausführung abgeschlossen oder bestanden ist. Die Erstellung ist nur über API/MCP möglich, nicht über einen neuen Erstellungsmodus im Dashboard.
• Zeitzonen für Web-Zeitpläne sind IANA-Bezeichner wie America/Argentina/Buenos_Aires. Die Dashboard-Auswahl enthält alle vom Server unterstützten Regionen und Städte und verwendet standardmäßig die Zeitzone deines Profils; die MCP-Zeitzone bleibt standardmäßig UTC.
• create_schedule — Eine geplante Web-Automatisierungsausführung erstellen. Erfordert automation_id und genau eines von cron_expression oder run_at. Unterstützt optionale Einstellungen für Gerät, Zeitzone, Fehlerbenachrichtigung, E-Mail und Slack-Kanal. Slack zuerst über das Dashboard verbinden und einen Kanal auswählen, zu dem der Bot gehört; die Installation eines Webhooks allein reicht nicht aus. Siehe Slack-Einrichtung und Kanalsuche.
• Einmalige Einführung und Wiederherstellung: Datenbankmigration 374_one_time_web_schedules.sql anwenden, bevor der passende API-/MCP-Code und der Scheduler bereitgestellt werden. claimed kann nach einem Worker-Absturz bestehen bleiben: Vor dem Erstellen eines Ersatzes für einen beanspruchten oder unsicheren Dispatch den Ausführungsverlauf prüfen. Ein Zeitstempel, der mehr als eine Stunde zurückliegt, wird niemals automatisch ausgeführt.
• Web-Automatisierungen im Entwurfsstatus: Die Automatisierung aktivieren, bevor ein Zeitplan erstellt, ein Zeitplan erneut aktiviert oder dessen Cron-Ausdruck oder Zeitzone geändert wird. create_schedule prüft den Zugriff auf Workspace und Projekt, bevor der Status „Entwurf“ zurückgewiesen wird. Bestehende Zeitpläne überspringen Zyklen, solange die Automatisierung im Entwurfsstatus ist; Pausieren, Löschen, Anheften und reine Benachrichtigungsänderungen bleiben verfügbar. Es gibt kein Web-update_schedule-MCP-Tool; diese Aktualisierungen müssen über das Dashboard vorgenommen werden.
• delete_schedule — Eine geplante Web-Automatisierungsausführung löschen
• list_mobile_schedules — Alle geplanten mobilen Automatisierungsausführungen mit Geräten, Cron, Zeitzone und Benachrichtigungen auflisten
• create_mobile_schedule — Eine geplante mobile Automatisierungsausführung auf echten Geräten erstellen. Erfordert automation_id und cron_expression; devices ist optional.
• delete_mobile_schedule — Eine geplante mobile Automatisierungsausführung löschen
• optimize_automation_script — Ein Playwright-Skript zur KI-gestützten Optimierung an Sonnet 4 senden. Wendet eine 12-Punkte-Checkliste an, die Selektoren, Wartebedingungen, Assertions, Fehlerbehandlung, Authentifizierungsmuster, mobile Kompatibilität und den Strict-Modus verbessert. Erfordert automation_id. Die aktuelle Skriptversion wird vor der Optimierung gespeichert. Gibt das optimierte Skript und eine Zusammenfassung der Änderungen zurück.
• undo_automation_script — Ein Automatisierungsskript auf seine vorherige Version zurücksetzen. Bis zu 100 vorherige Versionen werden aufbewahrt. Erfordert automation_id. Gibt das wiederhergestellte Skript und die Anzahl der verbleibenden Versionen zurück.

Beispielworkflow

1. create_automation → einen Test mit einem benutzerdefinierten Skript erstellen
2. list_automations → verfügbare Tests durchsuchen
3. get_automation → das Playwright-Skript prüfen
4. run_automation → den Test starten
5. list_automation_runs → Ergebnisse und Dauer prüfen

⏱️

Zeiterfassung

• list_time_entries — Zeiteinträge des Teams auflisten. Filtern nach period (today, week, month, all), project_id, category und sort (newest, oldest, most_time, least_time). Nur im Enterprise-Tarif.
• create_time_entry — Für QA-Aufgaben aufgewendete Zeit erfassen. Erfordert description, category und duration_minutes. Optional project_id und entry_date festlegen (Standard: heute). Nur im Enterprise-Tarif.
• update_time_entry — Einen bestehenden Zeiteintrag aktualisieren. Erfordert id. Folgende Angaben können aktualisiert werden: description, category, duration_minutes, project_id oder entry_date. Nur im Enterprise-Tarif.
• delete_time_entry — Einen Zeiteintrag dauerhaft löschen. Erfordert id. Nur im Enterprise-Tarif.

Beispielworkflow

1. create_time_entry → 45 Minuten Regressionstests erfassen
2. list_time_entries → die Zeiteinträge dieser Woche anzeigen
3. update_time_entry → Dauer oder Kategorie anpassen
4. delete_time_entry → einen fehlerhaften Eintrag entfernen

☑️

Testfälle

Testverwaltung mit hierarchischen Ordnern, verschachtelten Testsammlungen (bis zu 3 Ebenen tief, mit automatischer Erweiterung von Untersammlungen bei Ausführungen), Drag-and-drop-Sortierung und einem Analyse-Tab „Reports“ mit KPI-Trends, Fehleranalyse, Zustand der Testsammlungen, Abdeckung und Testerproduktivität. Alle Tools greifen direkt auf Supabase zu — kein HTTP-Roundtrip, gleiche Latenz wie im Dashboard.

Kostenlose Limits: 10 gespeicherte Testfälle, 1 Testsammlung, 3 Ordner, 128 KB strukturierter Inhalt pro Fall, 2 aktive Workspace-API-Schlüssel und insgesamt 10 Testausführungen pro UTC-Kalendermonat. Bis zu 3 dieser Ausführungen können Hermes oder einen anderen externen Agenten verwenden; dabei ist 1 externe Ausführung gleichzeitig aktiv und jeder externe Plan auf höchstens 10 Fälle beschränkt. Der MCP-Datenverkehr über kostenlose API-Schlüssel ist auf 30 Anfragen pro Schlüssel und 60 pro Workspace und Minute begrenzt. Im Enterprise-Tarif sind Testfallspeicherung und Ausführungen unbegrenzt, vorbehaltlich der allgemeinen Plattformschutzmaßnahmen.

Die KI-Generierung von Testfällen, KI-Tag-Vorschläge, der Figma-Import und Dateianhänge für Testfälle erfordern den Enterprise-Tarif. Die Grenze von 128 KB für strukturierte Inhalte im kostenlosen Tarif gilt unabhängig von Dateianhängen im Enterprise-Tarif. Im kostenlosen Tarif können URL-Referenzen gespeichert werden. Die zentralen MCP-Tools für Testfälle sind im kostenlosen Tarif innerhalb der oben genannten Limits verfügbar.

Freihändige Ausführung: Die Seite zur Ausführungsprüfung ist ein Karussell mit jeweils einem sichtbaren Fall, Tastenkürzeln (P Bestanden · F Fehlgeschlagen · B Blockiert · S Überspringen) und Sprachsteuerung. Auf das Mikrofon klicken und dann „Bestanden“, „Fehlgeschlagen“, „Blockiert“, „Überspringen“, „Weiter“, „Zurück“, „Notizen hinzufügen“ (spricht den Text in das Notizfeld), „Notizen speichern“ oder „Sprachsteuerung aus“ sagen. Bei erfolgreichen Ergebnissen wird automatisch zum nächsten ungeprüften Fall gewechselt; bei „Fehlgeschlagen“ bleibt die Ansicht geöffnet, damit Tester Details diktieren und einen Fehler erstellen können. Funktioniert in Chrome, Edge und Safari.

Fälle und Ordner

• list_test_cases — Zugängliche Testfälle auflisten, mit optionalem project-Selektor sowie den Filtern search, priority, type, status und sort. folder_id hinzufügen (null für nicht zugeordnete Fälle) oder suite_id für direkte Zugehörigkeit ohne Nachfahren. Aufrufer mit API-Schlüssel benötigen test_cases:read. limit ist standardmäßig 50 (1–200); offset ist standardmäßig 0 (0–1000000). Das unveränderte Array cases wird ergänzt durch total / total_count für alle autorisierten Treffer, limit, offset, has_more und next_offset (nullable). Bisher bedeutete total fälschlicherweise die Seitenlänge. Folge next_offset, bis der Wert null ist; leite den Abschluss nicht aus der Seitenlänge ab. Eine Fortsetzung über Offset 1000000 hinaus schlägt explizit fehl; schränke stattdessen die Filter ein, damit kein unbrauchbarer Cursor oder ein falscher Abschluss zurückgegeben wird. Seiten mit mehr als 1 MiB Falldaten schlagen explizit fehl: Wiederhole die Anfrage mit einem kleineren Limit, statt ausgelassene Datensätze zu akzeptieren. Die Sortierung verwendet stabile IDs als Tie-Breaker, aber gleichzeitige Änderungen können Offset-Seiten verschieben.
• Paginierungsbeispiel: Rufe list_test_cases mit {"project":"test-bed","limit":50,"offset":0} auf. Bei 55 Treffern enthält die Antwort total:55, has_more:true, next_offset:50. Wiederhole den Aufruf mit offset:50 für die verbleibenden fünf und has_more:false, next_offset:null.
• create_test_case — Einen Testfall im erforderlichen project-Selektor erstellen (UUID, Slug, exakter Name oder Ticketpräfix; zuerst list_projects aufrufen). Zwei Vorlagenvarianten: steps (Standard) — Raster { action, expected } pro Schritt über das Array steps; text — eine einzelne frei formulierte Beschreibung über text_content. Beide Felder können im selben Aufruf gesendet werden. Das optionale Array urls (max. 10 http/https-URLs) fügt Referenzlinks hinzu und ist im Free-Tarif verfügbar. Datei-Anhänge erfordern Enterprise und eine Dashboard-Sitzung. Aufrufer mit API-Schlüssel benötigen test_cases:write.
• Wiederherstellung der Paginierung: Wird ein Fall-Offset angefordert, der über die verfügbaren Ergebnisse hinausgeht, wird ein expliziter Fehler zurückgegeben; beginne erneut bei Offset 0. Dies kann auch passieren, wenn Fälle zwischen Anfragen entfernt werden. Folge dem zurückgegebenen Fortsetzungswert, statt den nächsten Offset zu erraten.
• Fallkennungen: list_test_cases, get_test_case, create_test_case und update_test_case geben die UUID id, die unveränderliche short_id (zum Beispiel TEST-BA-CASE-123) und die numerische case_number zurück, auch bei kompakten Update-/No-op-Antworten. Ältere Fälle ohne Projekt verwenden TEST-CASE-123. Fehlende Kennungen werden als null zurückgegeben; verwende ersatzweise die UUID. Die Datenbank weist Kennungen zu; Aufrufer können sie weder ändern noch bei der Erstellung auswählen. Eine Umbenennung des Präfixes ändert vorhandene IDs nicht.
• Suche nach einem einzelnen Fall: get_test_case und update_test_case akzeptieren eine UUID oder vollständige Kurz-ID in id; link_test_case_to_bug und list_test_case_links akzeptieren beides in case_id. Umgebende Leerzeichen, Groß-/Kleinschreibung und numerische Auffüllung werden vor der exakten Suche im aktiven Workspace normalisiert. Die Autorisierung richtet sich nach dem gespeicherten Workspace und Projekt, nicht nach dem ID-Präfix. Einzelne Zahlen, unvollständige IDs und Platzhaltersuchen werden nicht akzeptiert. Arrays mit mehreren Fällen, case_id für Ausführungsergebnisse, Fehler-IDs, Ordner-IDs und Suite-IDs akzeptieren weiterhin nur UUIDs. Verknüpfungsdatensätze behalten die UUID case_id bei.
• Lücken in der Nummerierung: Fallnummern müssen nicht lückenlos sein. Das Bearbeiten einer URL oder das Erhöhen einer Nummer kann zu einem fehlenden oder unzugänglichen Fall führen; dies ist keine garantierte Aktion zum Aufrufen des nächsten Falls. Ermittle Fälle mit dem Auflistungstool und folge dessen Paginierung.
• Workspace-Geltungsbereich: Dieselbe Kurz-ID kann in verschiedenen Workspaces vorkommen. MCP löst sie nur im aktiven Workspace auf; wechsle den Workspace-Kontext, bevor du die Kurz-ID eines anderen Workspaces verwendest. Wenn du eine Dashboard-URL mit Kurz-ID teilst, behalte ?team=<case.team_id> bei, zum Beispiel /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. UUID-Permalinks behalten das bestehende autorisierte Verhalten für workspaceübergreifende Zugriffe bei. MCP erstellt keinen Permalink.
• get_test_case — Den autorisierten Falldatensatz einschließlich Schritten und Kennungen abrufen. Lädt weder den Änderungsverlauf noch den Ausführungsverlauf. Beispiel: {"id":"TEST-BA-CASE-123"}.
• Ausführungsschätzungen: get_test_case gibt estimated_time_seconds und den Kompatibilitätsalias estimated_time zurück, beide in Sekunden. Ein gespeicherter Wert von 0 bleibt 0; eine unbekannte oder fehlende Schätzung ist null. Das kanonische Feld hat Vorrang, wenn beide Namen vorhanden sind, auch bei einem expliziten null; Werte, die nur unter dem Legacy-Namen estimated_time vorliegen, werden ohne Umrechnung als Sekunden behandelt. list_test_cases verwendet estimated_time_seconds. Die Eingabe create_test_case bleibt estimated_time, ebenfalls in Sekunden; REST-Anfragen und -Antworten verwenden estimated_time_seconds.
• list_test_case_folders — Zugängliche Ordner auflisten. Auf 500 begrenzt; akzeptiert einen flexiblen project-Selektor und den Filter parent_folder_id (verwende "root" nur für oberste Ebene). Aufrufer mit API-Schlüssel benötigen test_cases:read.
• get_test_case_folder — Einen Testfallordner direkt mit dem erforderlichen id (UUID) lesen. Gibt nur den Ordnerdatensatz zurück, ohne implizit untergeordnete Ordner oder Testfälle zu laden. Erfordert Zugriff auf den Workspace und das Projekt des Ordners; Aufrufer mit API-Schlüssel benötigen test_cases:read.
• Testfallwerte für type, list_test_cases, create_test_case und bulk_update_test_cases: functional (Standard bei der Erstellung), regression, smoke, integration, performance, security, usability, exploratory. Ungültige Typen werden vor dem Schreiben abgelehnt. Verwende integration für End-to-End-Abläufe; e2e, accessibility und other werden nicht als Testfalltypen akzeptiert. Automatisierungsskript-Typen unterliegen einem separaten Vertrag.
• create_test_case_folder — Einen Ordner im erforderlichen project erstellen, das von list_projects zurückgegeben wird (Verschachtelung bis zu 3 Ebenen über parent_folder_id). Erfordert mindestens Mitwirkendenzugriff auf den Workspace sowie Zugriff auf das Projekt. Aufrufer mit API-Schlüssel benötigen außerdem test_cases:write.
• update_test_case_folder — Aktualisierung anhand der Ordner-UUID: id, optionales name (getrimmt, 1–120 Zeichen), nullable description (max. 50000 Zeichen), nullable parent_folder_id und nullable card_color. Eine übergeordnete UUID verschiebt den Ordner und seinen Teilbaum innerhalb desselben Workspaces und Projekts; null verschiebt ihn in die Stammebene. Für die Farbe werden die Kleinbuchstabenwerte der Palette #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd akzeptiert; null löscht sie. Nicht angegebene Felder bleiben unverändert. Mindestens ein Aktualisierungsfeld ist erforderlich. Unbekannte, falsch geschriebene oder ungültige Felder führen zur Ablehnung der gesamten Anfrage, ohne Änderungen zu speichern. Zyklen durch Selbst- oder Nachfahrenreferenzen, Namen, die mit einem Geschwisterordner, direkten übergeordneten oder direkten untergeordneten Ordner übereinstimmen (ohne Beachtung von Groß-/Kleinschreibung und umgebenden Leerzeichen), sowie Teilbäume mit einer Tiefe über 3 (Stammebene = Tiefe 0) werden abgelehnt. Die Tiefen der Nachfahren werden atomar aktualisiert; Fall-IDs und Zugehörigkeiten bleiben unverändert. Widersprüchliche gleichzeitige Änderungen können fehlschlagen; lies den Ordner vor einem erneuten Versuch erneut ein. Erfordert aktiven Projektzugriff mindestens auf Mitwirkendenebene sowie test_cases:write für API-Schlüssel. Beispiel: {"id":"folder-uuid","card_color":"#93c5fd"}. Gibt die aktualisierten Werte id, team_id, project_id, name, description, card_color, parent_folder_id, depth und updated_at zurück. Auch beim Abrufen und Auflisten von Ordnern wird card_color zurückgegeben.
• update_test_case — Einen vorhandenen Fall anhand der UUID oder vollständigen Kurz-ID in id patchen; mindestens ein Feld ist erforderlich: name (oder Alias title), description, preconditions, steps, template_type, text_content, priority, type, status oder folder_id. Nicht angegebene Felder bleiben unverändert; steps ersetzt das gesamte Array ([] leert es). Ein explizites null löscht Beschreibung, Voraussetzungen, text_content oder die Ordnerzuordnung; ein leerer Wert für text_content löscht den Inhalt ebenfalls. Werden name und title beide gesendet, müssen sie übereinstimmen. Für Priorität und Typ gelten die Erstellungs-Enums; der Status ist active, draft oder deprecated. Eine Typänderung gleicht type_tags an den neuen Typ an, wie bei der PATCH-API. Verschiebungen zwischen Workspaces oder Projekten sowie Schreibvorgänge für Dateimetadaten sind nicht möglich. Ordner müssen demselben Workspace und exakt demselben Projekt angehören. Erfordert test_cases:write. Gibt die Fallzusammenfassung, id, short_id, case_number und changed zurück; unveränderte Werte ergeben changed: false. Bei einer bestätigten Aktualisierung mit einem nicht bestätigten Verlaufseintrag wird warnings zurückgegeben; wiederhole die Aktualisierung nicht, um den Verlauf zu reparieren. Bei einem Fehler aufgrund gleichzeitiger Änderungen lies den Fall vor einem erneuten Versuch erneut ein. Suite-Zugehörigkeit wird separat verwaltet: Verwende dafür das untenstehende Bulk-Tool, nicht suite_id in diesem Tool. Es gibt kein Löschtool.
• bulk_update_test_cases — Eine Aktion auf 1–500 Fall-UUIDs anwenden; für einen einzelnen Fall eine ID übergeben. set_folder akzeptiert params.folder_id (UUID zum Verschieben, explizites null zum Entfernen aus dem Ordner). add_to_suite und remove_from_suite akzeptieren params.suite_id; beim Hinzufügen werden andere Zugehörigkeiten weder entfernt noch der Ordner verschoben. Unterstützt außerdem set_priority, set_status, set_type, add_tags, remove_tags, pin und unpin. Für API-Schlüssel ist test_cases:write erforderlich. Gibt applied, skipped und errors zurück; Organisationsaktionen zählen bestätigte geänderte Zeilen, deduplizieren IDs und überspringen bereits vorhandene Zugehörigkeiten.
• Zuordnung bei der Erstellung: create_test_case akzeptiert optional folder_id und suite_id. Ermittle Ziele mit list_test_case_folders und list_test_suites (die Suite-Ermittlung erfordert test_runs:read für API-Schlüssel). Ordner sind ein einzelner Katalogort; Suites sind Viele-zu-viele-Zugehörigkeiten zu Testplänen. Ziele müssen zum selben autorisierten Workspace und exakt demselben Projekt gehören, auch bei älteren Fällen ohne Workspace-Zuordnung. Unzugängliche Fall-IDs werden ohne Details übersprungen; nicht übereinstimmende Ziele werden abgelehnt. Ungültige Erstellungsziele führen dazu, dass der Fall gar nicht erst erstellt wird.
• Teilweise Erstellung: Die Erstellung des Falls und das Hinzufügen zur Suite sind getrennte Schreibvorgänge. Schlägt das Hinzufügen fehl, gibt die Antwort die erstellte Fall-ID, suite_id: null und ein Array warnings zurück. Wiederhole create_test_case nicht; wiederhole stattdessen bulk_update_test_cases mit add_to_suite für die zurückgegebene ID.
• link_test_case_to_bug — Eine Rückverfolgbarkeitsverknüpfung zwischen einem Testfall und einer Fehlerbericht-UUID herstellen (verified_by, covers oder relates). Beide Datensätze müssen zum aktiven Workspace und zu Projekten gehören, auf die der Aufrufer Zugriff hat.
• list_test_case_links — Alle Rückverfolgbarkeitsverknüpfungen für einen Testfall auflisten.
• list_test_case_review_candidates — Kennzeichnungen für veraltete Tests: never_run (90+ Tage seit der Erstellung), always_passes (5+ aufeinanderfolgende erfolgreiche Durchläufe innerhalb von 90 Tagen), always_skipped (3+ aufeinanderfolgende übersprungene Durchläufe).
• mark_test_case_review_flags — Aktuelle Kennzeichnungen für Archivierungskandidaten in test_cases.review_flag speichern. Wird jeden Montag um 09:00 UTC automatisch über pg_cron ausgeführt.

Importe

• Figma-Import (Enterprise) (nur Dashboard-Sitzung): Lade einen ZIP-Export von Figma-Frames hoch (bis zu 100 MiB); Claude analysiert jeden Bildschirm und erstellt Entwürfe von Testfällen in einem Ordner, den du auswählst oder erstellst. Vor dem Dekodieren ist das Archiv auf 1.000 Einträge, 20 MiB entpackte (dekodierte) Daten pro Eintrag und insgesamt 100 MiB entpackte Daten begrenzt; ignorierte Dateien und Verzeichnisse werden in die Grenzwerte einbezogen. Die dekodierten Frame-Puffer müssen den angegebenen Größen entsprechen. Fehlerhafte Archive, Größenabweichungen und überschrittene Grenzwerte lassen den Auftrag vor der KI-Analyse fehlschlagen; der ursprüngliche Upload bleibt bei einem Fehler für einen erneuten Versuch erhalten, vorbehaltlich der Speicherbereinigungsrichtlinie. Gültige Archive durchlaufen eine Pipeline mit mehreren Durchläufen (klassifizieren → Fälle pro Bildschirm → Fälle auf Ablaufebene für Bildschirme mit gemeinsamem Präfix → Selbstkritik) mit Prompt-Caching, Wiederholungsversuchen bei 429 und Isolierung von KI-Fehlern pro Frame. Die Fälle werden als status=active gespeichert und mit ai_generated=true gekennzeichnet; source='figma' und source_frame_name bewahren einen Link zum ursprünglichen Frame. Verwendet den Anthropic-Schlüssel der Plattform — keine Claude-Verbindung pro Team erforderlich.

Suites und Durchläufe

• list_test_suites — Listet bis zu 50 zugängliche Testsuiten mit einem optionalen flexiblen Filter project auf. Jede Suite enthält eine exakte Ganzzahl case_count: direkt zugewiesene Testfälle aller Status, ohne Nachfahren und ohne Testfälle aus anderen Workspaces oder Projekten (ältere Testfälle ohne Projekt bleiben enthalten). Die Anzahl ist nicht durch die abgerufenen Mitgliedschaftszeilen begrenzt. Aufrufer mit API-Schlüssel benötigen aus Gründen der Abwärtskompatibilität mit Ausführungs-Workern test_runs:read.
• get_test_suite — Liest eine Testsuite direkt mit dem erforderlichen id (UUID). Gibt nur den Suite-Datensatz zurück, ohne untergeordnete Suites oder zugehörige Testfälle implizit zu laden. Erfordert Zugriff auf den Workspace und das Projekt der Suite; Aufrufer mit API-Schlüssel benötigen test_runs:read.
• create_test_suite — Erstellt eine Suite im erforderlichen project, das von list_projects zurückgegeben wird. Verschachtelt bis zu 3 Ebenen über parent_suite_id. Aufrufer mit API-Schlüssel benötigen test_cases:write.
• update_test_suite — Aktualisiert anhand der Suite-UUID: id, optional name (getrimmt, 1–120 Zeichen), nullable description (max. 50000 Zeichen) und status (aktiv/archiviert). Nicht angegebene Felder und die Testfallzugehörigkeit bleiben erhalten. Erfordert aktiven Projektzugriff mit mindestens der Rolle „Contributor“ sowie test_cases:write. Verschieben des übergeordneten Elements und Anheften werden nicht unterstützt; zum Verschieben eines übergeordneten Elements muss die Tiefe aller Nachfahren atomar angepasst werden. Gibt id, team_id, project_id, name, description, parent_suite_id, depth, status und updated_at zurück. Beispiel: {"id":"suite-uuid","name":"Checkout regression","description":null}.
• list_test_runs — Listet Testläufe mit Suite-Name, zuständiger Person und Zusammenfassung zu bestanden/nicht bestanden auf. Von Dashboards hochgeladene Nachweise für Testläufe verwenden private Links, für die eine Dashboard-Sitzung sowie Zugriff auf den Workspace und das Projekt des Testlaufs erforderlich sind; ein MCP-API-Schlüssel gewährt keinen Dateizugriff.
• create_test_run — Erstellt einen von einem Dashboard verwalteten Suite-Testlauf. Beim Ausführen einer übergeordneten Suite werden automatisch alle Testfälle aller untergeordneten Sub-Suites einbezogen (ein Testfall, der mit beiden verknüpft ist, wird genau einmal hinzugefügt). Jede Zeile test_run_results erfasst, aus welcher Sub-Suite der Testfall stammt, damit Ergebnisseiten nach Herkunft gruppiert werden können.

Ausführung durch externe Agenten

Mit diesen Tools können Hermes oder eine andere Agentenlaufzeit eine genehmigte Suite ausführen, ohne zum führenden QA-System zu werden. Verwende einen auf den Workspace beschränkten Schlüssel, der nur über test_runs:read und test_runs:write verfügt. Die Suite legt die Projektgrenze fest; Aufrufer können sie nicht überschreiben.

• start_test_plan — Startet oder setzt einen unveränderlichen Suite-Snapshot mit einer stabilen external_run_id fort. Bei wiederholter ID werden der vorhandene passende Testlauf und die erste Seite zurückgegeben, statt ein Duplikat zu erstellen.
• get_test_run_plan — Liest den kanonischen Status des Testlaufs und eine stabile Planseite. Übergib den vorherigen next_cursor; Seiten enthalten standardmäßig 100 Testfälle und sind auf 200 begrenzt.
• report_test_results — Übermittelt 1–200 Ergebnisse mit dem Status passed, failed, blocked oder skipped. Exakte Wiederholungen sind sicher; der Versuch, einen Testfall mit einem anderen Status zu überschreiben, wird abgelehnt.
• abort_test_run — Beendet einen unterbrochenen Testlauf idempotent und bewahrt dabei akzeptierte Teilergebnisse sowie die kanonische Zusammenfassung.

Kontingentverhalten: Wiederhole start_test_plan mit derselben external_run_id, um den passenden Testlauf fortzusetzen, ohne einen weiteren Testlauf zu verbrauchen. Das Löschen von Daten setzt die monatliche Nutzung des Testlaufkontingents nicht zurück.

Laufzeitgrenze: Testfall-Snapshots enthalten keine Zugangsdaten, Dateiinhalte oder privaten Anhangspfade. Im MVP bestehen Ergebnisnachweise aus Text. Zugangsdaten für Zielsysteme verbleiben in der Ausführungsumgebung. Browser-, Modell- und Netzwerkkosten gehen weiterhin zulasten der Kunden, die den Zugriff auf Zielsysteme und den ausgehenden Netzwerkverkehr beschränken müssen. Ein Mensch bleibt für Entscheidungen zu Fehlern und Releases verantwortlich.

Der Hermes-Agent-Leitfaden bündelt diesen Ablauf als von bugAgent gepflegte Community-Skill. Das öffentliche Starter-Kit enthält eine direkt verwendbare Konfiguration und eine installierbare Skill. Es handelt sich nicht um eine offizielle Integration von Nous Research.

Berichte (Analysen der Stufen 1 und 4)

• get_test_reports_overview — Zentrale KPIs für einen Zeitraum (Bestehensquote, abgeschlossene Testläufe, ausgeführte Testfälle) mit Veränderungen gegenüber dem vorherigen gleich langen Zeitraum. Es sind dieselben Werte, die in der KPI-Leiste des Tabs „Reports“ angezeigt werden. Damit wird kein gespeicherter Projektbericht erstellt. Enterprise-XLSX-Projektberichte und deren Zeitpläne werden im Dashboard verwaltet; in dieser Version ist für diese gespeicherten Artefakte kein MCP-Tool aktiviert.
• Berichtssteuerung im Dashboard: Im Tab „Reports“ können mehrere Suites (einschließlich Nachfahren) zu einem gefilterten Bericht zusammengefasst werden. Für einen abgeschlossenen Testlauf gibt es außerdem die Aktion „Export PDF“, deren Abdeckungsnenner den in diesem Testlauf enthaltenen Testfällen entspricht. Diese Dashboard-Steuerungen fügen keine MCP-Tool-Parameter hinzu; zum Herunterladen eines PDF für einen einzelnen Testlauf ist eine Dashboard-Sitzung erforderlich.
• Testfallfilter im Dashboard: Der CSV-Export berücksichtigt die aktuellen Filter unter „Cases“ über alle passenden Seiten hinweg. „Suite Health“ und „Coverage by suite“ gruppieren untergeordnete Suites innerhalb des ausgewählten Suite-Bereichs unter ihren tatsächlichen übergeordneten Suites. Hierarchie-Eltern ohne eigene Testfälle zeigen Striche statt aggregierter Kennzahlen für untergeordnete Suites. Nicht zugehörige Suites, die dieselben Testfälle enthalten, bleiben ausgeschlossen. Diese Korrekturen ändern keine MCP-Tool-Parameter.
• get_test_reports_failures — Vier Listen mit Antworten auf die Frage „Was muss behoben werden?“: failing_cases (≥50 % fehlgeschlagen, mindestens 3 Testläufe), flaky_cases (die meisten Wechsel zwischen bestanden/nicht bestanden), failing_suites (≥30 % fehlgeschlagen, mindestens 5 Testläufe), regressed_cases (zuletzt fehlgeschlagen, mit einem früheren bestandenen Test im Zeitraum).

Beispielworkflow

1. create_test_case_folder → Erstellt eine Ordnerstruktur (z. B. Smoke → Auth). Verwende die zurückgegebene Ordner-ID, wenn du im selben Projekt einen Testfall erstellst; das Formular „New Test Case“ im Dashboard bietet ebenfalls die Möglichkeit, Ordner direkt anzulegen.
2. create_test_case → Definiert Testfälle; bearbeite Inhalte mit update_test_case und organisiere die Suite-Zugehörigkeit mit bulk_update_test_cases.
3. Beispiel für tools/call: {"name":"update_test_case","arguments":{"id":"00000000-0000-4000-8000-000000000001","title":"Verify login rejection","steps":[{"action":"Submit an incorrect password","expected":"An error is shown; no session is created"}],"status":"active","folder_id":null}}. Nicht angegebene Priorität, Typ und Beschreibung bleiben unverändert.
4. create_test_suite → Erstellt einen Testplan (Sub-Suites sind optional, bis zu 3 Ebenen tief).
5. create_test_run → Erstellt einen von Menschen oder über das Dashboard verwalteten Testlauf aus einer übergeordneten Suite – Sub-Suites werden automatisch einbezogen.
6. start_test_plan → Startet einen externen Agenten-Testlauf oder setzt ihn fort; Wiederholungen sind sicher.
7. get_test_run_plan → Ruft alle unveränderlichen Planseiten ab und führt den Plan anschließend in der ausgewählten Laufzeit aus.
8. report_test_results → Gibt begrenzte Ergebnisbatches zurück; rufe abort_test_run auf, wenn die Ausführung nicht sicher fortgesetzt werden kann.
9. get_test_reports_failures → Fragt nach Abschluss des Testlaufs: „Was muss diese Woche behoben werden?“
10. get_test_reports_overview → Verfolgt die Entwicklung der Bestehensquote von Woche zu Woche.

⚡

Team-Booster

• scale_team — Skaliere dein QA-Team sofort mit Booster-Testern. Konten werden automatisch mit Testerzugriff eingerichtet. Gib team_size (1–10), location, duration, budget und optional product_url, product_types und tech_levels an. Verfügbar im Enterprise-Tarif. Eine Abrechnung erfolgt erst nach der Genehmigung.

Beispielworkflow

1. scale_team → Richtet 5 erfahrene Tester für 1 Monat in den USA ein.
2. list_team_members → Überprüft, ob die neuen Tester im Team angezeigt werden.
3. list_bug_reports → Prüft die von Boostertestern eingereichten Berichte.

📱

Mobiles Testen (Enterprise)

Mobile Ressourcen sind auf Projektebene beschränkt. Übergib bei Erstellungen, Importen und gefilterten Listen project_id oder einen flexiblen Selektor project. Automatisierungen übernehmen das Projekt der verknüpften App; andernfalls verwendet der Server das Standardprojekt des Workspaces. Ungefilterte Listen können weiterhin ältere Einträge auf Workspace-Ebene enthalten, bis diese migriert wurden.

• list_mobile_apps — Hochgeladene Apps mit optionalen Filtern project_id / project, platform und limit auflisten. Gibt für jede App project_id zurück, damit Agents nachfolgende Vorgänge im selben Projekt ausführen können.
• upload_mobile_app — Eine APK-App (Android) oder IPA-App (iOS) für Tests auf echten Geräten registrieren. Erfordert name, platform (android / ios) und file_url; project_id übergeben, um die App dem aktiven Projekt zuzuweisen. Für iOS die IPA für Läufe auf echten Geräten hochladen und anschließend über das Dashboard einen Simulator-Build von .app für Aufzeichnungen hochladen.
• update_mobile_app — Eine App-Binärdatei durch eine neue Version ersetzen. Löscht zwischengespeicherte URLs und Simulator-Builds, damit alle Automatisierungen beim nächsten Lauf die neue Version verwenden. Erfordert app_id und file_url. Optional: version. Private verknüpfte Anmeldeprofile erfordern ihren aktiven Ersteller; für gemeinsam genutzte Profile ist aktiver Zugriff auf dasselbe Projekt erforderlich. Zeitpläne übernehmen den geschützten Automatisierungsstandard.
• list_mobile_automations — Mobile Automatisierungen mit optionalen Filtern project_id / project, app_id, status und limit auflisten. Die Ergebnisse enthalten project_id und die ID der verknüpften App.
• create_mobile_automation — Ein Testskript erstellen. Erfordert name, app_id, script_type (maestro für YAML, appium für Appium Python, appium_js für Appium JavaScript) und script; project_id übergeben, wenn die App nicht bereits einem Projekt zugeordnet ist. Für einen extern validierten, eigenständigen Maestro-YAML-Flow execution_mode auf browserstack_maestro setzen; andernfalls ist der Standardwert appium_actions. Das YAML-appId muss mit der gespeicherten Paket- oder Bundle-ID der verknüpften App übereinstimmen; ist keine gespeichert, wird sie durch den ersten validierten nativen Flow festgelegt. Platzhalter-App-IDs und verschleierte Android-Ressourcen-IDs werden abgelehnt. Inline-runFlow wird unterstützt, externe Flow-/Skriptdatei-Referenzen werden in v1 jedoch abgelehnt. Native Maestro-Workflows behalten Befehle wie inputRandomText und copyTextFrom sowie Laufzeitausdrücke wie ${maestro.copiedText} und ${output.value} bei. Ein credential_id desselben Projekts kann vollständige inputText-Werte vom Typ ${USERNAME} / ${PASSWORD} bereitstellen. Ein variable_profile_id desselben Projekts kann den Standardwert für referenzierte ${DATA_*}-Werte speichern; jeder referenzierte Schlüssel muss vorhanden sein. Datenprofile dürfen nur synthetische, nicht geheime Daten enthalten.
• import_mobile_script — Ein vorhandenes mobiles Testskript importieren und in eine ausführbare Automatisierung umwandeln, wobei die eigenen Locators des Entwicklers erhalten bleiben, damit Läufe Elemente präzise auflösen. Unterstützte Dialekte: Appium‑Python, WebdriverIO, Maestro (YAML-Flows) und Playwright (Mobile-Web). Verschleierte Android-Ressourcen-ID-Platzhalter werden übersprungen und in der Selector-Zuordnung warnings gemeldet. Nur Android-Apps. Erfordert name, app_id und script; optional target_devices und project_id. Gibt die Automatisierung sowie action_count, erkannte dialect und die Selector-Zuordnung warnings zurück.
• run_mobile_automation — Eine mobile Automatisierung auf einem echten Gerät starten. Erfordert automation_id; optional device, os_version, credential_id und native-Maestro-variable_profile_id. Für Daten variable_profile_id weglassen, um den Automatisierungsstandard zu übernehmen, null übergeben, um kein Profil zu verwenden, oder eine UUID desselben Projekts übergeben, um den Standard zu überschreiben. Jeder referenzierte Schlüssel in ${DATA_*} muss vorhanden sein. Für ein privates Anmeldeprofil ist dessen aktiver Ersteller erforderlich; für ein gemeinsam genutztes Anmeldeprofil ist aktiver Zugriff auf dasselbe Projekt erforderlich. Exakte bekannte Anmeldedatenwerte werden gefiltert; für exakte Datenprofilwerte wird anhand gespeicherter Textbelege eine bestmögliche Filterung vorgenommen. Transformierte, teilweise, kodierte oder aus der App abgeleitete Datenwerte können erhalten bleiben. Autorisierte private Videos/Screenshots bleiben verfügbar und können von der getesteten App dargestellte Werte zeigen. Datenprofile dürfen daher nur synthetische, nicht geheime Werte enthalten. Wenn der Kontext für die Schwärzung von Anmeldedaten nicht verfügbar ist oder die sichere Bereinigung nicht nachgewiesen werden kann, werden detaillierte Texte mit Anmeldedaten zurückgehalten; Status und verfügbare visuelle Belege bleiben erhalten. Für Diagnosen sind Workspace- und Projektberechtigungen erforderlich; Medienlinks laufen nach fünf Minuten ab.
• list_mobile_runs — Autorisierte Ergebnisse mobiler Läufe abrufen (Status, Gerät, Ergebnisübersicht, private Video- und Screenshot-Links, BrowserStack-Sitzung, gefilterte native Maestro-Protokolle und Fehler mit Anmeldedaten, sofern sicher verfügbar, sowie alle automatisch erstellten Bugs). Für Laufdiagnosen werden Workspace-Mitgliedschaft und Projektzugriff geprüft. Optionale Filter: project_id, automation_id, status (queued, running, passed, failed, error, archived) und limit. Archivierte Läufe werden standardmäßig ausgeschlossen.
• create_login_profile — Ein schreibgeschütztes, verschlüsseltes Benutzername-/Passwortprofil erstellen, das von Mobile, Web Automation und Exploratory AI wiederverwendet werden kann. Erfordert project_id, name, username und password; optional ist visibility entweder private (Standard) oder shared. Private Profile sind nur für den Ersteller zugänglich. Gemeinsam genutzte Profile können aktive Mitglieder mit Zugriff auf dasselbe Projekt verwenden.
• create_mobile_credential — Kompatibilitätsname für create_login_profile; verwendet dieselben Eingaben und dieselbe Sicherheitsgrenze.
• list_login_profiles — Nur für den Aufrufer sichtbare Profile auflisten, optional für ein einzelnes project_id. Gibt nicht geheime Metadaten einschließlich visibility zurück; private Profile anderer Benutzer und unzugängliche Projekte werden ausgelassen.
• list_mobile_credentials — Kompatibilitätsname für list_login_profiles; gibt niemals Anmeldedatengeheimnisse zurück.
• update_login_profile — visibility umbenennen, rotieren oder ändern. Der aktive Ersteller kann jedes Feld aktualisieren. Ein aktiver Workspace-Eigentümer/Admin kann ein gemeinsam genutztes Profil umbenennen oder rotieren, aber nicht dessen Sichtbarkeit ändern; private Profile bleiben nur für den Ersteller zugänglich.
• update_mobile_credential — Kompatibilitätsname für update_login_profile; verwendet dieselben Prüfungen für Eigentümerschaft und Projektzugriff.
• delete_login_profile — Soft Delete durch den Ersteller; Wiederherstellung des Lebenszyklus gemeinsam genutzter Profile durch Eigentümer/Admins. Standardwerte für die zukünftige Verwendung werden gelöscht, der Auditverlauf bleibt erhalten.
• delete_mobile_credential — Kompatibilitätsname für delete_login_profile; historische Verweise bleiben für Audits erhalten.
• create_mobile_variable_profile — Wiederverwendbare, projektbezogene synthetische Testdaten mit project_id, name und einem variables-Objekt wie {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"} erstellen. Schlüssel müssen großgeschriebene DATA_*-Bezeichner sein. Profile erlauben 1–100 Zeichenfolgen, 4096 UTF-8-Bytes pro Wert und insgesamt 65536 Bytes. Reservierte Anmeldedaten-/Laufzeitnamen werden abgelehnt. Niemals Anmeldedaten, Tokens, personenbezogene Produktionsdaten oder andere Geheimnisse speichern.
• list_mobile_variable_profiles — Mobile/Both-Profile und ihre lesbaren, nicht geheimen Werte für ein autorisiertes project_id auflisten. Es gelten die Regeln für Projektzuweisungen. Für vorhandene Profile und die mobile Erstellung gilt standardmäßig both; beim Erstellen/Aktualisieren wird platform (mobile oder both) akzeptiert. Web-only-Profile sind vom mobilen Katalogzugriff und der Laufzeitverwendung ausgeschlossen.
• update_mobile_variable_profile — Ein Profil umbenennen oder sein vollständiges variables-Objekt durch id ersetzen. Nur der aktive Ersteller oder ein aktiver Workspace-Eigentümer/Admin darf es aktualisieren.
• delete_mobile_variable_profile — Ein Profil per id soft löschen. Nur der aktive Ersteller oder ein aktiver Workspace-Eigentümer/Admin darf es löschen; Automatisierungsstandards werden gelöscht, historische Laufverweise bleiben erhalten.
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Zeitpläne für echte Geräte auflisten, erstellen und entfernen. Zeitpläne übernehmen den Projektkontext, das Anmeldeprofil und das nicht geheime Variablenprofil der ausgewählten Automatisierung. Für private Anmeldeprofile ist deren aktiver Ersteller erforderlich; für gemeinsam genutzte Anmeldeprofile ist aktiver Zugriff auf dasselbe Projekt erforderlich. Für nicht geheime Variablenprofile gilt weiterhin die Richtlinie für Ersteller oder Eigentümer/Admins. Änderungen und Löschung von Zeitplänen sind auf den aktiven Ersteller des Zeitplans oder einen aktiven Workspace-Eigentümer/Admin beschränkt.

Web-Testdatenkatalog

Derselbe nicht geheime Projektkatalog ist über Automate Web verfügbar. Für diese Tools sind die Berechtigung automation des Workspace und der API-Key-Bereich automations:write erforderlich, auch für Lesezugriffe. Mobile-Zugriff ist nicht erforderlich. Werte werden niemals mit Datensätzen aus verschlüsselten Anmeldeprofilen geteilt. Der Katalog unterstützt noch nicht das Binden oder Injizieren von Profilwerten in Web-Läufe.

• create_web_variable_profile: erforderlich: project_id, name, variables; optional: platform (web oder both), Standardwert web. Verwendet dieselben DATA_*-Grenzwerte wie Mobile. Gibt das Profil einschließlich platform zurück.
• list_web_variable_profiles: erforderlich: project_id; gibt { profiles: [...] } zurück, das nur Web/Both-Datensätze enthält.
• get_web_variable_profile: erforderlich: id; gibt ein zugängliches Web/Both-Profil und dessen synthetische Werte zurück.
• update_web_variable_profile: erforderlich: id; optional: name, vollständiger Ersatz durch variables oder platform (web oder both). Erfordert den aktiven Ersteller oder einen aktiven Workspace-Eigentümer/Admin. Um Both auf Mobile einzuschränken, den Mobile-Katalog mit Mobile-Zugriff verwenden.
• delete_web_variable_profile: erforderlich: id; dieselben Verwaltungsberechtigungen. Führt ein Soft Delete aus und gibt { deleted: true } zurück; der Auditverlauf bleibt erhalten.

Beispiel: Ein Projekt mit list_projects auflösen, create_web_variable_profile mit {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}} aufrufen und anschließend mit list_web_variable_profiles überprüfen. Unzugängliche Projekte/Profile schlagen fehl, ohne ihre Werte offenzulegen; ungültige Daten oder projektweit doppelte Namen werden abgelehnt.

Beispielworkflow — Android

1. list_projects → das Ziel-project_id auflösen
2. upload_mobile_app → die APK in diesem Projekt registrieren
3. Sicher im Dashboard aufzeichnen oder import_mobile_script / create_mobile_automation verwenden
4. list_mobile_automations → die Automatisierung im selben Projekt auflösen
5. run_mobile_automation → sie auf einem echten Gerät ausführen, optional mit einem Anmeldeprofil
6. list_mobile_runs → Status, Ergebnisübersicht, private visuelle Links und BrowserStack-Sitzungsmetadaten prüfen
7. Bei Fehlern werden automatisch Bugberichte mit Fehler-Snapshot und Schrittaufschlüsselung erstellt

Beispielworkflow — iOS

1. upload_mobile_app → die IPA mit project_id für Läufe auf echten Geräten registrieren
2. Den Simulator-Build von .app auf der App-Detailseite hochladen (für Aufzeichnungen)
3. Den Test im Browser aufzeichnen → Aktionen werden vom Simulator erfasst
4. run_mobile_automation → die gespeicherte Automatisierung auf einem iPhone ausführen (verwendet die IPA)
5. update_mobile_app → die IPA durch eine neue Version ersetzen, sobald diese bereit ist

Beispielworkflow — Native Maestro

1. upload_mobile_app → die APK oder IPA im Zielprojekt registrieren
2. create_mobile_credential → optional ein Profil desselben Projekts für einen authentifizierten Flow erstellen
3. create_mobile_variable_profile → optional synthetische DATA_*-Werte desselben Projekts erstellen, die vom Flow verwendet werden
4. create_mobile_automation → einen funktionierenden YAML-Flow mit der exakten Paket-/Bundle-ID appId der verknüpften App, script_type: maestro und execution_mode: browserstack_maestro übergeben. ${USERNAME} / ${PASSWORD} für die Anmeldung und Platzhalter im Stil von ${DATA_EMAIL} für synthetische Eingaben verwenden; Profil-IDs übergeben, um Standardwerte zu speichern.
5. run_mobile_automation → ein kompatibles Gerät auswählen und optional das Anmelde- oder Variablenprofil überschreiben. Das Variablenprofil weglassen, um es zu übernehmen, oder null übergeben, um es für einen einzelnen Lauf zu deaktivieren.
6. list_mobile_runs → autorisierte Erfolgs-/Fehlerübersichten, private Videos/Screenshots, gefilterte Protokolle, echte Schrittnamen, detaillierte Fehler und Sitzungsmetadaten prüfen. Kann für einen Lauf mit Anmeldedaten keine sichere Bereinigung nachgewiesen werden, werden detaillierte Texte zurückgehalten; Status und verfügbare visuelle Belege bleiben erhalten.

Mit KI verfeinern: Die Beta mit Zulassungsliste ist über das Dashboard und REST-Verfeinerungsendpunkte verfügbar. Refine-MCP-Tools sind derzeit noch nicht Teil des öffentlichen Katalogs.

✅

Compliance & Nachweise (Enterprise)

• collect_compliance_evidence — Löst die automatisierte Erfassung von Nachweisen aus verbundenen Diensten (Cloudflare, GitHub, Sentry, Supabase, Railway) aus. Gibt eine Run-ID zurück. Erfasst SSL/TLS-Einstellungen, WAF-Status, Dependabot-Warnungen, Fehlertrends, Deployment-Verlauf und mehr.
• check_config_drift — Prüft alle verbundenen Dienste auf Abweichungen der Sicherheitskonfiguration von den Baselines (SSL-Modus, TLS-Version, HSTS, WAF-Regeln, Sicherheitsheader).
• generate_access_review — Erstellt einen vierteljährlichen Bericht zur Zugriffsüberprüfung. Prüft Teammitglieder, Rollen, MFA-Status und API-Schlüsselverwendung und erstellt Empfehlungen (z. B. inaktive Schlüssel widerrufen).
• get_security_events — Fragt die dienstübergreifende Zeitleiste von Sicherheitsereignissen ab. Filtert nach Quelle (cloudflare, sentry, github) und Schweregrad (critical, high, medium, low, info). Ereignisse werden dienstübergreifend automatisch korreliert.

Compliance-Abdeckung

Diese Tools unterstützen die Compliance-Anforderungen von SOC2 (CC4.1, CC6.1, CC7.2, CC8.1), ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29) und GDPR (Art. 5, 25, 32, 33).

Kompatible Clients

bug Agent funktioniert mit jedem Client, der das Model Context Protocol unterstützt. Hier sind Einrichtungsanleitungen für beliebte Clients:

Öffne Einstellungen → Entwickler → Konfiguration bearbeiten und füge Folgendes hinzu:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Starte Claude Desktop nach dem Speichern neu.

✳️

Cursor

Öffne Einstellungen → MCP-Server → Server hinzufügen oder bearbeite .cursor/mcp.json im Stammverzeichnis deines Projekts:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

🌊

Windsurf

Öffne Einstellungen → MCP → Server hinzufügen oder bearbeite deine MCP-Konfigurationsdatei:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

Füge bug Agent direkt über das Terminal hinzu:

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

Dadurch wird eine direkte Verbindung zum gehosteten Streamable-HTTP-Server hergestellt.

Verwende für Clients, die stdio erfordern, die veröffentlichte bugagent-mcp-Bridge:

• Befehl: npx
• Befehlszeile: npx -y bugagent-mcp
• Argumente: ["-y", "bugagent-mcp"]
• Umgebung: BUGAGENT_API_KEY

Hilfe erhalten

Brauchst du Unterstützung? Wir helfen dir gerne.

Discord-Community

Tritt unserem Discord bei, um Echtzeit-Support zu erhalten und dich mit der Community auszutauschen.

E-Mail-Support

support@bugagent.com — Wir antworten in der Regel innerhalb von 24 Stunden.