bugAgent

offiziell

Verbinde bugAgent mit jedem MCP-kompatiblen KI-Client. Erfasse, klassifiziere und verwalte Bugs, Feature-Anfragen und mehr direkt aus deinem KI-Coding-Assistenten. Kein Kontextwechsel, kein Kopieren und Einfügen – beschreibe einfach das Problem und bugAgent erledigt den Rest.

Was kann man mit bugAgent MCP machen?

Beschreibe einen Fehler in einfachem Englisch und bugAgent erfasst, klassifiziert und verwaltet ihn für dich.

  • Fehler melden und automatisch klassifizieren — Bitte deinen Assistenten, einen Fehler oder eine Feature-Anfrage in natürlicher Sprache zu melden; create_bug_report klassifiziert ihn automatisch in 19 Typen.
  • Berichte auflisten und filtern — Frage nach aktuellen oder kritischen Fehlern in einem Projekt; list_bug_reports filtert nach Projekt, Schweregrad, Status und mehr.
  • Warteschlange übernehmen und bearbeiten — Lass deinen Agenten den nächsten priorisierten Fehler mit pick_next_bug auswählen und ihn atomar über claim_bug beanspruchen.
  • Sicherheits-Scans ausführen — Starte einen Schwachstellen-Scan für eine URL mit run_security_scan und überprüfe die Ergebnisse über get_security_results.
  • Entwickler-Notizen generieren — Bitte um KI-generierte Ursachenanalyse und Lösungsvorschlag über push_to_claude für jeden Fehlerbericht.

Dokumentation

MCP

Verbinde bug_Agent_ mit jedem MCP-kompatiblen KI-Client.

Melde, klassifiziere und verwalte Bugs, Feature-Requests und mehr direkt aus deinem KI-Coding-Assistenten. Kein Kontextwechsel, kein Kopieren-Einfügen – beschreibe einfach das Problem und bug_Agent_ erledigt den Rest.

Discord Community support@bugagent.com

Erste Schritte

Der bug_Agent_ MCP-Server ermöglicht es KI-Clients, über das Model Context Protocol Bug-Reports, Feature-Requests, Verbesserungen und mehr zu erstellen, abzufragen und zu verwalten. Er läuft lokal und kommuniziert mit der Cloud-API von bug_Agent_.

1

API-Schlüssel abrufen

Erstelle ein kostenloses Konto; neue Workspace-Besitzer werden direkt zur API-Schlüssel-Einrichtung geführt. Wiederkehrende Benutzer können einen Schlüssel unter Einstellungen → Entwickler → API-Schlüssel generieren.

2

KI-Client konfigurieren

Füge bug_Agent_ als MCP-Server in der Konfiguration deines Clients hinzu (siehe Einrichtung unten).

3

Mit dem Melden von Bugs beginnen

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

Schnellbeispiel

# 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

Installation

Keine globale Installation erforderlich. Verwende npx, um den MCP-Server bei Bedarf auszuführen:

npx @bugagent/mcp-server

API-Schlüssel konfigurieren

Beim ersten Verbinden fordert bug_Agent_ dich zur Eingabe deines API-Schlüssels auf. Du kannst ihn auch über eine Umgebungsvariable festlegen:

export BUGAGENT_API_KEY=ba_live_your_key_here

Hole deinen API-Schlüssel aus der bug_Agent_-Konsole.

MCP-Client-Konfiguration

Füge Folgendes zur Konfigurationsdatei deines MCP-Clients hinzu:

mcp.json

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "@bugagent/mcp-server"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_your_key_here"
      }
    }
  }
}

💡

Ersetze ba_live_your_key_here durch deinen tatsächlichen API-Schlüssel aus der Konsole.

Verbindung zum Server herstellen

Der bug_Agent_ MCP-Server ist unter https://mcp.bugagent.com/mcp über den Streamable-HTTP-Transport erreichbar. Verbinde dich mit einem der acht unten aufgeführten Clients – wähle den, der am besten zu deinem Workflow passt.

Für eine kleine, kopierfertige Konfiguration, Hinweise zu bereichsbezogenen Schlüsseln und sichere Einstiegsprompts verwende den öffentlichen MCP-Quickstart.

🔑

Hole zuerst deinen API-Schlüssel. Melde dich unter Einstellungen → Entwickler an, klicke auf API-Schlüssel erstellen und kopiere den Wert (beginnt mit ba_live_). Du siehst ihn nur einmal, also speichere ihn an einem sicheren Ort. Jedes Beispiel unten verwendet diesen Schlüssel.

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

Das offizielle Anthropic-Tool. Startet eine lokale Web-UI, in der du jedes Tool durchklicken, Parameter ausfüllen und Antworten sehen kannst. Null Konfiguration, keine IDE erforderlich.

macOS (Terminal)

Terminal

npx @modelcontextprotocol/inspector

Windows (PowerShell oder CMD)

PowerShell

In der sich öffnenden Browser-UI:

  1. Transporttyp: Wähle Streamable HTTP
  2. URL: https://mcp.bugagent.com/mcp
  3. Verbindungstyp: Wähle Proxy (Standard – der Inspector leitet über einen lokalen Node-Prozess weiter, um Browser-CORS zu umgehen)
  4. Klicke auf den Tab Authentifizierung → füge einen benutzerdefinierten Header hinzu:
    • Header-Name: Authorization
    • Wert: Bearer ba_live_YOUR_KEY_HERE
  5. Klicke auf Verbinden. Du siehst alle 110+ bug_Agent_-Tools im linken Bereich.
  6. Klicke auf ein beliebiges Tool (z. B. list_bug_reports), fülle Parameter aus, klicke auf Tool ausführen. Die Antwort wird auf der rechten Seite angezeigt.

Voraussetzungen: Node.js 18 oder höher. Installiere von nodejs.org, falls du es nicht hast.

Option 2 – Claude Desktop (Mac + Windows)

Wenn du die Claude-Desktop-App verwendest, kannst du bug_Agent_ als permanenten MCP-Server hinzufügen. Claude verfügt dann in jedem Gespräch über alle bug_Agent_-Tools.

macOS

  1. Öffne Claude Desktop → Menüleiste Claude → Einstellungen → Entwickler → Konfiguration bearbeiten. Dadurch wird ~/Library/Application Support/Claude/claude_desktop_config.json geöffnet.
  2. Füge den bug_Agent_-Eintrag unter mcpServers hinzu:
    claude_desktop_config.json
{  
  "mcpServers": {  
    "bugagent": {  
      "type": "http",  
      "url": "https://mcp.bugagent.com/mcp",  
      "headers": {  
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"  
      }  
    }  
  }  
}  
  1. Speichere die Datei und beende Claude Desktop vollständig (Cmd+Q, nicht nur das Fenster schließen).
  2. Starte Claude Desktop neu. Das Werkzeug-Hammer-Symbol am unteren Rand des Chat-Eingabefelds sollte nun bug_Agent_-Tools anzeigen.
  3. Teste: Tippe „Liste meine 5 neuesten Bug-Reports auf“ – Claude ruft automatisch list_bug_reports auf.

Windows

  1. Öffne Claude Desktop → Datei → Einstellungen → Entwickler → Konfiguration bearbeiten. 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 das System-Tray (Rechtsklick auf das Claude-Symbol → Beenden) und starte dann neu.
  4. Das Werkzeug-Hammer-Symbol zeigt dann die bug_Agent_-Tools.

Option 3 – Claude Code (CLI)

Wenn du Claude Code über dein Terminal verwendest (die CLI-Version von Claude), registriere den bug_Agent_-Server mit einem Befehl. Funktioniert identisch auf macOS, Linux und Windows.

Terminal / PowerShell

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

Starte dann deine Claude-Code-Sitzung neu. Überprüfe, ob die Verbindung hergestellt ist:

claude mcp list

Du solltest bugagent mit einem grünen Punkt in der Liste sehen. Beginne, Tools in einem beliebigen Chat zu verwenden: „Zeig mir meinen Explorations-Verbrauch für diesen Monat.“

Um es später zu entfernen:

claude mcp remove bugagent

Option 4 – OpenAI Codex CLI

Wenn du die OpenAI Codex CLI verwendest, füge bug_Agent_ zu ~/.codex/config.toml hinzu, um eine dauerhafte Registrierung zu erhalten, oder übergebe die Konfiguration inline für eine einmalige Sitzung.

Dauerhafte Registrierung (zur Konfiguration hinzufügen)

~/.codex/config.toml

[[mcp_servers]]
name = "bugagent"
type = "http"
url  = "https://mcp.bugagent.com/mcp"

[mcp_servers.headers]
Authorization = "Bearer ba_live_YOUR_KEY_HERE"

Inline – eine Sitzung

Terminal

codex \
  --mcp-server '{"name":"bugagent","type":"http","url":"https://mcp.bugagent.com/mcp","headers":{"Authorization":"Bearer ba_live_YOUR_KEY_HERE"}}' \
  "list the last 5 bug reports"

Codex löst Tool-Aufrufe automatisch aus deinem Prompt in natürlicher Sprache auf. Versuche: „Liste meine offenen Bugs sortiert nach Schweregrad auf.“

Option 5 – Cursor (Mac + Windows)

Cursor hat integrierte MCP-Unterstützung. Füge bug_Agent_ einmal hinzu und der KI-Assistent in Cursor kann dann Bugs melden, Reports auflisten, Scans ausführen usw., ohne den Editor zu verlassen.

  1. Öffne Cursor → Einstellungen (Cmd+, auf Mac / Ctrl+, auf Windows) → MCP in der linken Seitenleiste.
  2. Klicke auf + Neuen MCP-Server hinzufügen.
  3. Wähle HTTP als Transporttyp.
  4. Fülle aus:
    • Name: bugagent
    • URL: https://mcp.bugagent.com/mcp
    • Header-Name: Authorization
    • Header-Wert: Bearer ba_live_YOUR_KEY_HERE
  5. Klicke auf Speichern. Cursor zeigt einen grünen Indikator, wenn verbunden.
  6. Öffne den Chat von Cursor (Cmd+L / Ctrl+L) und tippe „Erstelle einen Bug-Report mit dem Titel ‚Login kaputt‘ mit hohem Schweregrad.“ 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 Claude-Desktop-Abschnitt hinzu.

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

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

  1. Installiere die Continue-Erweiterung aus dem VS-Code-Marketplace.
  2. Öffne die Continue-Konfiguration: Befehlspalette (Cmd+Shift+P / Ctrl+Shift+P) → Continue: config.json öffnen. Die Datei befindet sich unter:
    • macOS: ~/.continue/config.json
    • Windows: %USERPROFILE%\.continue\config.json
  3. Füge einen mcpServers-Eintrag hinzu:
    ~/.continue/config.json
{  
  "mcpServers": [  
    {  
      "name": "bugagent",  
      "type": "streamable-http",  
      "url": "https://mcp.bugagent.com/mcp",  
      "requestOptions": {  
        "headers": {  
          "Authorization": "Bearer ba_live_YOUR_KEY_HERE"  
        }  
      }  
    }  
  ]  
}  
  1. Speichere. Continue lädt automatisch neu und zeigt die bug_Agent_-Tools in der Seitenleiste an.
  2. Öffne das Continue-Chat-Panel und versuche: „Liste meine Sicherheitsscans auf.“

Andere VS-Code-Erweiterungen mit MCP-Unterstützung: Cline, Roo Code und Windsurf (Fork) folgen ähnlichen JSON-Konfigurationsmustern mit einem mcpServers-Schlüssel und HTTP-Transport.

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

Einige MCP-Hosts authentifizieren sich über OAuth 2.0 und fragen im Voraus nach einem statischen client_id und client_secret, anstatt einen Bearer-API-Schlüssel zu akzeptieren. Für diese Hosts generierst du ein workspace-bezogenes OAuth-Anmeldedatenpaar aus dem bug_Agent_-Dashboard und fügst es in das Connector-Formular des Hosts ein. Die Anmeldedaten sind MCP-Host-agnostisch – jeder OAuth-Client, der Authorization Code + PKCE unterstützt, kann sie verwenden. Die folgende Anleitung verwendet die Claude.ai-Web-App als häufigstes Beispiel.

  1. In bug_Agent_: Öffne Einstellungen → Entwickler → MCP-Connectors. Klicke auf Connector generieren, gib ihm einen Namen, der den Host beschreibt (z. B. „Claude.ai (Arbeit)“), füge die Redirect-URI ein, die dein MCP-Host benötigt (für die Claude.ai-Web-App ist das https://claude.ai/api/mcp/auth_callback – prüfe für andere die Connector-Dokumentation deines Hosts), und wähle Vertraulich für die Authentifizierungsmethode. Kopiere die client_id und client_secret, die auf dem Erfolgsbildschirm einmalig angezeigt werden.
  2. Füge in den Connector-/OAuth-Einstellungen deines MCP-Hosts 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
      Speziell für Claude.ai: Gehe zu claude.ai/customize/connectors und klicke auf MCP-Connector hinzufügen.
  3. Speichere. Der Host leitet dich zu bug_Agent_ weiter, um dich anzumelden (Google oder E-Mail/Passwort – je nachdem, welche Methode du für das Dashboard verwendest) und die Zustimmung zu erteilen, dann wird der OAuth-Handshake abgeschlossen.
  4. Verwalte und widerrufe generierte Connectors über dieselbe Einstellungsseite. Widerruf ist sofort wirksam – die nächste Anfrage von diesem Connector gibt invalid_client zurück.

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

Option 8 – Direktes HTTP mit curl (Terminal)

Wenn du den Server direkt ohne Client testen oder in ein Skript integrieren möchtest, kannst du den HTTP-Endpunkt mit curl aufrufen. Das MCP-Protokoll ist JSON-RPC 2.0 über Streamable HTTP.

macOS / Linux

Terminal

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

# 1. List all available tools
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":"tools/list"}'

# 2. 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":2,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

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. List all tools
$body = '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" `
  -Method Post -Headers $headers -Body $body

# 2. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 2
  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 kommen als Server-Sent-Events (der MCP-Streamable-HTTP-Standard). Jeder Teil ist eine Zeile mit dem Präfix data:, gefolgt von einem JSON-Objekt. Der Accept: application/json, text/event-stream-Header ist erforderlich – der Server lehnt Anfragen ohne ihn ab.

ℹ️

Fehlerbehebung bei 401 Unauthorized: Überprüfe, ob dein API-Schlüssel nicht unter Einstellungen → Entwickler widerrufen wurde. Schlüssel beginnen mit ba_live_. Wenn du immer noch nicht weiterkommst, generiere den Schlüssel neu und versuche es erneut.

Probier es aus – Prompts in normaler Sprache

Sobald verbunden, musst du keine Tool-Namen oder Parameter kennen. Beschreibe, was du willst, in normaler Sprache und dein KI-Assistent ruft automatisch das richtige bug_Agent_-Tool auf.

Bug-Reports

Frage deinen KI-Assistenten

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 & Leistung

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 & 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?

Schnellreferenz

Konfigurationsdatei-Speicherorte für alle acht Clients. Jeder Client verbindet sich mit https://mcp.bugagent.com/mcp mit dem Header Authorization: Bearer ba_live_YOUR_KEY_HERE über Streamable HTTP.

Client-Konfiguration Speicherort / Befehl

MCP Inspector Keine Datei – URL und Auth-Header in der Browser-UI eingeben, nach npx @modelcontextprotocol/inspector

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 Einstellungen → MCP-UI, oder ~/.cursor/mcp.json

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

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

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

Fehlerbehebung

Symptom Behebung

401 Unauthorized Schlüssel ist falsch, abgelaufen oder widerrufen. Überprüfe Einstellungen → Entwickler – Schlüssel beginnen mit ba_live_. Regeneriere bei Bedarf.

Tools werden im Client nicht angezeigt Beende den Client vollständig und starte ihn nach dem Bearbeiten der Konfiguration neu. Bei Claude Desktop Cmd+Q (nicht nur das Fenster schließen). Bei Cursor überprüfe Einstellungen → MCP auf einen grünen Punkt.

Accept header required Direkte HTTP-Aufrufe müssen Accept: application/json, text/event-stream enthalten – der Streamable-HTTP-Standard verlangt es. Der Server gibt ohne ihn 406 zurück.

Falsche Daten des Workspace Jeder API-Schlüssel ist auf einen Workspace beschränkt. Generiere einen neuen Schlüssel aus dem Workspace, den du abfragen möchtest, unter Einstellungen → Entwickler.

Tools erscheinen, aber Aufrufe scheitern still Überprüfe, ob der Server erreichbar ist: curl -I https://mcp.bugagent.com/health sollte 200 zurückgeben. Falls eine Zeitüberschreitung auftritt, prüfe Netzwerk-/Firewall-Regeln.

MCP-Inspector-CORS-Fehler Wähle Proxy (nicht Direkt) für Verbindungstyp in der Inspector-UI. Der Inspector leitet über einen lokalen Node-Prozess weiter, um Browser-CORS-Beschränkungen zu umgehen.

Codex CLI – Tools nicht erkannt Stelle sicher, dass ~/.codex/config.toml [[mcp_servers]] verwendet (doppelte Klammern, Array-Syntax). Überprüfe, ob die Codex-CLI-Version neu genug ist, um MCP zu unterstützen (codex --version).

MCP-Funktionen

Der bug_Agent_ MCP-Server stellt Werkzeuge für Folgendes bereit:

🐛

Fehlerbericht-Verwaltung

  • create_bug_report — Einen neuen Bericht mit automatischer Klassifizierung über 19 Typen einreichen — Fehler, Feature-Anfragen, Verbesserungen, technische Schulden und mehr (Titel: 3–500 Zeichen). Das optionale attachments-Array akzeptiert base64-codierte Dateien bis zu 400 MB pro Datei: beliebige Bilder, Videos, Audiodateien, PDFs oder Text/JSON. Setzen Sie format_description: true, um die Beschreibung per KI automatisch in eine strukturierte Vorlage umzuformatieren. Übergeben Sie time_spent_seconds, um QA-Aufwand zu erfassen. Übergeben Sie priority (urgent / high / normal / low), um die Fix-Dringlichkeit unabhängig von der Schwere einzustellen. Übergeben Sie is_epic: true, um ein Epic zu erstellen, oder parent_epic_id (UUID/Kurz-ID), um ein Kind-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 Ticket-Präfix), project_id, project_slug, project_prefix, workspace (UUID, exakter Name oder Workspace-Ticket-Präfix), workspace_id/team_id, is_epic, type, severity, status, resolution, root_cause oder reporter_user_id. Jedes Ergebnis enthält mandantenbezogene Personen-/Projektkennungen sowie is_epic, parent_epic_id, parent_epic und begrenzte epic_progress. Berichts-Lesewerkzeuge legen keine Mitglieder-E-Mail-Adressen offen.
  • pick_next_bug — Gibt den/die nächsten Bug(s) zurück, an denen die Agent-Schleife arbeiten soll, in Prioritätsreihenfolge (S1 → S2 → S3, älteste zuerst innerhalb jedes Buckets). Automatisch auf Ihren Workspace begrenzt — gibt Tickets über alle Projekte in Ihrem Team mit status new, awaiting-triage oder confirmed und Schweregrad S1–S3 zurück. Schreibgeschützt — beansprucht Tickets nicht atomar. Optionales severity (einzelne Stufe), limit (1–50, Standard 1). Gibt Zeilen im gleichen Format wie list_bug_reports zurück, für die Werkzeug-Komponierbarkeit. Kombinieren Sie mit claim_bug für das Lese-dann-Beanspruche-Muster.
  • claim_bug — Überführt einen Bug atomar von status new, awaiting-triage oder confirmed zu status='in-progress', setzt assigned_to auf den aufrufenden Benutzer und stempelt claimed_at=NOW(). Wettbewerbssicher bei gleichzeitigen Aufrufen über das Postgres-UPDATE-WHERE-RETURNING-Muster — wenn zwei Agenten claim_bug für dieselbe ID kurz nacheinander aufrufen, erhält genau einer claimed:true mit dem Bug-Inhalt und der andere claimed:false mit einer Grundzeichenkette. Erfolgreiche Antworten enthalten reporter_user_id, reporter_name, assigned_to und assignee_name. Ein pg_cron-Reaper gibt abgelaufene Beanspruchungen (Status=in-progress + claimed_at > 30 Minuten alt) automatisch an new zurück, sodass Tickets eines abgestürzten Agents ohne manuellen Eingriff wieder in die Warteschlange gelangen. Eingaben: id (UUID oder Kurz-ID).
  • get_bug_report — Vollständige Details eines Berichts per UUID oder Workspace-/Projekt-Kurz-ID abrufen. Gibt die Standardfelder für Personen/Projekt/Qualität sowie is_epic, Eltern-Identität, aggregierten Fortschritt und eine begrenzte erste Kind-Seite für Epics zurück.
  • list_epic_children — Kind-Berichte eines Epics paginieren mit id, limit (1–100) und offset. Gibt children, total, has_more und per SQL aggregierte epic_progress zurück, ohne jeden Kind-Bericht zu laden.
  • update_bug_report — Standard-Berichtsfelder sowie is_epic und parent_epic_id aktualisieren. Übergeben Sie parent_epic_id: null, um zu trennen; Neu-Zuordnung/Trennung ist atomar und erfordert eine Autorisierung im selben Workspace und Projekt. Die Beförderung zu einem Epic trennt einen vorhandenen Eltern-Eintrag, während ein Epic mit Kindern nicht herabgestuft werden kann. Bestehende Status-/Auflösungs-/Ursachen- und Zuweisungs-Benachrichtigungsregeln gelten weiterhin.
  • add_comment — Einen Kommentar zu einem Fehlerbericht hinzufügen (UUID oder Kurz-ID, Text 1–10000 Zeichen). Wenn der Bericht mit Jira synchronisiert ist, wird der Kommentar automatisch an das verknüpfte Jira-Ticket übertragen.
  • list_comments — Den vollständigen Kommentarverlauf eines Berichts auflisten, älteste zuerst — jeder Kommentar mit Autorenname, parentId (verschachtelte Antworten) und Zeitstempeln. Kommentare sind nicht Teil von get_bug_report, daher lesen Sie auf diesem Weg die Diskussion zu einem Ticket. Akzeptiert UUID oder Kurz-ID.
  • link_bug_reports — Einen gerichteten semantischen Link zwischen zwei Berichten im selben autorisierten Projekt erstellen. Für parent-of muss der Von-Bericht ein Epic und der Zu-Bericht ein standardmäßiges Kind sein. Bevorzugen Sie parent_epic_id beim Erstellen/Aktualisieren für die Epic-Zuweisung.
  • unlink_bug_reports — Einen zuvor erstellten Fehlerbericht-Link per UUID entfernen (link_id, zurückgegeben von link_bug_reports oder list_bug_report_links).
  • list_bug_report_links — Jeden benutzerkuratierten Link auflisten, der einen Fehlerbericht betrifft. Gibt jeden Link aus der Perspektive des angegebenen Berichts zurück — z. B. wird eine gespeicherte duplicate-of-Zeile, in der dieser Bericht das Ziel ist, als duplicated-by dargestellt; parent-of, in der dieser Bericht das Ziel ist, wird als subtask-of dargestellt; depends-on, in der dieser Bericht das Ziel ist, wird als blocks dargestellt; testing-blocked-by, in der dieser Bericht das Ziel ist, wird als blocks-testing dargestellt. related-to ist symmetrisch. Ergänzt das automatisch erkannte similar_reports-Feld, das von get_bug_report zurückgegeben wird.
  • classify_bug — Eine Beschreibung in einen von 19 Berichtstypen klassifizieren (Fehler, Features, Verbesserungen usw.) mit Konfidenzwert
  • flush_reports — Alte Berichte massenhaft löschen (nur Administratoren)

📊

Nutzung & Analysen

  • get_usage — Nutzung gegen Tariflimits prüfen. API-Key-Aufrufer benötigen usage:read.
  • get_stats — Tägliche Zählungen, Aufschlüsselungen nach Typ/Schweregrad/Status

📁

Projektverwaltung

  • list_projects — Verfügbare Projekte auflisten mit id, name, slug, ticket_prefix, Beschreibung und Standardstatus. Verwenden Sie diese Werte mit create_bug_report und list_bug_reports, 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 (Fehlerberichte, Automatisierungen, Testfälle, Mobile-Apps, Zeitpläne, Geo-Snapshots, Notizen, Zeiterfassungen). Nur Eigentümer/Manager. Das letzte Projekt kann nicht gelöscht werden. Speicher wird automatisch freigegeben
  • export_okf_bundle — Das QA-Wissen eines Projekts exportieren — Fehlerberichte, Testfälle, Automatisierungen sowie Leistungs-, Sicherheits- und explorative Tests — als OKF/OQA-Markdown-Bündel (das Open-Query-Agent-Format, das von oqa.ai verwendet wird). Standardmäßig wird das aktive Projekt verwendet; übergeben Sie das optionale project (Slug oder Name), um ein anderes zu exportieren. Gibt die Liste der Dateien im Bündel sowie das Bündel selbst als base64-codierte ZIP-Datei 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 / update_settings — Einstellungen verwalten

🔑

API-Key-Verwaltung

  • generate_api_key — Einen benannten API-Key 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_team_members — Alle Mitglieder Ihres Workspace mit Rollen, Status und Booster-Flags auflisten
  • invite_team_member — Einen Benutzer per E-Mail einladen (Manager können Mitarbeiter und Manager einladen; nur Eigentümer können Administratoren einladen). Link mit 5 Tagen Ablauf

🎯

Integrationen

  • sync_to_jira — Einen Bericht über die gemeinsame Verbindung des Teams mit Jira synchronisieren
  • push_to_claude — Die Entwickler-Notizen für einen Fehlerbericht generieren (oder neu generieren) — Ursache, vorgeschlagener Fix, Verifikationsschritte und Risikobewertung. Akzeptiert UUID oder Kurz-ID (WRKID-545). Verwendet Plattformschlüssel — keine teameigene Claude-Verbindung erforderlich. Führt eine adaptive Kette aus: drei Schritte bei s3/medium- oder s4/low-Fehlern (Sonnet-Entwurf → OpenAI-gpt-5-Kritik → Sonnet-Synthese), fünf Schritte bei den beiden höchsten Schweregrad-Buckets — s1/critical oder s2/high — (Entwurf → Kritik → Sonnet-Widerlegung → Claude-Opus-Schiedsrichter, der das vollständige Transkript liest und die endgültigen Notizen mit unabhängigem Urteil verfasst). Die Antwort legt jede Runde offen: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model sowie ein debated-Flag. Wenn ein Schritt fehlschlägt, wird auf die nächstbeste Antwort zurückgegriffen. Wird automatisch bei der Bug-Erstellung ausgelöst; normalerweise nur für die manuelle Neugenerierung aufgerufen.
  • analyze_fix_area — Den Unterblock „Wahrscheinlicher Fix-Bereich" der Entwickler-Notizen generieren (oder neu generieren) — eine schmale Sonnet-Ausgabe, die benennt, wo im Codebase der Fix am wahrscheinlichsten liegt. Akzeptiert UUID oder Kurz-ID. Verwendet den Anthropic-Plattformschlüssel. Wenn das Team eine github_connections-Zeile hat und das Projekt ein github_repo zugeordnet hat, wird die Ausgabe auf echte Dateiausschnitte aus dem verbundenen Repository gestützt; andernfalls wird auf allgemeine Anleitung mit einem Hinweis, ein Repository zu verbinden, zurückgegriffen. Gibt likely_fix_area-Text, generated_at, repo_used und ein grounded-Flag zurück. Wird automatisch bei der Bug-Erstellung ausgelöst — Agents müssen dies normalerweise nur für die manuelle Neugenerierung aufrufen.
  • upgrade_plan — Den vertriebsunterstützten Enterprise-Anmeldelink abrufen

Leistungstests

  • create_performance_test — Eine Leistungstest-Konfiguration mit URL, Gerät, virtuellen Benutzern, Dauer, Score-Schwellwert und automatischem Bug-Erstellungs-Schalter erstellen. Nur Enterprise
  • run_performance_test — Einen Seiten-Audit und einen Lasttest für einen Web-Leistungstest auslösen. Gibt eine Ausführungs-ID zur Ergebnisabfrage zurück. Mobile-App-Profiling-Läufe werden über das Dashboard ausgelöst
  • get_performance_results — Vollständige Ergebnisse abrufen, einschließlich Lighthouse-Scores (Leistung, Barrierefreiheit, Best Practices, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) und Lasttest-Metriken (VUs, Anfragen, RPS, p50/p90/p95/p99-Latenzen)
  • list_performance_tests — Alle Leistungstest-Konfigurationen für das aktuelle Team auflisten
  • get_performance_usage — Monatliche Leistungstest-Nutzung prüfen. Leistungstests sind nur für Enterprise verfügbar. Free=0, Enterprise=unbegrenzt

Beispiel-Workflow

  1. get_performance_usage → verbleibendes Kontingent prüfen
  2. create_performance_test → einen Test für Ihre URL konfigurieren
  3. run_performance_test → Audit + Lasttest auslösen
  4. get_performance_results → Scores und Vitals prüfen

🛡

Sicherheits-Scans

  • create_security_scan — Erstellen Sie eine Sicherheits-Scan-Konfiguration. Web-Scans verwenden Quick Scanner + Nuclei (4.000+ Vorlagen) mit drei Tiefenstufen und optionalem authentifiziertem Scannen. Mobile Scans verwenden MobSF für die APK/IPA-Binäranalyse. Konfigurierbare automatische Bug-Erstellung mit Schweregradschwellen. Nur für Enterprise.
  • run_security_scan — Einen Schwachstellen-Scan auslösen. Web-Scans erfordern die Verifizierung einer DNS-Domain. Mobile Scans erfordern eine hochgeladene App. Gibt eine Run-ID zurück, um auf Ergebnisse zu prüfen.
  • get_security_results — Vollständige Ergebnisse abrufen, einschließlich Sicherheitsbewertung (0–100), Erkenntnisse kategorisiert nach Schweregrad (Kritisch, Hoch, Mittel, Niedrig, Info) mit CWE-Referenzen, OWASP-Zuordnungen, Nachweisen und Empfehlungen zur Behebung.
  • list_security_scans — Alle Sicherheits-Scan-Konfigurationen für das aktuelle Team mit letzter Bewertung und Auth-/Tiefen-Abzeichen auflisten.
  • get_security_usage — Monatliche Nutzung der Sicherheits-Scans prüfen. Sicherheits-Scans sind nur für Enterprise. Enterprise = unbegrenzt.
  • list_security_schedules — Alle geplanten Sicherheits-Scans für das Team mit Cron, Zeitzone, aktiviertem Status, nächster Ausführung und Benachrichtigungseinstellungen auflisten. Verknüpft mit der übergeordneten Scan-Konfiguration (Name, scan_type, target_url).
  • create_security_schedule — Einen wiederkehrenden Zeitplan für einen Sicherheits-Scan erstellen. Erfordert scan_id und cron_expression. Ein Zeitplan pro Scan-Konfiguration. Optional timezone, notify_on_fail (keine/E-Mail/Slack/beide), notify_email, slack_channel_id. Jede Ausführung zählt gegen Ihr monatliches Limit; Admin-Benutzer umgehen das Limit. Die Scan-Tiefe wird bei Ausführung immer aus der Scan-Konfiguration gelesen.
  • delete_security_schedule — Einen geplanten Sicherheits-Scan löschen. Betrifft nicht die übergeordnete Scan-Konfiguration oder abgeschlossene Ausführungen.
  1. get_security_usage → verbleibendes Kontingent prüfen
  2. create_security_scan → einen Scan für Ihre URL oder Ihr Repo konfigurieren
  3. run_security_scan → einen einmaligen Schwachstellen-Scan auslösen
  4. create_security_schedule → wiederkehrende Ausführungen automatisieren (z. B. wöchentliches SAST auf dem Hauptbranch)
  5. get_security_results → Erkenntnisse und Behebungsmaßnahmen prüfen

📖

Code-Review

  • list_code_reviews — Aktuelle KI-Code-Reviews für das Team auflisten. Gibt Qualitätsbewertungen, Schweregrad-Anzahlen, PR-Informationen und Zeitstempel zurück. Nur für Enterprise.
  • get_code_review — Ein Code-Review mit allen Erkenntnissen abrufen. Jede Erkenntnis enthält Schweregrad, Kategorie (Bug/Sicherheit/Leistung/Stil/Logik/Wartbarkeit), Titel, Beschreibung, Code-Vorschlag, Dateipfad und Zeilennummern.
  • get_code_review_usage — Code-Review-Nutzung prüfen. KI-Code-Review ist nur für Enterprise; unbegrenzt auf Enterprise.
  • get_code_review_analytics — Review-Analysen abrufen: Trends, Erkenntnis-Kategorien/-Quellen, Schweregrad-Aufschlüsselung, Geschwindigkeitsmetriken, Top-Repos/-Autoren. Unterstützt 7/30/90-Tage-Rückblick.
  1. get_code_review_usage → verbleibende Reviews prüfen
  2. Ein PR im Dashboard unter /dashboard/code-review überprüfen
  3. list_code_reviews → aktuelle Reviews ansehen
  4. get_code_review → Erkenntnisse und Vorschläge abrufen

🔍

Explorative KI

Multi-Agenten-autonomer Website-Bug-Finder mit bis zu 10 parallelen Agenten, die jeweils eine andere Teststrategie verwenden.

  • list_explorations — Explorative-KI-Konfigurationen für das Team auflisten.
  • create_exploration — Eine neue Exploration erstellen. Akzeptiert agent_count (1–10, max. 10), um mehrere parallele Agenten mit einzigartigen Strategien auszuführen: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom.
  • get_exploration — Explorations-Konfiguration mit Agenteneinstellungen, sicheren Authentifizierungsmetadaten und letzten Ausführungen abrufen. Passwörter und Chiffretext werden niemals zurückgegeben.
  • get_exploration_run — Ausführungsergebnisse mit Fortschritt pro Agent, Phasendaten, Erkenntnisse mit Agentenzuordnung (agent_index, agent_strategy) und verknüpften Bugs abrufen.
  • get_exploration_usage — Monatliche Nutzung prüfen. Explorative KI ist nur für Enterprise; Enterprise: unbegrenzt (10 Agenten).
  1. create_exploration mit agent_count: 5 → 5 parallele Agenten konfigurieren
  2. Eine Ausführung über das Dashboard oder über POST /api/explorations/run auslösen
  3. get_exploration_run → auf Fortschritt und Erkenntnisse pro Agent prüfen
  4. Deduplizierte Erkenntnisse mit Agentenzuordnung im Dashboard anzeigen

📝

Notizen

  • list_notes — Notizen mit optionaler Stichwortsuche, Projektfilter, Autorfilter und Datumsbereich auflisten. Gibt Notizen zurück, die der Benutzer besitzt oder die im Team geteilt werden.
  • create_note — Eine Notiz in einem von 5 Formaten erstellen: markdown, plain_text, rich_text, checklist, outline. Setzen Sie visibility auf private oder shared. Automatischer Titel aus den ersten 30 Zeichen, wenn kein Titel angegeben wird. Optionales attachments-Array akzeptiert base64-kodierte Dateien bis zu 400 MB pro Datei: beliebige Bilder, Videos, Audiodateien, PDFs oder Text/JSON. Übergeben Sie time_spent_seconds, um QA-Aufwand zu verfolgen.
  • 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. Übergeben Sie ein attachments-Array, um neue Dateien (max. 400 MB pro Datei) an die vorhandenen Anhänge der Notiz anzuhängen, ohne sie zu ersetzen. Nur der Autor kann aktualisieren. Erfordert id.
  • delete_note — Eine Notiz und ihre Anhänge dauerhaft löschen. Nur der Autor kann löschen. Erfordert id.
  1. create_note → eine Testsitzungs-Notiz starten
  2. update_note → Beobachtungen während des Testens anhängen
  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 (kein FAB-Recording erforderlich). Erfordert name. Optional: target_url (automatisch aus der ersten page.goto(...)-URL im Skript abgeleitet, wenn weggelassen), script (Node.js/JavaScript/TypeScript oder Python — die Sprache wird automatisch erkannt; Standard ist ein Platzhalter), status (draft oder active, Standard: draft), project_id. Gibt die Automatisierungs-id zurück. Enterprise-Plan erforderlich. Tipp — Automatisierung duplizieren: Verwenden Sie get_automation, um das Originalskript abzurufen, und rufen Sie dann create_automation mit name auf "[Copy] Original Name" auf und übergeben Sie das Original script, target_url und project_id. Das Duplikat startet im draft-Status ohne Versionshistorie.
  • list_automations — Playwright-Automatisierungsskripte auflisten. Filtern Sie nach project_id oder status (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 letzten Ausführungen abrufen. Erfordert id. Gibt die Automatisierung mit dem Live-script, einem script_versions-Stack (älteste zuerst, bis zu 100 frühere Einträge, jeder { script, source, timestamp }) und einem recent_runs-Array zurück, wobei jede Ausführung das ausführende script_version_label/script_version_source trägt. Rufen Sie dies vor run_automation auf, wenn Sie eine bestimmte historische Version auswählen müssen.
  • run_automation — Eine sofortige Ausführung eines Playwright-Tests auslösen. Erfordert automation_id. Selbstheilende Locators (automatisch): Wenn eine Locator-Aktion ein Timeout auslöst, fragt der Runner Claude nach einem funktionierenden Selektor und wiederholt den Schritt einmal — Assertions werden nie geheilt, sodass echte Regressionen weiterhin fehlschlagen — und jede Heilung wird im Run-Stdout protokolliert. Virtueller Modus (Standard): optionales device für Viewport-Emulation (z. B. desktop, iphone-15). Live-Modus: Setzen Sie browserstack: true mit bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) und bs_os_version, um in einem echten Desktop-Browser auszuführen. Live-Echtes-Mobil: Setzen Sie bs_os: "android" (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 übergeben Sie den Gerätenamen in bs_os_version. Node.js-Skripte laufen über browserstack-node-sdk (deckt Desktop + Android + iPhone ab). Python-Skripte laufen über browserstack-sdk (pytest-playwright) und decken nur Desktop ab — echtes Mobilgerät über Python wird nicht unterstützt, da browser_type.connect() von pytest-playwright die Echt-Mobil-Endpunkte von BrowserStack nicht ansteuern kann. Video- und Netzwerkprotokolle werden automatisch erfasst; Konsolenprotokolle nur für Desktop. Versions-Wiedergabe: Übergeben Sie optionales version_index (Ganzzahl, 0-indexiert), um einen früheren Eintrag aus der script_versions-Historie der Automatisierung auszuführen. Standard: Wenn version_index weggelassen oder null ist, wird das aktuelle Live-Skript ausgeführt — übergeben Sie keinen Platzhalterwert, um „aktuell" auszuwählen. Werte außerhalb des Bereichs, negative oder nicht-ganzzahlige Werte werden abgelehnt. Der Ausführungsdatensatz speichert den exakt ausgeführten Snapshot, und jeder aus einer fehlgeschlagenen Ausführung automatisch erstellte Bug-Report verlinkt tief auf diese Version im Editor.
  • list_automation_runs — Aktuelle Ausführungen für eine Automatisierung auflisten. Erfordert automation_id. Gibt Ausführungen mit Status, duration_ms und error_message zurück.
  • list_schedules — Alle geplanten Web-Automatisierungsläufe mit Cron, Zeitzone, Gerät und Benachrichtigungseinstellungen auflisten.
  • create_schedule — Einen geplanten Web-Automatisierungslauf erstellen. Erfordert automation_id und cron_expression. Unterstützt Gerät, Zeitzone, notify_on_fail (E-Mail/Slack/beide) und Slack-Kanaloptionen. BrowserStack Live bei geplanten Läufen: Übergeben Sie browserstack: true mit bs_browser, bs_os und bs_os_version — dieselbe Gerätematrix wie bei run_automation (Node = Desktop + echtes Android + echtes iPhone; Python = nur Desktop).
  • delete_schedule — Einen geplanten Web-Automatisierungslauf löschen.
  • list_mobile_schedules — Alle geplanten mobilen Automatisierungsläufe mit Geräten, Cron, Zeitzone und Benachrichtigungen auflisten.
  • create_mobile_schedule — Einen geplanten mobilen Automatisierungslauf auf echten Geräten erstellen. Erfordert automation_id, cron_expression und devices-Array.
  • delete_mobile_schedule — Einen geplanten mobilen Automatisierungslauf löschen.
  • optimize_automation_script — Ein Playwright-Skript an Sonnet 4 zur KI-gestützten Optimierung senden. Wendet eine 12-Punkte-Checkliste an, die Selektoren, Warte-Strategien, Assertions, Fehlerbehandlung, Authentifizierungsmuster, Mobilkompatibilität und Strict Mode behebt. Erfordert automation_id. Die aktuelle Skriptversion wird vor der Optimierung gespeichert. Gibt das optimierte Skript und eine Änderungsübersicht zurück.
  • undo_automation_script — Ein Automatisierungsskript auf seine vorherige Version zurücksetzen. Bis zu 10 vorherige Versionen werden beibehalten. Erfordert automation_id. Gibt das wiederhergestellte Skript und die Anzahl der verbleibenden Versionen zurück.
  1. create_automation → einen Test mit einem benutzerdefinierten Skript erstellen
  2. list_automations → verfügbare Tests durchsuchen
  3. get_automation → das Playwright-Skript inspizieren
  4. run_automation → den Test auslösen
  5. list_automation_runs → Ergebnisse und Dauer prüfen

⏱️

Zeiterfassung

  • list_time_entries — Zeiteinträge für das Team auflisten. Filtern Sie nach period (today, week, month, all), project_id, category und sort (newest, oldest, most_time, least_time). Nur Enterprise-Plan.
  • create_time_entry — Für QA-Aufgaben aufgewendete Zeit protokollieren. Erfordert description, category und duration_minutes. Optional project_id und entry_date festlegen (Standard: heute). Nur Enterprise-Plan.
  • update_time_entry — Einen vorhandenen Zeiteintrag aktualisieren. Erfordert id. Kann description, category, duration_minutes, project_id oder entry_date aktualisieren. Nur Enterprise-Plan.
  • delete_time_entry — Einen Zeiteintrag dauerhaft löschen. Erfordert id. Nur Enterprise-Plan.
  1. create_time_entry → 45 Minuten Regressionstests protokollieren
  2. list_time_entries → die Zeiteinträge dieser Woche anzeigen
  3. update_time_entry → Dauer oder Kategorie anpassen
  4. delete_time_entry → einen falschen Eintrag entfernen

☑️

Testfälle

Testverwaltung mit hierarchischen Ordnern, verschachtelten Suiten (bis zu 3 Ebenen tief mit automatischer Erweiterung von Untersuiten bei Läufen), Drag-and-Drop-Neuordnung und einem Analyse-Reiter „Reports" mit KPI-Trends, Fehleranalyse, Suite-Gesundheit, Abdeckung und Tester-Produktivität. Alle Tools rufen Supabase direkt auf — kein HTTP-Roundtrip, gleiche Latenz wie das Dashboard.

Free-Limits: 10 gespeicherte Testfälle, 1 Suite, 3 Ordner, 128 KB strukturierter Inhalt pro Fall, 2 aktive Workspace-API-Schlüssel und insgesamt 10 Testläufe pro UTC-Kalendermonat. Bis zu 3 dieser Läufe dürfen Hermes oder einen anderen externen Agenten verwenden, mit 1 aktivem externem Lauf und höchstens 10 Fällen pro externem Plan. Free-API-Schlüssel-MCP-Datenverkehr ist auf 30 Anfragen pro Schlüssel und 60 pro Workspace pro Minute begrenzt. Enterprise-Testfallspeicherung und -läufe sind unbegrenzt, vorbehaltlich allgemeiner Plattformschutzmaßnahmen.

KI-Testfallgenerierung, KI-Tag-Vorschläge, Figma-Import und Testfall-Dateianhänge erfordern Enterprise. Die Free-Grenze von 128 KB strukturiertem Inhalt ist getrennt von Enterprise-Dateianhängen. Free kann URL-Referenzen speichern. Die zentralen MCP-Testfall-Tools bleiben auf Free innerhalb der oben genannten Grenzen verfügbar.

Freihändige Ausführung: Die Lauf-Überprüfungsseite ist ein Karussell mit jeweils einem sichtbaren Fall, Tastaturkürzeln (P Bestanden · F Fehlgeschlagen · B Blockiert · S Überspringen) und Sprachsteuerung. Klicken Sie auf das Mikrofon und sagen Sie dann „Pass", „Fail", „Block", „Skip", „Next", „Previous", „Add notes" (wird in das Notizfeld transkribiert), „Save notes" oder „Voice off". Bei erfolgreichen Ergebnissen wird automatisch zum nächsten ungetesteten Fall weitergegangen; bei Fehlschlägen bleibt die Ansicht stehen, damit Tester Details diktieren und einen Bug erstellen können. Funktioniert in Chrome, Edge und Safari.

Fälle & Ordner
  • list_test_cases — Testfälle auflisten mit optionalem search, priority (critical, high, medium, low), type (functional, regression, smoke, integration, performance, security, usability, exploratory), status (active, draft, deprecated) und sort (newest, oldest, name, priority). API-Schlüssel-Aufrufer benötigen test_cases:read.
  • create_test_case — Einen Testfall erstellen. Zwei Vorlagenvarianten: steps (Standard) — Schrittraster mit { action, expected } pro Schritt über das steps-Array; text — einzelne Freiform-Beschreibung über text_content. Beide Felder können im selben Aufruf gesendet werden (die Plattform speichert sie unabhängig voneinander, sodass ein Tester, der später template_type wechselt, keine der beiden Datenseiten verliert). Optionales urls-Array (max. 10 http/https-URLs) fügt Referenzlinks hinzu und ist auf Free verfügbar. Erfordert name. Optional: description, preconditions, template_type, steps, text_content, urls, priority, type, tags, estimated_time (Sekunden). Dateianhänge erfordern Enterprise und werden über den POST /api/test-cases/:id/attachments-Endpunkt des Dashboards (Multipart) hochgeladen — noch nicht als MCP-Tool verfügbar. API-Schlüssel-Aufrufer benötigen test_cases:write.
  • get_test_case — Vollständige Testfalldetails einschließlich Schritten und Ausführungsverlauf abrufen.
  • list_test_case_folders — Die Ordner des Teams auflisten (ein Ordner pro Fall über folder_id; zu unterscheiden von Suiten, die Many-to-Many-Testplangruppierungen sind). Auf 500 begrenzt; berücksichtigt project_id- und parent_folder_id-Filter ("root" für nur oberste Ebene verwenden).
  • create_test_case_folder — Einen Ordner erstellen (verschachtelt bis zu 3 Ebenen über parent_folder_id). bulk_update_test_cases verwenden, um Fälle hinein zu verschieben. API-Schlüssel-Aufrufer benötigen test_cases:write.
  • bulk_update_test_cases — Eine Aktion auf bis zu 500 Fälle gleichzeitig anwenden: set_priority, set_status, set_type, add_tags, remove_tags, add_to_suite, pin, unpin.
  • link_test_case_to_bug — Rückverfolgbarkeit zwischen einem Testfall und einem Bug-Report herstellen (verified_by, covers oder relates).
  • list_test_case_links — Alle Rückverfolgbarkeitslinks für einen Testfall auflisten.
  • list_test_case_review_candidates — Dead-Test-Flags: never_run (90+ Tage seit Erstellung), always_passes (5+ aufeinanderfolgende Bestanden in 90 Tagen), always_skipped (3+ aufeinanderfolgende Überspringungen).
  • mark_test_case_review_flags — Aktuelle Archivkandidaten-Flags auf test_cases.review_flag speichern. Läuft automatisch jeden Montag um 09:00 UTC über pg_cron.
Importe
  • Figma-Import (Enterprise) (Dashboard-UI + REST): Laden Sie einen Zip-Export von Figma-Frames hoch (bis zu 100 MB), Claude analysiert jeden Bildschirm und entwirft Testfälle in einen Ordner Ihrer Wahl oder einen neu erstellten. Mehrstufige Pipeline (Klassifizierung → Fälle pro Bildschirm → flussübergreifende Fälle über Bildschirme mit gemeinsamem Präfix → Selbstkritik) mit Prompt-Caching, 429-Retry und Fehlerisolation pro Frame, sodass ein fehlerhafter Frame den Batch nicht scheitern lässt. Fälle landen als status=active, getaggt mit ai_generated=true, wobei source='figma' und source_frame_name einen Link zum ursprünglichen Frame erhalten. Verwendet den Plattform-Anthropic-Schlüssel — keine teamseitige Claude-Verbindung erforderlich. Endpunkte: POST /api/test-cases/import/figma/request, POST /api/test-cases/import/figma/start, GET /api/test-cases/import/figma/:id.
Suiten & Läufe
  • list_test_suites — Testsuiten mit Projektidentität, Fallanzahl und Status des letzten Laufs auflisten. API-Schlüssel-Aufrufer benötigen test_runs:read.
  • create_test_suite — Eine Suite erstellen. Verschachtelt bis zu 3 Ebenen über parent_suite_id.
  • list_test_runs — Testläufe mit Suite-Name, Bearbeiter und Bestanden/Fehlgeschlagen-Zusammenfassung auflisten.
  • create_test_run — Einen dashboard-verwalteten Suite-Lauf erstellen. Beim Ausführen einer übergeordneten Suite werden automatisch alle Fälle jeder untergeordneten Untersuite einbezogen (ein Fall, der mit beiden verknüpft ist, wird genau einmal hinzugefügt). Jede test_run_results-Zeile zeichnet auf, aus welcher Ursprungs-Untersuite der Fall stammt, sodass Ergebnis-Seiten nach Herkunft gruppieren können.
Externe Agenten-Ausführung

Diese Tools ermöglichen es Hermes oder einer anderen Agenten-Laufzeitumgebung, eine genehmigte Suite auszuführen, ohne das QA-System der Aufzeichnung zu werden. Verwenden Sie einen workspacespezifischen Schlüssel mit nur test_runs:read und test_runs:write. Die Suite liefert die Projektgrenze; Aufrufer können sie nicht überschreiben.

  • start_test_plan — Eine unveränderliche Suite-Momentaufnahme mit stabilem external_run_id starten oder fortsetzen. Eine wiederholte ID gibt den vorhandenen passenden Lauf und die erste Seite zurück, anstatt ein Duplikat zu erstellen.
  • get_test_run_plan — Kanonischen Laufzustand und eine stabile Plan-Seite lesen. Übergeben Sie das vorherige next_cursor; Seiten enthalten standardmäßig 100 Fälle und sind auf 200 begrenzt.
  • report_test_results — 1–200 Ergebnisse mit passed-, failed-, blocked- oder skipped-Status übermitteln. Exakte Wiederholungen sind sicher; der Versuch, einen Fall mit einem anderen Status zu überschreiben, wird abgelehnt.
  • abort_test_run — Einen unterbrochenen Lauf idempotent beenden, während akzeptierte Teilergebnisse und die kanonische Zusammenfassung erhalten bleiben.

Kontingentverhalten: start_test_plan mit demselben external_run_id erneut aufrufen, um den passenden Lauf fortzusetzen, ohne einen weiteren Lauf zu verbrauchen. Das Löschen von Daten setzt die monatliche Laufnutzung nicht zurück.

Laufzeitgrenze: Fall-Momentaufnahmen schließen Anmeldeinformationen, Dateiinhalte und private Anhangspfade aus. Ergebnisbelege sind im MVP Text. Zielanmeldeinformationen bleiben in der Ausführungslaufzeit. Browser-, Modell- und Netzwerkkosten bleiben kundenseitig, und Kunden müssen Zielzugriff und Netzwerkausgang einschränken. Ein Mensch bleibt für Fehler- und Release-Entscheidungen verantwortlich.

Der Hermes-Agenten-Leitfaden verpackt diese Schleife als von bugAgent gepflegte Community-Skill. Das öffentliche Startpaket enthält eine kopierfertige Konfiguration und eine installierbare Skill. Es ist keine offizielle Nous-Research-Integration.

Berichte (Tier-1- + Tier-4-Analysen)
  • get_test_reports_overview — Kern-KPIs für ein Zeitfenster (Bestanden-Quote, abgeschlossene Läufe, ausgeführte Fälle) mit Abweichungen gegenüber dem vorherigen äquivalenten Zeitfenster. Dieselben Zahlen wie im KPI-Streifen des Reiters „Reports".
  • get_test_reports_failures — Vier „Was ist zu beheben?"-Listen: failing_cases (≥50 % fehlgeschlagen, mind. 3 Läufe), flaky_cases (meiste Bestanden/Fehlgeschlagen-Wechsel), failing_suites (≥30 % fehlgeschlagen, mind. 5 Läufe), regressed_cases (letzter Fehlschlag mit früherem Bestanden im Zeitfenster).
  1. create_test_case_folder → eine Ordnerstruktur erstellen (z. B. Smoke → Auth)
  2. create_test_case → Fälle definieren; mit bulk_update_test_cases in Ordner verschieben
  3. create_test_suite → einen Testplan erstellen (Untersuiten optional, bis zu 3 Ebenen tief)
  4. create_test_run → einen menschlich/dashboard-verwalteten Lauf aus einer übergeordneten Suite erstellen — Untersuiten automatisch einbezogen
  5. start_test_plan → einen wiederholungssicheren externen Agenten-Lauf starten oder fortsetzen
  6. get_test_run_plan → jede unveränderliche Plan-Seite abrufen und dann in der gewählten Laufzeitumgebung ausführen
  7. report_test_results → begrenzte Ergebnischargen zurückgeben; abort_test_run aufrufen, wenn die Ausführung nicht sicher fortgesetzt werden kann
  8. get_test_reports_failures → nach Abschluss des Laufs fragen: „Was ist diese Woche zu beheben?"
  9. get_test_reports_overview → den Bestanden-Quote-Trend Woche für Woche verfolgen

Team-Booster

  • scale_team — Skalieren Sie Ihr QA-Team sofort mit Booster-Testern. Konten werden automatisch mit Testerzugriff bereitgestellt. Geben Sie team_size (1–10), location, duration, budget und optional product_url, product_types und tech_levels an. Verfügbar im Enterprise-Plan. Es wird erst nach Genehmigung abgerechnet.
  1. scale_team → 5 Senior-Tester in den USA für 1 Monat bereitstellen
  2. list_team_members → überprüfen, dass neue Tester in Ihrem Team erscheinen
  3. list_reports → Berichte der Booster-Tester prüfen

📱

Mobile-Tests (Enterprise)

Mobile-Ressourcen sind projektbezogen. Übergeben Sie project_id oder einen flexiblen project-Selektor bei Erstellungen, Importen und gefilterten Listen. Automatisierungen erben das Projekt der verknüpften App; andernfalls verwendet der Server das Standardprojekt des Workspace. Ungefilterte Listen können weiterhin legacy Workspace-Ebenen-Zeilen enthalten, bis diese migriert sind.

  • list_mobile_apps — Listet hochgeladene Apps mit optionalen Filtern für project_id/project, platform und limit auf. Gibt die project_id jeder App zurück, damit Agenten nachfolgende Vorgänge im selben Projekt durchführen können.
  • upload_mobile_app — Registriert eine APK- (Android) oder IPA-App (iOS) für Tests auf echten Geräten. Erfordert name, platform (android/ios) und file_url; übergebe project_id, um sie dem aktiven Projekt zuzuweisen. Für iOS die IPA für Real-Geräte-Läufe hochladen und anschließend über das Dashboard einen Simulator-.app-Build für Aufzeichnungen hochladen.
  • update_mobile_app — Ersetzt ein App-Binary durch eine neue Version. Leert gecachte URLs und Simulator-Builds, sodass alle Automatisierungen beim nächsten Lauf die neue Version verwenden. Erfordert app_id und file_url. Optional: version. Wenn verknüpfte Automatisierungen Login-Profile verwenden, muss der Aufrufer für jedes Profil autorisiert sein oder ein aktiver Workspace-Inhaber/Administrator sein; Zeitpläne übernehmen die geschützte Automatisierungsvorgabe.
  • list_mobile_automations — Listet Mobile-Automatisierungen mit optionalen Filtern für project_id/project, app_id, status und limit auf. Die Ergebnisse enthalten project_id und die verknüpfte App-ID.
  • create_mobile_automation — Erstellt ein Testskript. Erfordert name, app_id, script_type (maestro für YAML, appium für Appium Python, appium_js für Appium JavaScript) und script; übergebe project_id, wenn die App nicht bereits projektbezogen ist. Für einen extern validierten, in sich geschlossenen Maestro-YAML-Flow setze execution_mode auf browserstack_maestro; andernfalls ist der Standardwert appium_actions. Die YAML-appId muss mit dem gespeicherten Paket- oder Bundle-ID der verknüpften App übereinstimmen; ist keine gespeichert, legt der erste validierte native Flow sie fest. Platzhalter-App-IDs und verschleierte Android-Ressourcen-IDs werden abgelehnt. Inline-runFlow wird unterstützt, externe Flow-/Skriptdatei-Referenzen werden in v1 jedoch abgelehnt. Natives Maestro erhält Befehle wie inputRandomText und copyTextFrom sowie Laufzeitausdrücke wie ${maestro.copiedText} und ${output.value}. Ein projektgleicher credential_id kann vollständige inputText-Werte von ${USERNAME}/${PASSWORD} liefern. Ein projektgleicher variable_profile_id kann die Vorgabe für referenzierte ${DATA_*}-Werte speichern; jeder referenzierte Schlüssel muss vorhanden sein. Datenprofile sind ausschließlich nicht-geheime synthetische Daten.
  • import_mobile_script — Importiert ein bestehendes mobiles Testskript und macht daraus eine ausführbare Automatisierung, wobei die eigenen Locators des Entwicklers erhalten bleiben, sodass 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 Selektoren-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 Selektoren-Zuordnung warnings zurück.
  • run_mobile_automation — Startet eine Mobile-Automatisierung auf einem echten Gerät. Erfordert automation_id; optional device, os_version, credential_id und natives Maestro-variable_profile_id. Für Daten lasse variable_profile_id weg, um die Automatisierungsvorgabe zu übernehmen, übergib null, um kein Profil zu verwenden, oder übergib eine projektgleiche UUID zur Überschreibung. Jeder referenzierte ${DATA_*}-Schlüssel muss vorhanden sein. Nur der aktive Profilersteller oder ein aktiver Workspace-Inhaber/Administrator darf ein ausgewähltes Profil ausführen. Exakte bekannte Anmeldedatenwerte werden gefiltert und exakte Datenprofilwerte erhalten eine Best-Effort-Filterung aus gespeicherten textuellen Beweisen; transformierte, partielle, kodierte oder von der App abgeleitete Datenwerte können verbleiben. Autorisierte private Videos/Screenshots bleiben verfügbar und können von der getesteten App gerenderte Werte zeigen. Daher dürfen Datenprofile nur synthetische, nicht geheime Werte enthalten. Wenn kein Anmeldedaten-Schwärzungskontext verfügbar ist oder die Sicherheit der Bereinigung nicht nachgewiesen werden kann, werden detaillierte Anmeldedatentexte zurückgehalten, während Status und verfügbare visuelle Beweise erhalten bleiben. Diagnosen erfordern Workspace- und Projektautorisierung; Medienlinks laufen nach fünf Minuten ab.
  • list_mobile_runs — Ruft autorisierte Mobile-Laufergebnisse ab (Status, Gerät, Ergebniszusammenfassung, private Video- und Screenshot-Links, BrowserStack-Sitzung, gefilterte native Maestro-Protokolle mit Anmeldedaten und Fehler, sofern sicher verfügbar, sowie jeden automatisch erstellten Fehler). Workspace-Mitgliedschaft und Projektzugriff werden für Laufdiagnosen erzwungen. Optionale Filter: project_id, automation_id, status (queued, running, passed, failed, error, archived) und limit. Archivierte Läufe sind standardmäßig ausgeschlossen.
  • create_mobile_credential — Erstellt ein benanntes Login-Profil (z. B. „Admin", „Contributor") für ein Projekt: einen Benutzernamen + ein Passwort, die von Mobile-Automatisierungen verwendet werden. Beide Werte werden AES-256-GCM-verschlüsselt gespeichert und sind nur schreibbar — kein Tool oder API gibt sie jemals zurück, und andere Mitglieder/die Benutzeroberfläche sehen nur den Namen. Nur das aktive Workspace-Mitglied, das es erstellt hat, oder ein aktiver Workspace-Inhaber/Administrator kann es binden, ausführen, rotieren oder löschen. Erfordert project_id, name, username, password. Nur Enterprise.
  • list_mobile_credentials — Listet Login-Profile auf (optional ein project_id). Gibt nur nicht-geheime Felder zurück (id, name, Projekt, Ersteller, Erstellungsdatum) — niemals Benutzername oder Passwort. Verwende die zurückgegebene id als Anmeldedatenauswahl beim Ausführen einer Automatisierung.
  • update_mobile_credential — Benennt ein Login-Profil um oder rotiert dessen Benutzernamen/Passwort über id. Nur Felder angeben, die geändert werden sollen. Neue geheime Werte werden sofort verschlüsselt und niemals zurückgegeben. Nur das aktive Workspace-Mitglied, das das Profil erstellt hat, oder ein aktiver Workspace-Inhaber/Administrator darf es aktualisieren.
  • delete_mobile_credential — Löscht ein Login-Profil per Soft-Delete über id. Nur das aktive Workspace-Mitglied, das das Profil erstellt hat, oder ein aktiver Workspace-Inhaber/Administrator darf es löschen. Es bleibt für Audit- und Laufverlauf erhalten, ist aber nicht mehr nutzbar oder aufgelistet; Automatisierungsvorgaben werden geleert und der Name wird wiederverwendbar.
  • create_mobile_variable_profile — Erstellt wiederverwendbare, projektbezogene synthetische Testdaten mit project_id, name und einem variables-Objekt wie {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Schlüssel müssen DATA_*-Bezeichner in Großbuchstaben sein. Profile erlauben 1-100 Strings, 4096 UTF-8-Bytes pro Wert und insgesamt 65536 Bytes. Reservierte Anmeldedaten-/Laufzeitnamen werden abgelehnt. Speichere niemals Anmeldedaten, Token, personenbezogene Produktionsdaten oder andere Geheimnisse.
  • list_mobile_variable_profiles — Listet Profile und ihre lesbaren nicht-geheimen Werte für eine autorisierte project_id auf. Projektzuweisungsregeln gelten.
  • update_mobile_variable_profile — Benennt ein Profil um oder ersetzt dessen vollständiges variables-Objekt über id. Nur der aktive Ersteller oder ein aktiver Workspace-Inhaber/Administrator darf es aktualisieren.
  • delete_mobile_variable_profile — Löscht ein Profil per Soft-Delete über id. Nur der aktive Ersteller oder ein aktiver Workspace-Inhaber/Administrator darf es löschen; Automatisierungsvorgaben werden geleert, während historische Laufreferenzen erhalten bleiben.
  • list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Listet Zeitpläne für echte Geräte auf, erstellt und entfernt sie. Zeitpläne übernehmen Projektkontext, Login-Profil und nicht-geheimes Variablenprofil von ihrer ausgewählten Automatisierung. Ein Zeitplan, der eines der geschützten Profile verwendet, erfordert den aktiven Profilersteller oder einen aktiven Workspace-Inhaber/Administrator; Zeitplanänderungen und -löschungen sind auf den aktiven Zeitersteller oder einen aktiven Workspace-Inhaber/Administrator beschränkt.

Beispiel-Workflow — Android

  1. list_projects → die 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 → auf einem echten Gerät auslösen, optional mit einem Login-Profil
  6. list_mobile_runs → Status, Ergebniszusammenfassung, private visuelle Links und BrowserStack-Sitzungsmetadaten prüfen
  7. Fehler erzeugen automatisch Fehlerberichte mit Fehlerschnappschuss und Schrittaufschlüsselung

Beispiel-Workflow — iOS

  1. upload_mobile_app → deine IPA mit project_id für Real-Geräte-Läufe registrieren
  2. Simulator-.app-Build auf der App-Detailseite hochladen (für Aufzeichnungen)
  3. Test im Browser aufzeichnen → Aktionen werden vom Simulator erfasst
  4. run_mobile_automation → die gespeicherte Automatisierung auf einem iPhone auslösen (verwendet die IPA)
  5. update_mobile_app → IPA durch neue Version ersetzen, wenn bereit

Beispiel-Workflow — Natives Maestro

  1. upload_mobile_app → die APK oder IPA im Zielprojekt registrieren
  2. create_mobile_credential → optional ein projektgleiches Profil für einen authentifizierten Flow erstellen
  3. create_mobile_variable_profile → optional projektgleiche synthetische DATA_*-Werte erstellen, die der Flow verwendet
  4. create_mobile_automation → einen bekannten funktionierenden YAML-Flow mit der exakten Paket-/Bundle-appId der verknüpften App, script_type: maestro und execution_mode: browserstack_maestro übergeben. ${USERNAME}/${PASSWORD} für den Login und ${DATA_EMAIL}-artige Platzhalter für synthetische Eingaben verwenden; Profil-IDs übergeben, um Vorgaben zu speichern.
  5. run_mobile_automation → ein kompatibles Gerät auswählen und optional das Login- oder Variablenprofil überschreiben. Das Variablenprofil weglassen, um es zu übernehmen, oder null übergeben, um es für einen Lauf zu deaktivieren.
  6. list_mobile_runs → autorisierte Bestanden-/Fehlgeschlagen-Zusammenfassungen, private Videos/Screenshots, gefilterte Protokolle, echte Schrittnamen, detaillierte Fehler und Sitzungsmetadaten prüfen. Wenn für einen Lauf mit Anmeldedaten keine sichere Bereinigung festgestellt werden kann, werden detaillierte Texte zurückgehalten, während Status und verfügbare visuelle Beweise erhalten bleiben.

Mit KI verfeinern: die auf der Allowlist stehende Betaversion ist über das Dashboard und REST-Verfeinerungsendpunkte verfügbar. Es sind noch keine Refine-MCP-Tools Teil des öffentlichen Katalogs.

Compliance & Nachweise (Enterprise)

  • collect_compliance_evidence — Löst die automatisierte Beweiserfassung von verbundenen Diensten aus (Cloudflare, GitHub, Sentry, Supabase, Railway). Gibt die Lauf-ID zurück. Erfasst SSL/TLS-Einstellungen, WAF-Status, Dependabot-Warnungen, Fehlertrends, Bereitstellungsverlauf und mehr.
  • check_config_drift — Prüft alle verbundenen Dienste auf Sicherheitskonfigurationsabweichungen von den Baselines (SSL-Modus, TLS-Version, HSTS, WAF-Regeln, Sicherheitsheader).
  • generate_access_review — Erstellt einen vierteljährlichen Zugriffsprüfungsbericht. Prüft Teammitglieder, Rollen, MFA-Status, API-Schlüsselnutzung und generiert Empfehlungen (z. B. inaktive Schlüssel widerrufen).
  • get_security_events — Fragt die dienstübergreifende Sicherheitsereignis-Zeitleiste ab. Filtere nach Quelle (cloudflare, sentry, github) und Schweregrad (critical, high, medium, low, info). Ereignisse werden automatisch über Dienste hinweg korreliert.

Compliance-Abdeckung

Diese Tools unterstützen bei SOC2-Anforderungen (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:

🤖

Claude Desktop

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

claude_desktop_config.json

Starte Claude Desktop nach dem Speichern neu.

✳️

Cursor

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

.cursor/mcp.json

🌊

Windsurf

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

mcp_config.json

💻

Claude Code (CLI)

Füge bug_Agent_ direkt aus dem Terminal hinzu:

claude mcp add bugagent -- npx -y @bugagent/mcp-server

Setze deinen API-Schlüssel mit export BUGAGENT_API_KEY=ba_live_..., bevor du startest.

🔧

Andere MCP-Clients

Jeder Client, der den MCP-stdio-Transport unterstützt, funktioniert mit bug_Agent_. Verwende die Standardkonfiguration:

  • Befehl: npx
  • Argumente: ["-y", "@bugagent/mcp-server"]
  • Env: BUGAGENT_API_KEY

CLI

Erste Schritte mit CLI

Die bug_Agent_ CLI gibt Ihnen volle Kontrolle über Fehlerberichte, Feature-Anfragen, Projekte und Integrationen von Ihrem Terminal aus. Verwenden Sie sie, um:

  • Automatisieren Sie Workflows — Integrieren Sie Fehlerberichte in CI/CD-Pipelines, Skripte und Cron-Jobs
  • Massenoperationen — Listen, filtern und verwalten Sie Berichte, ohne Ihr Terminal zu verlassen
  • Pipe-freundliche Ausgabe — JSON-, YAML- und Rohformate zum Kombinieren mit jq, yq und anderen Tools
  • Schnelle Iteration — Kein Browser nötig — erstellen und aktualisieren Sie Berichte in Sekunden

Installation

npm install -g @bugagent/cli

Überprüfen Sie die Installation:

bugagent --version

Authentifizierung

Legen Sie Ihren API-Schlüssel als Umgebungsvariable fest:

Oder übergeben Sie ihn direkt mit dem --api-key-Flag:

bugagent reports list --api-key ba_live_your_key_here

🔑

Holen Sie Ihren API-Schlüssel aus der bug_Agent_-Konsole. Schlüssel beginnen mit ba_live_.

Für dauerhafte Authentifizierung fügen Sie den Export zu Ihrem Shell-Profil hinzu (~/.bashrc, ~/.zshrc, usw.).

Verwendung

Befehle folgen dem Muster:

bugagent <resource> <action> [flags]

Ressourcen können auch die Doppelpunkt-Syntax für Unterressourcen verwenden:

bugagent reports comments add --report-id WRKID-545 --body "Reproduced on v2.1"

Verwenden Sie --help bei jedem Befehl für Details:

bugagent reports --help
bugagent reports create --help

Beispielsitzung

Terminal

# List your projects
bugagent projects list

# Create a bug report in your default project
bugagent reports create \
  --title "Checkout 500 on discount code" \
  --description "Applying SAVE20 returns HTTP 500" \
  --severity critical \
  --type logic

# View recent reports
bugagent reports list --limit 5 --format pretty

# Get full details on a report (use the short ID or UUID)
bugagent reports get WRKID-545

# Sync a report to Jira
bugagent jira sync --report-id WRKID-545

# Check your usage
bugagent usage get --format json

CLI-Funktionen

Die CLI bietet Befehle für:

reports Erstellen, auflisten, abrufen, aktualisieren und leeren von Fehlerberichten

projects Erstellen, auflisten, aktualisieren und löschen von Projekten

keys Generieren, auflisten, neu generieren und widerrufen von API-Schlüsseln

jira Verbinden, Berichte synchronisieren und Jira-Einstellungen konfigurieren

usage Aktuelle Nutzung gegen Planlimits prüfen

stats Analysen und Aufschlüsselungen anzeigen

profile Profil und Einstellungen anzeigen und aktualisieren

auth Anmelden, registrieren und Anmeldeinformationen verwalten

Globale Flags

Flag Beschreibung

--api-key <key> API-Schlüssel für diesen Befehl überschreiben

--format <fmt> Ausgabeformat: json, yaml, pretty, raw

--debug Anzeigen von Anfrage-/Antwortdetails zur Fehlerbehebung

--help Hilfe für jeden Befehl anzeigen

--version CLI-Version ausgeben

Ausgabeformate

Die CLI unterstützt mehrere Ausgabeformate für verschiedene Anwendungsfälle:

json

Maschinenlesbares JSON. Ideal zum Weiterleiten an jq oder andere Tools.

yaml

Menschenfreundliche YAML-Ausgabe für Konfigurationsdateien und Lesbarkeit.

pretty

Standard. Farbige, formatierte Ausgabe für das Terminal.

raw

Unformatierte Ausgabe. Nützlich für Skripte und Automatisierung.

Filtern mit --transform

Verwenden Sie --transform mit GJSON-Syntax, um Ausgabedaten abzufragen und zu filtern:

# Default pretty output
bugagent reports list

# JSON for piping to other tools
bugagent reports list --format json

# YAML
bugagent reports list --format yaml

# Raw (no formatting)
bugagent reports get rpt_abc123 --format raw

# Filter with GJSON syntax
bugagent reports list --format json \
  --transform "items.#(severity==critical).title"

KI-Fähigkeit

Die CLI ist auch als AgentSkill verfügbar, sodass KI-Codierungsassistenten bug_Agent_ in Ihrem Namen verwenden können.

Was ist ein AgentSkill?

AgentSkills ermöglichen KI-Codierungsassistenten (Claude Code, Cursor usw.), CLI-Tools kontextbezogen aufzurufen. Die bug_Agent_-Fähigkeit gibt Ihrem KI-Assistenten die Möglichkeit, Fehler zu melden, Projektstatus zu prüfen und mit Jira zu synchronisieren – ganz ohne dass Sie einen Befehl eingeben.

Installieren Sie den Skill

claude skills install bugagent --from @bugagent/mcp-server

Nach der Installation kann der kontextbewusste KI-Assistent bug_Agent_-Befehle natürlich verwenden – mit vollständiger Kenntnis Ihres Produkts, Ihrer Testrichtlinien und hochgeladener Dokumentation:

KI-Assistent-Prompt

"File a critical bug: the payment webhook is returning
a 403 after the latest deploy. It affects all Stripe
events. Assign it to the payments project."

Die Fähigkeit übersetzt die natürliche Sprache in die entsprechenden CLI-Befehle und führt sie aus.

🎬

Session-Replay + KI-Assistent: Wenn Session-Replay aktiviert ist (Enterprise-Plan), kann der KI-Assistent auf die erfasste Benutzersitzung verweisen – Klicks, Navigation, Fehler und Netzwerkfehler der letzten 60 Sekunden – um automatisch umfassendere, genauere Fehlerberichte mit vollständigem Reproduktionskontext zu erstellen.

Hilfe erhalten

Benötigen Sie Hilfe? Wir sind für Sie da.

Discord-Community

Treten Sie unserem Discord bei für Echtzeit-Support und Community-Diskussionen.

E-Mail-Support

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