MCP-Server für Testing: Wie du Verification direkt in deinen AI-Workflow einbaust

Aletiq ist ein MCP-Server, den dein AI-Agent direkt als Tool aufrufen kann — kein Kontextwechsel, kein separater Testing-Schritt. Dein Agent baut ein Feature, verifiziert es und fixt Probleme in einer Schleife, ohne dass du den Editor verlässt. Verification wird zum natürlichen Teil der AI-Entwicklung statt zum Nachgedanken.

Dieser Artikel zeigt, wie du Aletiq als MCP-Server einrichtest, wie der Self-Verification-Loop in der Praxis funktioniert und warum integrierte Verification besser ist als ein separater Testing-Workflow.

Was ist MCP und warum ist es relevant für Testing?

MCP (Model Context Protocol) ist ein offener Standard, der AI-Agents den Zugriff auf externe Tools ermöglicht. Statt nur Text zu generieren, kann ein Agent über MCP mit der realen Welt interagieren: Dateien lesen, APIs aufrufen, Datenbanken abfragen — oder Software verifizieren.

Für Testing bedeutet das: Verification wird ein Tool, das der Agent selbstständig aufruft — genauso wie er ein Terminal öffnet oder eine Datei editiert. Kein separater Workflow, kein Tab-Wechsel, kein „Vergiss nicht, die Tests zu laufen".

Ohne MCP-Integration:

1. Agent schreibt Code
2. Du wechselst zum Terminal
3. Du führst Tests manuell aus
4. Du liest die Ergebnisse
5. Du wechselst zurück zum Agent und beschreibst das Problem
6. Agent fixt den Bug
7. Zurück zu Schritt 2

Mit MCP-Integration:

1. Agent schreibt Code
2. Agent ruft aletiq_verify auf
3. Agent liest das Verdict
4. Bei FAIL: Agent fixt den Bug und verifiziert erneut
5. Bei PASS: Agent meldet „Done, verified"

Der gesamte Build-Verify-Fix-Loop passiert innerhalb des Agents. Du siehst am Ende fertigen, verifizierten Code.

Warum scheitern separate Testing-Workflows bei AI-Entwicklung?

Weil jeder Kontextwechsel eine Chance ist, Testing zu überspringen — und bei AI-Geschwindigkeit wird diese Chance regelmäßig genutzt.

Drei Gründe, warum separate Workflows versagen:

• Kontextwechsel-Kosten — Du bist im Flow, dein AI-Agent hat gerade drei Komponenten refactored. Jetzt solltest du zum Terminal wechseln, Playwright starten, auf die Ergebnisse warten, die Failures analysieren. Oder du machst einfach weiter zum nächsten Feature. Die meisten Entwickler machen weiter.
• Testing als Nachgedanke — Wenn Testing ein separater Schritt ist, wird es als optional wahrgenommen. „Ich teste nachher", „Ich teste wenn das Feature fertig ist", „Ich teste vor dem Release". In der Praxis heißt „nachher" oft „nie".
• Feedback-Verzögerung — Je mehr Zeit zwischen Code-Änderung und Verification liegt, desto schwieriger wird es, Fehler zuzuordnen. Wenn du nach 20 AI-generierten Changes merkst, dass der Checkout kaputt ist, weißt du nicht welcher Change schuld ist. Sofortige Verification nach jedem Change macht das Problem trivial.

Die Lösung ist nicht Disziplin, sondern Design: Wenn Verification im selben Kontext wie die Entwicklung passiert, wird sie nicht übersprungen, weil es keinen Aufwand kostet, sie auszuführen.

Wie funktioniert Aletiq als MCP-Server?

Aletiq registriert sich als MCP-Tool mit einem einzigen Capability: aletiq_verify. Dein AI-Agent sieht dieses Tool in seiner Toolbox — neben Datei-Operationen, Terminal und anderen Tools.

Der Ablauf im Detail:

1. Agent entscheidet — Der Agent erkennt, dass er eine UI-Änderung gemacht hat, die verifiziert werden sollte (z.B. nach einem Refactoring oder neuen Feature).
2. Tool-Aufruf — Der Agent ruft aletiq_verify auf mit zwei Parametern: dem Intent in natürlicher Sprache und der URL.
3. Planner — Aletiq übersetzt den Intent in einen Ausführungsplan und definiert Bewertungskriterien.
4. Runner — Der Runner führt den Plan lokal aus: öffnet den Browser, navigiert, klickt, macht Screenshots, sammelt DOM-Daten.
5. Judge — Die Multi-Model-Jury (Claude, Gemini, GPT) bewertet die Beobachtungen einstimmig gegen den Intent.
6. Rückgabe — Der Agent bekommt ein strukturiertes Verdict: PASS, UNCLEAR oder FAIL mit Begründung und Evidenz.
7. Reaktion — Bei FAIL: Agent analysiert die Begründung, identifiziert das Problem und fixt es. Bei PASS: weiter zum nächsten Task.

Das Verdict ist maschinenlesbar — der Agent kann direkt darauf reagieren, ohne dass ein Mensch die Ergebnisse interpretieren muss. Die durchschnittliche Latenz beträgt 4,5 Sekunden pro Verification.

Mit welchen AI-Agents funktioniert die MCP-Integration?

Mit allen Agents, die das Model Context Protocol unterstützen — das sind mittlerweile die meisten relevanten AI-Coding-Tools.

Verifizierte Kompatibilität:

• Claude Code — Anthropics CLI-Agent. MCP-native, Aletiq als Tool direkt verfügbar.
• Cursor — AI-IDE mit MCP-Support. Aletiq integriert sich über die MCP-Konfiguration.
• Codex — OpenAIs Coding-Agent mit MCP-Kompatibilität.
• Gemini — Googles AI-Agent mit Tool-Use-Capabilities.
• GitHub Copilot — MCP-Unterstützung in neueren Versionen.
• Windsurf — Codeium's AI-IDE mit MCP-Integration.
• Aider — Open-Source AI-Pair-Programming-Tool.
• Continue — Open-Source AI-Coding-Assistent für VS Code und JetBrains.
• Cline — Autonomer AI-Agent für VS Code.
• Devin — Cognitions autonomer Software-Engineer.

Wenn dein Agent MCP-Tools aufrufen kann, kann er Aletiq nutzen. Die Integration ist identisch für alle Agents — eine JSON-Konfiguration, kein agent-spezifischer Code.

Wie sieht der Self-Verification-Loop in der Praxis aus?

Ein konkretes Beispiel mit Claude Code. Du gibst dem Agent einen Task:

"Refactor the hero section to use the new design tokens and update the CTA text to 'Start Building Free'"

Was der Agent tut:

# 1. Agent editiert Hero.tsx
# ... ändert Styles, aktualisiert Text, passt Layout an ...

# 2. Agent verifiziert
→ aletiq_verify("The hero section should display a prominent CTA that navigates to signup", "http://localhost:3000")

# 3. Verdict: FAIL
# Reason: "The CTA button is present with text 'Start Building Free' but clicking it
# navigates to /login instead of /signup. The intent specifies signup navigation."

# 4. Agent fixt den Bug
# ... ändert href von /login zu /signup ...

# 5. Agent verifiziert erneut
→ aletiq_verify("The hero section should display a prominent CTA that navigates to signup", "http://localhost:3000")

# 6. Verdict: PASS
# Reason: "The hero section displays a clearly visible CTA button with text 'Start Building Free'.
# Clicking the button navigates to /signup as intended."

# 7. Agent meldet
"Done. Hero section refactored with new design tokens. CTA updated and verified —
navigates correctly to /signup."

Der gesamte Loop — Refactoring, erster Verify, Bug-Fix, zweiter Verify — dauert unter 2 Minuten. Ohne MCP-Integration hätte der Agent den falschen Link nicht bemerkt, weil der Code syntaktisch korrekt ist und /login eine gültige Route ist.

Wie richte ich Aletiq als MCP-Server ein?

Eine JSON-Konfiguration — unter 5 Minuten für jeden unterstützten Agent.

Claude Code:

Füge in deiner .claude/settings.json oder über claude mcp add den Aletiq-Server hinzu:

{
  "mcpServers": {
    "aletiq": {
      "command": "aletiq",
      "args": ["mcp-server"],
      "env": {
        "ALETIQ_API_KEY": "your-api-key"
      }
    }
  }
}

Cursor:

In den Cursor Settings unter MCP Servers:

{
  "aletiq": {
    "command": "aletiq",
    "args": ["mcp-server"],
    "env": {
      "ALETIQ_API_KEY": "your-api-key"
    }
  }
}

Nach dem Setup sieht dein Agent aletiq_verify als verfügbares Tool. Kein Import, kein Package, keine Konfigurationsdatei pro Projekt. Der Agent kann sofort verifizieren.

Tipp: Definiere ein Project Profile in Aletiq, damit der Agent Kontext hat. Ohne Profile verifiziert Aletiq generisch. Mit Profile versteht die Judge-Jury, was deine App tun soll — und kann gewollte Änderungen von Bugs unterscheiden.

Kann der Agent entscheiden, wann er verifiziert?

Ja — und gute Agents tun das bereits von selbst, sobald Aletiq als Tool verfügbar ist.

AI-Agents wie Claude Code und Cursor sind darauf trainiert, ihre verfügbaren Tools situativ einzusetzen. Wenn der Agent weiß, dass aletiq_verify existiert, wird er es nach UI-Änderungen aufrufen — genauso wie er nach Code-Änderungen den TypeScript-Compiler aufruft, um Fehler zu finden.

Wann Agents typischerweise verifizieren:

• Nach Refactoring einer Komponente
• Nach Hinzufügen eines neuen Features mit UI-Elementen
• Nach Änderungen an Navigation oder Routing
• Vor dem Abschluss eines Tasks, als finaler Check

Wann Agents typischerweise nicht verifizieren:

• Bei reinen Backend-Änderungen ohne UI-Impact
• Bei Config-Änderungen (Umgebungsvariablen, Package-Versionen)
• Bei Dokumentations-Updates

Du kannst das Verhalten steuern, indem du dem Agent Instruktionen gibst: „Verifiziere nach jeder UI-Änderung" oder „Verifiziere nur am Ende des Tasks". Die meisten Entwickler lassen den Agent selbst entscheiden — er hat ein gutes Gespür dafür, wann Verification sinnvoll ist.

Was ist der Unterschied zu einem Test-Runner als MCP-Tool?

Du könntest auch Playwright als MCP-Tool einbinden — der Agent führt dann bestehende Tests aus. Aber das löst das Grundproblem nicht.

Wenn dein Agent Playwright als Tool hat, verbringt er Tokens und Zeit damit, Test-Code zu generieren, auszuführen, Failures zu analysieren und Tests zu reparieren. Mit Aletiq gibt er einen einzeiligen Intent und bekommt ein klares Verdict in 4,5 Sekunden.

Der Agent sollte Code schreiben, der Wert liefert — nicht Code, der anderen Code testet. Aletiq trennt diese Verantwortlichkeiten: Der Agent baut, Aletiq verifiziert.

Die vollständige Gegenüberstellung von Playwright und Aletiq — mit Code-Beispielen und Benchmark-Daten — findest du im Playwright vs. Aletiq Vergleich.

Wie vermeide ich unnötige Verification-Aufrufe?

Nicht jeder Change braucht Verification. Drei Strategien, um dein Kontingent sinnvoll einzusetzen:

1. Nur bei UI-Changes verifizieren

Backend-Logik, API-Endpunkte, Datenbankmigrationen, Config-Änderungen — diese haben keinen direkten UI-Impact und brauchen keine visuelle Verification. Instruiere deinen Agent: „Verifiziere nur nach Änderungen an Komponenten, Pages oder Styles."

2. Kritische Intents priorisieren

Nicht jede Seite ist gleich wichtig. Dein Checkout ist kritischer als deine Impressum-Seite. Definiere eine Prioritätenliste:

• Immer verifizieren: Signup, Login, Checkout, Pricing, Hauptnavigation
• Bei größeren Changes verifizieren: Dashboard, Settings, Profil
• Selten verifizieren: Statische Seiten, Legal, Blog

3. Batched Verification statt Einzel-Checks

Statt nach jeder kleinen Änderung zu verifizieren, sammle Changes und verifiziere nach Abschluss eines Features oder Tasks. Ein Verify-Run mit 5 Intents kostet 5 Verifications — egal ob du sie einzeln oder gebatched aufrufst.

Aletiq nutzt außerdem intelligentes Caching: Wenn sich der Seiteninhalt seit dem letzten Check nicht geändert hat, liefert der Cache sofort ein Verdict — ohne LLM-Aufruf. Das passiert automatisch und verbraucht kein Kontingent.

Wie starte ich mit MCP-basierter Verification?

In 5 Minuten — drei Schritte:

Schritt 1: Aletiq installieren und API-Key holen

Free Tier: 50 Verifications pro Monat, keine Kreditkarte.

Schritt 2: MCP-Config einfügen

Eine JSON-Zeile in deiner Agent-Konfiguration. Für Claude Code:

claude mcp add aletiq -- aletiq mcp-server

Für Cursor: MCP-Server in den Settings hinzufügen.

Schritt 3: Ersten Intent verifizieren

Sag deinem Agent: „Refactor the hero section and verify that the CTA still navigates to signup." Der Agent baut, verifiziert und meldet das Ergebnis — alles in einem Durchgang.

Du musst dem Agent nicht erklären, wie er Aletiq nutzt. MCP-fähige Agents erkennen verfügbare Tools automatisch und setzen sie situativ ein. Sobald aletiq_verify verfügbar ist, wird der Agent es bei UI-Änderungen aufrufen.

Mehr zum praktischen Workflow — Checklisten, CI/CD-Integration und UNCLEAR-Handling — findest du im praktischen Guide zur AI-Code-Verification. Wie sich Intent-Based Verification von Screenshot-Diffing unterscheidet, zeigt der Vergleich Screenshot-Diffing vs. Intent-Based Verification.

Richte Aletiq jetzt als MCP-Server ein — dein AI-Agent verifiziert ab sofort jeden UI-Change automatisch, bevor du ihn siehst.