QA Copilot MCP Server

Ein Model Context Protocol-Server, der einer KI-Assistenz einen kleinen Satz konkreter QA-/Testanalyse-Werkzeuge an die Hand gibt, statt sie raten zu lassen: einen Playwright-Lauf zusammenfassen, flaky Tests über mehrere Läufe finden, einen Fehlschlag heuristisch erklären, ein Playwright-Testgerüst erzeugen und den aktuellen CI-Status eines GitHub-Repos abrufen. Richtet man Claude Desktop, Claude Code oder einen anderen MCP-kompatiblen Host auf den Server aus, werden daraus echte Tool-Aufrufe statt Freitext-Vermutungen.

Es ist das „Gib der KI echte Daten, keine Bauchgefühle"-Stück eines QA-Automations-Portfolios: Die anderen Repos dieses Portfolios (healthcare-qa-automation-framework, healthcare-data-quality-framework) erzeugen Playwright-JSON-Reports und CI-Läufe; dieser Server macht daraus etwas, das eine Assistentin bzw. ein Assistent tatsächlich abfragen kann.

Warum es so aufgebaut ist

• Die Protokoll-Anbindung ist eine dünne Schicht über gewöhnliche Funktionen. Die eigentliche Logik jedes Tools lebt in src/playwright/, src/github/ und src/tools/ als kleine, weitgehend pure, unabhängig unitgetestete Module. src/index.ts registriert sie nur mit dem MCP-SDK – der fehleranfällige Teil (Report-Parsing, Flaky-Erkennung, Heuristiken) ist also durch schnelle Unit-Tests abgedeckt, die Protokoll-Verdrahtung durch einen separaten End-to-End-Smoke-Test (weiter unten).

• GitHub-Zugriff ist pluggbar – nach demselben Muster wie die LLM-Integrationen im übrigen Teil dieses Portfolios. GitHubClient ist ein Interface; RealGitHubClient kapselt fetch gegen die GitHub-REST-API, FakeGitHubClient liefert vorgefertigte Daten. Dadurch ist get_repo_ci_status offline vollständig unit-testbar, während der echte Client echter, lauffähiger Code ist – ein MCP-Host auf dem Rechner einer Entwicklerin oder eines Entwicklers hat ganz normalen Internetzugang, selbst in Umgebungen, die keinen haben (wie der eigenen CI-Sandbox dieses Repos).

• Die Teststub-Generierung ist bewusst deterministisch und nicht LLM-basiert. Bei einer benannten Sequenz von data-testid-Interaktionen erzeugt generate_playwright_test_stub immer genau dieselbe Ausgabe – sofort, kostenlos, reproduzierbar. Für einen anderen Zweck gibt es ein eigenes Projekt: Testfälle aus einer Spezifikation oder User Story zu erzeugen, wo ein LLM tatsächlich Mehrwert bringt.

• Ein Smoke-Test auf Protokollebene, nicht nur Unit-Tests. smoke-test.mjs startet den gebauten Server als echten Kindprozess und steuert ihn mit dem offiziellen MCP-Client über stdio – tools/list, dann ein tools/call pro Tool. Damit beweist CI das einen echten Wire-Protokolle ebenso wie nur die Funktionen dahinter.

Related MCP server: playwright-fixer-mcp

Tools

Architektur

src/
  index.ts                    MCP server: registers all 5 tools, connects over stdio
  playwright/reportParser.ts  Pure Playwright-JSON parsing: summarizeReport, findFlakyTests
  github/githubClient.ts      GitHubClient interface + RealGitHubClient (fetch) + FakeGitHubClient
  tools/
    explainFailure.ts         Heuristic pattern-matching (ported from the triage_failure.py
                               script in healthcare-qa-automation-framework)
    generateTestStub.ts       Deterministic Playwright test-file template generator
    getRepoCiStatus.ts        Wraps GitHubClient into pass/fail/in-progress counts
test/                         Vitest unit tests for every module above
fixtures/                     Sample Playwright JSON reports (3 runs, used for flaky-test tests)
smoke-test.mjs                End-to-end MCP protocol smoke test (real child process, real client)
.github/workflows/ci.yml      Type-check, unit tests, build, protocol smoke test

Tech-Stack

TypeScript · Node.js · @modelcontextprotocol/sdk · Zod · Vitest · GitHub REST API · GitHub Actions

Lokale Ausführung

npm install
npm run build       # compiles to dist/
npm test            # unit tests (27 tests, fully offline)
npm run smoke        # builds, then drives the real server over stdio via the MCP client

Verwendung über einen MCP-Host

Richten Sie einen beliebigen MCP-kompatiblen Client auf den gebauten Server, z. B. in Claudes claude_desktop_config.json:

{
  "mcpServers": {
    "qa-copilot": {
      "command": "node",
      "args": ["/absolute/path/to/qa-copilot-mcp-server/dist/index.js"]
    }
  }
}

Setzen Sie GITHUB_TOKEN in der Umgebung, um das unauthentifizierte GitHub-Ratenlimit für get_repo_ci_status anzuheben (60 Anfragen pro Stunde ohne Token, 5.000 pro Stunde mit Token) – für gelegentliche Nutzung funktioniert es auch ganz ohne Token.

CI

Jeder Push und Pull-Request auf main läuft einen einzigen Job: Typprüfung (tsc --noEmit), die Unit-Test-Suite (vitest run), ein Produktions-Build und den Smoke-Test auf Protokoll-Ebene (node smoke-test.mjs) gegen die gebaute Ausgabe. CI setzt nirgendwo Netzwerkzugang voraus oder benötigt ihn – get_repo_ci_status wird in den Unit-Tests nur gegen FakeGitHubClient ausgeführt, und der Smoke-Test wertet ein netzwerkfreies Ergebnis von get_repo_ci_status als Erfolg, solange der Server es sauber über den isError-Kanal des MCP weitergibt statt abzustürzen.

Was das hier nicht ist

Das ist kein Allzweck-GitHub- oder CI-Dashboard – es ist ein kleine, fokussierte Sammlung von Tools, die gezielt für die Playwright-Berichts- und GitHub-Actions-Formate gebaut wurde, die die anderen Repos dieses Portfolios tatsächlich erzeugen. Es soll zeigen, wie eine KI-Assistenz mit realen, überprüfbaren Testdaten verbunden wird, statt von ihr zu verlangen, Testergebnisse aus einer Paraphrase zu erraten.