MCP-Server als unsichtbarer QA-Engineer: Wie KI-Systeme Datenlücken entdeckt

Fast jedes SaaS-Unternehmen verlässt sich auf Unit-Tests, um die Funktionsfähigkeit seiner Software zu sichern. Doch was passiert, wenn die eigentlichen Daten inkonsistent sind – selbst wenn der Code fehlerfrei läuft? Genau diese Frage stellte sich ein Team, nachdem es seinen MCP-Server mit über 700 Tests konfrontierte. Das Ergebnis war eine überraschende Erkenntnis: Künstliche Intelligenz kann als stiller QA-Engineer agieren, indem sie Produktionsdaten systematisch analysiert.

Warum klassische Tests an Grenzen stoßen

Unit-Tests überprüfen, ob der Code das tut, was der Entwickler geschrieben hat. Sie prüfen jedoch nicht, ob die Daten, mit denen das System arbeitet, tatsächlich Sinn ergeben. Genau hier setzt die Stärke eines MCP-Servers an, der mit einer KI wie Claude verbunden ist. Während Entwickler typischerweise prüfen, ob ein System eine Rechnung erstellen kann, fragt die KI: „Zeige mir alle Transaktionen ohne Kategorie“ oder „Welche Rechnungen sind seit über 30 Tagen im Status ‚Gesendet‘?“. Solche Abfragen decken Lücken auf, die in herkömmlichen Testverfahren unsichtbar bleiben.

Ein konkretes Beispiel: Das Team entdeckte Transaktionen, die zwar erfasst, aber nie kategorisiert wurden. Solche Datenfehler sind keine Code-Bugs, sondern resultieren aus menschlichen oder systemischen Versäumnissen. Kein Unit-Test hätte dies vorhersehen können – denn die Daten selbst waren zunächst korrekt erfasst worden.

Kreuzdomänen-Checks: Die Stärke der KI-basierten QA

Die wahre Innovation liegt in der Fähigkeit der KI, Daten über verschiedene Domänen hinweg zu analysieren. Während klassische Tests oft isoliert funktionieren, kombiniert die KI Informationen aus mehreren Systemen. Folgende Checks wurden regelmäßig durchgeführt:

• Stecken gebliebene Statusmaschinen

„Welche Rechnungen sind seit über 30 Tagen im Status ‚Gesendet‘?“ Die KI filtert Rechnungen nach Status und überprüft die Daten. Ein Rechnungsstatus, der nicht automatisch in „Überfällig“ wechselt, deutet auf ein Problem im Hintergrundprozess, eine gelöschte Client-Datensatz oder einen Zeitzonenfehler hin.

• Saldenabstimmung

„Stimmt der Bankkontostand mit der Summe aller Transaktionen überein?“ Die KI vergleicht den aktuellen Saldo mit den verbuchten Transaktionen. Abweichungen deuten auf fehlende Importe oder fehlerhafte Synchronisationen hin – Probleme, die jedes Teilsystem für sich genommen bestehen könnte, die aber erst im Zusammenspiel sichtbar werden.

• Einnahmenkonsistenz

„Stimmt die Summe aller fakturierten Einnahmen mit den verbuchten Zahlungseingängen überein?“ Hier werden Rechnungsbeträge mit den tatsächlichen Zahlungstransaktionen abgeglichen. Unstimmigkeiten können auf fehlende Buchungen oder nicht zugeordnete Zahlungen hindeuten.

• Geisterreferenzen

„Welche Produkte werden in Rechnungen referenziert, obwohl sie bereits archiviert sind?“ Ein archiviertes Produkt sollte nicht mehr in aktiven Rechnungen erscheinen. Falls doch, deutet dies auf ein Problem bei der Löschkaskade oder einen Race-Condition-Fehler hin.

• Inaktive Clients

„Welche Clients haben in den letzten sechs Monaten keine Rechnung erhalten?“ Diese Abfrage ist kein Fehler, sondern ein geschäftlicher Insight – doch das zugrundeliegende Muster (kombinierte Filter über mehrere Domänen) gleicht den zuvor genannten Checks.

722 Tests: Die unerwarteten Erkenntnisse

Um die Leistungsfähigkeit des MCP-Servers systematisch zu überprüfen, führte das Team 722 Akzeptanztests durch. Jeder Test deckte nicht nur den „Happy Path“ ab, sondern auch Fehlerbehandlungen, Grenzwertfälle und E2E-Szenarien. Die Ergebnisse wurden in vier Kategorien eingeteilt: PASS, ÜBERSPRUNGEN, BUG-BEHOBEN und BEKANNTE EINSCHRÄNKUNGEN. Besonders aufschlussreich war die Kategorie BUG-BEHOBEN, die fünf wiederkehrende Problemklassen identifizierte – allesamt an den Schnittstellen zwischen Systemen oder Transportwegen lokalisiert.

1. Zod-Koerzierung: Wenn Strings und Zahlen nicht zusammenpassen

Sechs List-Tools nutzten z.number() für Paginationsparameter. Da der MCP-Server Parameter als JSON-RPC-Strings sendet, wurden diese von Zod abgelehnt – obwohl die Tests mit nativen Zahlen funktionierten. Die Lösung: Umstellung auf z.coerce.number(), das Strings automatisch in Zahlen konvertiert. Ein klassischer Fall von Schema und Realität, die nicht übereinstimmen.

2. Pflichtfelder bei partiellen Updates

Drei Update-Tools (update-company, update-client, update-product) verlangten in ihrem Schema ein Pflichtfeld name. Bei partiellen Updates (z. B. nur Telefonnummer ändern) führte dies zu Fehlern, da die KI { phone: "..." } ohne name sendet. Die Korrektur: Umstellung auf z.string().optional() für Felder, die nicht bei jedem Update erforderlich sind.

3. Fehlende Besitzprüfungen (IDOR)

Das Tool update-document-status überprüfte nicht, ob der Status zur authentifizierten Team-ID gehörte. Theoretisch hätte ein Nutzer durch Raten der UUID den Status eines anderen Teams ändern können – die Web-UI zeigte dies nie, da sie nur die eigenen Stati anzeigte. Die Lösung: Explizite teamId-Prüfung in der Repository-Abfrage. Ähnliches galt für delete-document-status. Diese Sicherheitslücke wäre in einem Code-Review vermutlich unentdeckt geblieben.

4. Methodenname-Missmatches

Das Tool update-invoice rief fälschlicherweise service.update() auf, während die Methode eigentlich service.updateDocument() hieß. Der TypeScript-Compiler übersah dies dank as never und übergangener Generics. Ein weiterer Fall: convert-estimate-to-invoice nutzte require() statt statische Importe, was im ESM-Kontext zu stillen Fehlern führte. Die Korrektur: Entfernen von require(), Nutzung korrekter DI-Factory-Funktionen und Anpassung der Methodennamen.

5. Archivierte Entitäten in Listen

Die Tools list-clients, list-companies und list-products gaben standardmäßig archivierte Entitäten zurück – obwohl die Web-UI diese in der Oberfläche filterte. Die KI zeigte Nutzern archivierte Clients an, die daraufhin Invoices erstellen wollten und eine verwirrende Fehlermeldung erhielten. Die Lösung: Standardmäßige Filterung archivierter Entitäten, optional mit includeArchived-Parameter.

Fazit: MCP-Server als strategischer QA-Partner

Die Erkenntnisse aus diesem Projekt zeigen, dass MCP-Server weit mehr sein können als nur Schnittstellen für KI-Assistenten. Sie fungieren als unsichtbare QA-Engineers, die Produktionsdaten systematisch durchforsten und Probleme aufdecken, die klassische Tests und manuelle Checks übersehen. Besonders wertvoll sind sie bei der Analyse von Kreuzdomänen-Inkonsistenzen, Sicherheitslücken und Datenqualitätsproblemen.

Für Unternehmen, die SaaS-Lösungen entwickeln, könnte der Einsatz von MCP-Servern in Kombination mit KI-Assistenten ein Game-Changer sein – nicht nur zur Fehlererkennung, sondern auch zur kontinuierlichen Verbesserung der Datenintegrität. Die Zukunft der Qualitätssicherung liegt möglicherweise weniger in zusätzlichen Testfällen, sondern in der intelligenten Analyse der tatsächlichen Systemdaten.