MCP — Model Context Protocol
msg.ZenTestAI wird mit einem integrierten MCP-Server ausgeliefert, der es externen KI-Clients (Claude Desktop, Claude Code, Cursor, Windsurf, GitHub Copilot, …) ermöglicht, sich direkt mit Ihrem Tenant zu verbinden und die Plattform zu steuern. Sobald die Verbindung hergestellt ist, kann der KI-Client Tests durchsuchen, ausführen, Ergebnisse prüfen und sogar in Ihrem Namen neue Tests erstellen – unter Verwendung derselben Berechtigungen wie der Benutzer (oder der API-Schlüssel), mit dem er sich authentifiziert.
Es ist keine Tenant-Konfiguration erforderlich, um MCP zu aktivieren – der Server ist immer verfügbar. Die Konfiguration erfolgt auf der Client-Seite: Jedes KI-Tool muss auf den MCP-Endpunkt verwiesen werden und benötigt Anmeldedaten zur Authentifizierung.
Verbindungsdetails
| Feld | Wert |
|---|---|
| Endpunkt | https://<your-msg-zentestai-backend>/mcp |
| Transport | Streamable HTTP (SSE-artiges Fallback ist nicht aktiviert). |
| Auth (Option 1) | HTTP-Header zen-test-api-key: <your tenant API key> — siehe API-Key Konnektivität. |
| Auth (Option 2) | HTTP-Header Authorization: Bearer <OIDC access token> — dasselbe Token, das auch vom Frontend verwendet wird. |
Der API-Key-Flow ist am einfachsten und funktioniert für Headless-CI-Szenarien. Der Bearer-Token-Flow ist erforderlich, wenn die MCP-Sitzung im Namen eines bestimmten menschlichen Benutzers agieren soll (zum Beispiel, um die Produktzuordnungen dieses Benutzers zu übernehmen).
Wie ein Tenant ausgewählt wird
Tools operieren immer auf einem Tenant („Produkt“). Der aktive Tenant wird bei jedem Aufruf in der folgenden Reihenfolge ermittelt:
- Ein explizites
product-Argument, das an das Tool übergeben wird — validiert gegen die zugewiesenen Tenants des Benutzers. - Der einzige zugewiesene Tenant des Benutzers — wird automatisch angewendet, wenn die API-Key-Authentifizierung verwendet wird (ein API-Key ist genau an einen Tenant gebunden).
- Eine zuvor gespeicherte Auswahl über das MCP-Tool
select_product— wird nur verwendet, wenn der Benutzer Zugriff auf zwei oder mehr Tenants hat. - Andernfalls schlägt der Aufruf mit einer klaren Fehlermeldung fehl, die die verfügbaren Tenants auflistet.
Die gespeicherte Auswahl bleibt auch bei Verbindungsabbrüchen und Backend-Neustarts erhalten.
Beispiele zur Client-Konfiguration
Cursor / Windsurf / Claude Code (API-Key)
Fügen Sie Folgendes zur MCP-Konfigurationsdatei Ihres Clients hinzu (z. B. ~/.cursor/mcp.json):
{
"mcpServers": {
"zentestai": {
"url": "https://<backend-host>/mcp",
"headers": { "zen-test-api-key": "<your tenant API key>" }
}
}
}
Cursor / Windsurf / Claude Code (OIDC-Benutzer)
{
"mcpServers": {
"zentestai": {
"url": "https://<backend-host>/mcp",
"headers": { "Authorization": "Bearer <oidc-access-token>" }
}
}
}
Claude Desktop
Claude Desktop unterstützt derzeit nur stdio MCP. Verwenden Sie die mcp-remote-Bridge, um mit einem Remote-HTTP-Server zu kommunizieren:
{
"mcpServers": {
"zentestai": {
"command": "npx",
"args": [
"mcp-remote",
"https://<backend-host>/mcp",
"--header", "zen-test-api-key:<your tenant API key>"
]
}
}
}
Was der KI-Client tun kann
Der MCP-Server stellt eine kuratierte Auswahl an Tools bereit. Diese lassen sich in folgende Gruppen einteilen:
| Gruppe | Beispiele | Was die KI damit tun kann |
|---|---|---|
| Sitzung / Tenant | whoami, list_products, select_product | Herausfinden, wer eingeloggt ist, verfügbare Tenants auflisten und einen Standard-Tenant für zukünftige Aufrufe festlegen. |
| Tests lesen | list_test_definitions, get_test_definition, list_test_sets, get_test_set | Den Testkatalog durchsuchen und einzelne Tests, Parameter und Ausführungsvarianten lesen. |
| Tests verwalten | create_test_definition, update_test_header, add_test_step, update_test_step, delete_test_step, move_test_step, add_execution_variant, update_execution_variant | Neue Tests erstellen und bestehende ändern — einschließlich Schritten, Parametern und Variantenkombinationen. |
| Tests ausführen | execute_test, wait_for_execution, cancel_execution | Ausführungen triggern (optional im interaktiven Modus), auf deren Abschluss warten und bei Bedarf abbrechen. |
| Ergebnisse prüfen | list_executions, get_execution, get_execution_logs, list_execution_screenshots, get_execution_screenshot | Vergangene Ausführungen finden, deren Header/Ergebnisse lesen, das Textprotokoll abrufen und die aufgenommenen Screenshots einsehen. |
| Makros | list_macros, get_macro, create_macro, update_macro | Wiederverwendbare Test-Snippets (Makros) durchsuchen und erstellen, inklusive KI-generierter Geschäftslogik-Signaturen. |
| Agenten | list_agents | Die für den Tenant konfigurierten Testbenutzer (Agenten) auflisten. |
| Interaktive Aufzeichnung | wait_for_interaction, interactive_continue, interactive_add_step, interactive_edit_step, interactive_delete_step, interactive_get_current_step, interactive_get_current_screenshot, interactive_get_frames, interactive_read_accessibility, interactive_run_js, interactive_act_on_node | Während ein Test im interaktiven Modus läuft, kann die KI pausieren, den Live-Browser inspizieren, Aktionen ausprobieren und neue Schritte aufzeichnen. |
Die genaue Liste wird mit dem Backend ausgeliefert und kann mit der Zeit wachsen — der MCP-Client sieht bei der Verbindung immer den aktuellen Satz an verfügbaren Tools.
Sicherheitsmodell
- MCP verwendet die bestehende Authentifizierung wieder. Was auch immer der API-Key oder das Bearer-Token über die REST-API tun darf, darf auch die MCP-Sitzung — nicht mehr und nicht weniger.
- Der initiale
initialize-HTTP-Aufruf ist nicht authentifiziert; ein anonymer Client kann die verfügbaren Tool-Schemas auflisten, aber kein Tool aufrufen. Jeder Tool-Aufruf durchläuft die Authentifizierungsprüfung. - Alle Tenant-Beschränkungen (max. Ausführungen pro Tag, max. KI-Kosten pro Tag, Host-Beschränkung, Bearbeitungssperre) gelten für MCP-Aufrufe genauso wie für REST- und Frontend-Aufrufe.
- Die MCP-Sitzung führt keinen neuen persistenten Status ein, außer der benutzerbezogenen Auswahl des Standard-Tenants. Sie speichert keine Konversationsverläufe, Prompts oder generierten Inhalte.
Tipps
Für geteilte CI/CD-Pipelines oder generische Automatisierung ist der API-Key-Flow zu bevorzugen — er erfordert keine erneute menschliche Authentifizierung und der Schlüssel kann jederzeit auf dem Head-Data-Tab neu generiert werden.
Für entwicklerspezifische Setups (ein KI-Client pro Entwickler) ist der Bearer-Token-Flow zu bevorzugen, damit die KI-Sitzung die Rollen und Tenant-Zuweisungen des Entwicklers übernimmt.
Ein MCP-Client, der über den API-Key verfügt, kann Tests in Ihrem Tenant ausführen, bearbeiten und erstellen. Behandeln Sie den API-Key wie jedes andere Produktions-Credential — speichern Sie ihn in einem Passwort-Manager oder einem Secret Vault und committen Sie ihn niemals in die Quellcodeverwaltung.