Symfony Mate: Echter Laufzeit-Kontext für KI-Assistenten

Symfony Mate: Echter Laufzeit-Kontext für KI-Assistenten

Wer KI-Coding-Assistenten im Symfony-Alltag einsetzt, kennt das Muster: Der Agent liest Datei für Datei, rekonstruiert den Kontext, fragt nach, schlägt dann doch die falsche Lösung vor. Weil er nicht weiß, was der Container wirklich tut. Weil er den Profiler nicht öffnen kann. Weil er nur Code liest, aber die Applikation nie sieht.

Symfony Mate löst dieses Problem. Es ist ein MCP-Server (Model Context Protocol), der eine laufende Symfony-Applikation für jeden MCP-fähigen Client zugänglich macht. Container-Zustand, Services, Profiler-Daten, Logs. Nicht als Datei-Dump, sondern als kuratierter, deterministischer Blick. Der Talk von Johannes Wachter (Sulu GmbH, Co-Maintainer Symfony AI) bei SymfonyOnline June 2026 (11. Juni) zeigt, wie Mate einen N+1-Doctrine-Bug in Sekunden findet, wo der Agent sonst Minuten braucht.

Heute, am Tag der Konferenz, ist der richtige Zeitpunkt für die Einordnung: Was ist Mate, wie funktioniert es, und was bedeutet es für Teams, die KI-Assistenten produktiv in Symfony-Projekten einsetzen wollen?

Wie unterscheiden sich die gängigen KI-Assistenten?

Alle vier unterstützen MCP. Alle vier können Symfony Mate als Kontext-Quelle nutzen. Die Wahl des Assistenten hängt von anderen Faktoren ab: IDE-Präferenz des Teams, Datenschutz-Anforderungen (lokal vs. Cloud), Aufgabentyp.

Was macht Symfony Mate konkret?

Das Kernproblem von KI-Assistenten ohne Laufzeit-Kontext: Sie sehen nur Dateien. Ein N+1-Doctrine-Bug zum Beispiel ist in der Codebase oft nicht sichtbar. Er zeigt sich erst im Profiler: 47 SQL-Queries für das Laden von 10 Produkten. Ein Assistent ohne Profiler-Zugriff kann das nicht diagnostizieren. Er liest den Code, vermutet das Problem, schlägt vielleicht die richtige Lösung vor. Oder auch nicht.

Symfony Mate löst das, indem es einen MCP-Server über Ihre laufende Symfony-Applikation legt. Der Assistent fragt nicht mehr "Was sagt die Datei?", sondern "Was zeigt der Profiler für diesen Request?" oder "Welche Services sind im Container registriert?". Das ist der Unterschied zwischen Quellcode-Lesen und Applikations-Verstehen.

# Installation (Development-Dependency)
$ composer require --dev symfony/ai-mate

# Konfiguration initialisieren (erstellt mate/-Verzeichnis + mcp.json)
$ vendor/bin/mate init

# Autoloader aktualisieren
$ composer dump-autoload

# Verfügbare Extensions entdecken
$ vendor/bin/mate discover

# MCP-Server starten
$ vendor/bin/mate serve
# → Mate startet als stdio-basierter MCP-Server
# → Claude Code, Cursor, Copilot verbinden sich über mcp.json
# → Zugriff auf: Container-Services, Profiler, Logs

Drei Architektur-Entscheidungen sind dabei besonders durchdacht:

Zugriff auf kompilierte Artefakte: Mate parst den bereits gedumpten Container (App_KernelDevDebugContainer.xml) und die Profiler-Dateien auf der Festplatte. Das bedeutet: Wenn der Container der Ziel-Applikation kaputt ist (Konfigurationsfehler, fehlende Services), kann Mate die kompilierten Artefakte dennoch lesen. Der Agent kann dann helfen, genau diesen Fehler zu debuggen, ohne dass Mate selbst einen Live-Container starten muss.

Secret-Redaction: Sensitive Daten (API-Keys, Datenbankpasswörter) werden automatisch aus dem Kontext herausgefiltert, bevor sie an den Assistenten gesendet werden. Kein Risiko, dass Secrets in der KI-Kontext-Historie landen.

Keine externen Server: Mate läuft lokal. Der Kontext verlässt Ihren Entwicklungsrechner nicht. Das ist relevant für Teams, die an Projekten mit vertraulichen Daten arbeiten.

Wie passt Mate in den Entwicklungs-Workflow?

Mate ändert nicht den Assistenten, sondern die Qualität des Kontexts. Der Workflow bleibt: Code schreiben, Assistent fragen, Änderungen reviewen. Was sich ändert: Der Assistent fragt jetzt nicht mehr fünf Mal nach, weil er den Container nicht kennt. Er sieht den echten Zustand.

Das Wie der Integration hängt vom gewählten Assistenten ab:

Claude Code ist der natürlichste Fit. MCP ist Anthropics eigenes Protokoll, Claude Code ist von Grund auf MCP-first. Die Verbindung läuft über die von mate init generierte mcp.json. Claude Code liest diese Konfigurationsdatei und verbindet sich automatisch mit dem laufenden Mate-Server. Besonders stark bei großen Refactors über mehrere Dateien, was in Symfony-Projekten häufig ist.

GitHub Copilot hat die breiteste IDE-Abdeckung inklusive PhpStorm. Wer sein Team nicht aus der gewohnten IDE herausreißen will, kommt mit Copilot + Mate-Integration am weitesten. Der Trade-off: MCP-Unterstützung in Copilot ist jünger als bei Claude Code.

Cursor ist für VS-Code-Teams die natürliche Wahl. Der Agent-Mode in Cursor funktioniert gut mit MCP-Servern. Trade-off: Cursor ist proprietär, der Quellcode läuft über externe Server.

Wie ich im PHPverse 2026 Artikel beschrieben habe, ist das offizielle MCP-PHP-SDK (in Kollaboration von PHP Foundation, Symfony und Anthropic entstanden) die Grundlage für diese Entwicklung. Symfony Mate baut auf derselben Infrastruktur auf und zeigt, wie MCP in der Praxis aussieht.

# Eigene Tools für Mate registrieren:
# Nach 'mate init' wird composer.json automatisch angepasst:
{
  "autoload": {
    "psr-4": {
      "App\\Mate\\": "mate/src"
    }
  },
  "extra": {
    "ai-mate": {
      "scan-dirs": ["mate/src"],
      "includes": ["mate/config.php"]
    }
  }
}

# Tool erstellen in mate/src/MyTool.php:
namespace App\Mate;

use Mcp\Capability\Attribute\McpTool;

class MyTool
{
    #[McpTool(name: 'my_tool', description: 'My custom tool')]
    public function execute(string $param): array
    {
        return ['result' => $param];
    }
}
# → Tools im Scan-Verzeichnis werden über #[McpTool]-Attribut automatisch erkannt

Das Composer-Plugin-Erweiterungsmodell ist dabei strategisch interessant: Agenturen, die auf mehreren Projekten ähnliche Domain-Logik haben, können projektspezifische Mate-Tools entwickeln und über eigene Packages verteilen.

Was sind die Grenzen von Symfony Mate?

Was die Dokumentation nicht explizit benennt: Mate ist ein Entwicklungs-Tool. Es ist für die lokale Entwicklungsumgebung konzipiert, nicht für Staging oder Production. Der Profiler-Zugriff funktioniert nur, wenn der Symfony-Profiler aktiv ist (typischerweise im dev-Modus). In Production-ähnlichen Umgebungen ohne Profiler liefert Mate weniger Kontext.

Für Teams, die KI-Assistenten auch bei Produktions-Debugging einsetzen wollen, ist Mate nur der erste Schritt. Die Log-Daten können je nach Konfiguration begrenzt sein. Und bei sehr großen Symfony-Projekten (100+ Services im Container) kann die Kontext-Qualität leiden, wenn der Agent alle Services auf einmal betrachtet.

Zusammenfassung

Symfony Mate ist ein lokaler MCP-Server für Symfony-Projekte. Container-Zustand, Profiler-Daten und Logs werden für jeden MCP-fähigen Assistenten (Claude Code, Copilot, Cursor) zugänglich gemacht.

Das Kernprinzip: "Don't give AI more context, give it better context." Laufzeit-Kontext schlägt Datei-Kontext.

Installation: composer require --dev symfony/ai-mate, dann vendor/bin/mate init und vendor/bin/mate serve. Lokal, keine externen Server, Secret-Redaction eingebaut.

Zugriff auf kompilierte Artefakte: Mate parst den gedumpten Container und die Profiler-Daten. Auch wenn der Live-Container der Applikation einen Fehler hat, kann Mate die kompilierten Artefakte lesen und beim Debugging helfen.

Erweiterbar über das Composer-Plugin-Modell. Projektspezifische Tools können eigene Domain-Kontext-Daten bereitstellen.

Johannes Wachters Talk bei SymfonyOnline June 2026 (11. Juni, AI-Track) zeigt die Demo mit dem N+1-Doctrine-Bug. Die Replay-Aufzeichnung erscheint wenige Stunden nach dem Talk.