Symfony AI Mate ist ein CLI Assistent aus dem offiziellen symfony/ai Ökosystem. Er stellt Coding Agents wie Claude Code, Codex oder Cursor projektbezogene Werkzeuge als echte Kommandozeilenbefehle bereit: Profiler Daten, Container Services, Logs und Projektstruktur, ohne dass Quellcode an externe Server geht.

Bis Version 0.12 lief Mate als MCP Server. Mit Version 0.13.0 vom 30. August 2026 ist das vorbei. Die MCP Runtime, die Befehle serve und stop und die Abhängigkeit zu mcp/sdk sind entfernt. Der Agent ruft jetzt vendor/bin/mate direkt auf und liest Tool Schemas bei Bedarf über --help oder tools:inspect, statt sie beim Start komplett in den Kontext zu laden.

Anders als generische Werkzeuge kennt Mate die Symfony Architektur: Dependency Injection Container, Service Definitionen, Profiler Collector Daten und Monolog Logs sind direkt als Tools verfügbar. Wichtig bleibt: Mate ist ein reines Development Tool und nicht für Produktion gedacht. Die Installation läuft über composer require --dev, alles läuft lokal auf dem Entwicklungsrechner. Das macht Mate für DSGVO konforme Entwicklungsumgebungen interessant.

Never Code Alone arbeitet seit über zwanzig Jahren mit PHP und Symfony. Unser CMS läuft auf Symfony, diese Website ebenso, und wir entwickeln täglich mit Coding Agents gegen echte Projekte. Wir wissen deshalb aus der Praxis, wo ein Werkzeug wie Mate wirklich Zeit spart und wo es nur Kontext frisst.

Rund um Mate greifen mehrere Leistungen ineinander. Den Rahmen setzt unser PHP Consulting, den Weg vom Prototyp in die Produktion begleitet das Vibe Coding Consulting. Regeln und Prüfungen für KI Code kommen aus den NCA PHP AI Coding Guidelines, die Absicherung in der Pipeline aus den Vibe Coding CI CD Pipelines. Praxiswissen zum Umgang mit Agents sammeln wir in den Vibe Coding Best Practices, den Datenschutzteil deckt die DSGVO Beratung ab.

Mate ist seit Version 0.13 eine native PHP CLI. Tools und Ressourcen werden per Reflection aus den Attributen #[MateTool], #[MateResource] und #[MateResourceTemplate] eingelesen. Der Agent bekommt keine Tool Liste vorab in den Kontext geschoben, sondern fragt sie ab, wenn er sie braucht. Das spart Tokens und macht jeden Aufruf nachvollziehbar, weil er als normaler Shell Befehl im Verlauf steht.

Der Workflow im Projekt sieht so aus:

• Installation: composer require --dev symfony/ai-mate fügt Mate als Dev Dependency hinzu
• Initialisierung: vendor/bin/mate init legt das mate/ Verzeichnis an und fragt, wie der Coding Agent Mate aufrufen soll
• Discovery: vendor/bin/mate discover scannt installierte Pakete nach Extensions und Skills
• Arbeiten: tools:list, tools:inspect, tools:call und resources:read ersetzen die alten mcp: Befehle

Parameter übergibt tools:call jetzt als lange Optionen, etwa vendor/bin/mate tools:call symfony-profiler-list --limit=1, bei verschachtelten Werten mit --json. Statt einer mcp.json schreibt mate init CLI orientierte Agent Instructions nach mate/AGENT_INSTRUCTIONS.md und legt im Projektroot eine gemanagte CLAUDE.md an, die AGENTS.md per @AGENTS.md importiert. Damit findet Claude Code die Anleitung, die es sonst nie lesen würde. Prompts hat die CLI nicht mehr, sie sind mit dem MCP Server entfallen.

Die Installation läuft über Composer und dauert wenige Minuten. Das Paket kommt als Development Dependency ins Projekt, weil es ausschließlich in der Entwicklungsumgebung arbeitet.

Nach der Initialisierung liegt im Projektroot ein mate/ Verzeichnis mit extensions.php für Extensions und Skills sowie config.php für projektspezifische Einstellungen. Neu in 0.13 sind dort mate.invocation und mate.php_version. Beim init fragt Mate, wie der Coding Agent das Tool aufrufen soll, und schlägt ddev exec vendor/bin/mate vor, sobald ein .ddev/ Verzeichnis existiert.

Die PHP Version wird über genau diesen Wrapper ermittelt und festgeschrieben. Läuft Mate später unter einer anderen major.minor Version, verweigert es den Start. Nur init, discover, list, help und completion warnen stattdessen. Für maschinenlesbare Ausgaben hängt man --format=json an die tools:*, resources:read, debug:* und skills:* Befehle. Das optionale symfony/ai-mate-composer-plugin aktualisiert die Discovery automatisch nach jedem composer install und composer update.

Das Extension System ist die zentrale Stärke von Symfony AI Mate. Offizielle und Community Extensions erweitern die CLI um neue Tools und Ressourcen. Die wichtigsten offiziellen Extensions:

• symfony/ai-symfony-mate-extension: Container Introspection, Service Discovery, Dependency Analyse und Profiler Zugriff für Symfony Projekte
• symfony/ai-monolog-mate-extension: Log Suche, Filterung und Tail Operationen für Monolog basierte Anwendungen

Eigene Tools entstehen als PHP Klasse im mate/src Verzeichnis. Seit 0.13 trägt sie das native Attribut #[MateTool], die frühere MCP Variante #[McpTool] ist weg. Für Ressourcen gibt es #[MateResource] und #[MateResourceTemplate]. Damit lassen sich projektspezifische Erweiterungen bauen, etwa für Datenbank Abfragen, API Tests oder eigene Debugging Workflows.

Jede Extension meldet sich über die extra.ai-mate Konfiguration in der composer.json an. Nach vendor/bin/mate discover taucht sie sofort in tools:list auf. Für Agenturen ist das interessant, weil domänenspezifische Werkzeuge als wiederverwendbare Composer Pakete entstehen können, etwa für Sulu CMS Integrationen, Shop Schnittstellen oder Monitoring.

NCA unterstützt bei der Entwicklung eigener Mate Extensions und bringt sie sauber in die Pipeline: Tests mit PHPUnit, statische Analyse mit PHPStan, Prüfung im CI. Wie eine Symfony Anwendung umgekehrt selbst zum MCP Server wird, zeigt unsere Seite zum Symfony MCP Bundle.

Extensions bringen seit Version 0.12 nicht nur Tools mit, sondern auch Agent Skills. Das sind kleine Anleitungen, die dem Coding Agent erklären, wann er welches Werkzeug einsetzt. Version 0.13 macht daraus einen kompletten Lebenszyklus mit eigenen Befehlen und einem festen Ort im Projekt.

skills:install kopiert die Skills einer Extension nach .agents/skills/mate-name/ und legt im Ordner .claude/skills/ relative Symlinks als Spiegel an. Wo Symlinks nicht funktionieren, wird kopiert. Der Befehl ist ein idempotenter Reconciler: Er baut beide Ordner bei jedem Lauf neu aus Quelle oder Override auf und räumt Skills entfernter oder deaktivierter Extensions weg. discover ruft ihn automatisch mit auf.

Der komplette Zustand pro Skill steht in mate/extensions.php. Von Hand pflegt man dort nur enabled und mode mit den Werten managed oder override. Alles andere verwaltet Mate selbst: state, source, source_hash, hash und targets. Wer einen Skill anpassen will, holt ihn mit skills:override nach mate/skills/name/ und gibt ihn mit skills:reset wieder ab.

Praktisch ist skills:validate. Der Befehl prüft die generierten Ordner gegen den gespeicherten Zustand und schlägt bei handbearbeiteten Inhalten, fehlenden Ordnern oder einem falsch zeigenden Spiegel fehl. Mit --strict werden auch Warnungen zum Fehler, etwa wenn eine SKILL.md auf eine Datei verlinkt, die gar nicht zum Skill gehört. Dazu kommen Hinweise, wenn eine Beschreibung kürzer als 40 Zeichen ist oder nie sagt, wann der Skill greift. Diese Hinweise ändern den Exit Code nicht. Genau so ein Befehl gehört in die CI Pipeline, damit Anweisungen für Agents nicht still auseinanderlaufen. Wie sich das mit AGENTS.md und Rules Dateien verzahnt, steht in unserem Praxisartikel dazu.

Im Alltag zeigt sich der Nutzen schnell. Statt selbst Profiler Daten zu durchsuchen oder Service Definitionen nachzuschlagen, ruft der Agent den passenden Mate Befehl auf. Ein typisches Bild: Du beschreibst ein Performance Problem im Chat, der Agent holt sich die Profiler Daten, findet die langsame Query und schlägt eine Änderung vor. Kein Fenster Wechsel, kein Copy Paste.

Konkrete Einsatzszenarien in Symfony Projekten:

• Debugging: Zugriff auf Profiler Collector Daten, um Bottlenecks im Request Cycle zu finden
• Refactoring: Container Introspection zeigt Service Abhängigkeiten, bevor etwas verschoben wird
• Onboarding: Neue Teammitglieder fragen nach Projektstruktur, Services und Konfiguration
• Log Analyse: Die Monolog Extension erlaubt gezielte Suche im Log statt Blindflug

Gerade beim Refactoring bleibt die Reihenfolge wichtig: erst Quality Gates, dann aufräumen. Statische Analyse, Unit Tests, funktionale Tests und E2E Tests mit Cypress stehen vor jedem größeren Umbau. Mate liefert dem Agent den Kontext, die Entscheidung über Struktur bleibt beim Team. NCA begleitet genau diesen Weg im Vibe Coding Consulting und hilft Teams, Mate sauber in bestehende Symfony Projekte zu bringen.

Bis 0.12 stand Mate in derselben Reihe wie der GitHub MCP Server oder der Sylius MCP Server. Seit 0.13 ist der Vergleich schief, denn Mate ist kein Server mehr. Der Agent startet keinen Prozess und hält keine Session, er ruft einen Befehl auf und liest dessen Ausgabe.

Was der CLI Ansatz bringt:

• Weniger Kontext: Tool Schemas werden über tools:inspect nur bei Bedarf gelesen, nicht beim Start komplett geladen
• Weniger Abhängigkeiten: keine MCP Runtime, kein mcp/sdk, kein Session Handling
• Nachvollziehbar: jeder Aufruf steht als normaler Shell Befehl im Verlauf und lässt sich wiederholen
• Framework aware: Mate kennt Dependency Injection, Profiler und Routing, ein dateibasiertes Werkzeug nicht

MCP verschwindet damit nicht aus dem symfony/ai Ökosystem. Das Symfony MCP Bundle im selben Repository bleibt der Weg, wenn eine Symfony Anwendung selbst als MCP Server auftreten soll. Version 0.13 bringt dort Unterstützung für mehrere Server und Clients sowie die Protokoll Revision 2026 07 28. Die Einschränkung von Mate bleibt: Der Kern funktioniert in jedem PHP Projekt, die tiefe Integration über die Symfony Extension gibt es nur mit Symfony.

Mate läuft vollständig lokal. Quellcode, Container Konfiguration und Logs verlassen den Entwicklungsrechner nicht. Für europäische Teams ist das der entscheidende Punkt, denn die Analyse passiert im eigenen Netzwerk und nicht in einer fremden Cloud.

Version 0.13 baut den Datenschutz weiter aus:

• Untrusted Data Envelope: Tool Antworten mit Daten aus der untersuchten Anwendung landen unter einem untrusted_data Schlüssel mit Sicherheitshinweis, damit das Modell sie als Daten und nicht als Anweisung behandelt
• Mailer Collector: Mail Inhalte, Empfänger und Link Tokens werden vor der Ausgabe geschwärzt
• Profiler Fallback: sensible Schlüssel im Raw Data Fallback werden ebenfalls geschwärzt
• Doctrine Parameter: beim Schwärzen in gespeicherten Profilen bleibt die Struktur erhalten, der Inhalt nicht

Der Coding Agent selbst schickt natürlich weiter Kontext an seine API. Genau deshalb gilt bei NCA eine klare Regel: Coding Modelle, die nicht auf eigener Infrastruktur laufen, arbeiten immer gegen lokale Entwicklungsumgebungen mit Fake Daten, nie gegen echte Kundendaten. Wer gehostete Inferenz mit europäischem Datenschutz braucht, findet passende Optionen bei TensorX oder über unseren Netzwerkpartner Conversis in Duisburg. Der Grundsatz bleibt: Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk. Wie das im Detail aussieht, zeigt unsere DSGVO Beratung für Vibe Coding.

Was in der Praxis den Unterschied macht, ist selten das Werkzeug selbst. Es sind die Regeln drumherum. Ein Agent, der Profiler Daten lesen darf, aber keine Tests kennt, produziert schnelle Vorschläge ohne Absicherung. Deshalb steht bei uns immer zuerst die Prüfkette, dann die Beschleunigung.

Zur Einordnung der Werkzeuge im Umfeld gibt es unsere Übersicht der Vibe Coding Tools und das Glossar für KI Tools 2026. Wer wissen will, welche Modelle sich für Coding eignen, findet die Bewertung bei den Vibe Coding Modellen. Ergänzend dazu der offizielle Sprachserver von Symfony, die Symfony Language Tools, die Container, Routen und Twig kennen.

Die wichtigsten Fragen und Antworten zu Symfony AI Mate, dem CLI Assistenten für KI gestützte PHP Entwicklung mit Symfony.