Das Symfony MCP Bundle macht eine Symfony Anwendung zum MCP Server. Eigene Services, Entitäten und Geschäftslogik werden als Tools, Prompts und Ressourcen bereitgestellt, die ein KI Agent über das Model Context Protocol aufrufen kann. Seit Version 0.13 arbeitet das Bundle auch in die andere Richtung und tritt selbst als MCP Client auf.

Installiert wird es mit composer require symfony/mcp-bundle. Unter der Haube liegt das offizielle mcp/sdk. Transport läuft über HTTP oder stdio. Wichtig zu wissen: Das Bundle ist als experimentell markiert und fällt damit nicht unter die Backward Compatibility Promise von Symfony. Für Produktivsysteme heißt das: Version pinnen und Updates lesen.

Die Abgrenzung zu Symfony AI Mate ist seit 0.13 klar. Mate ist ein CLI Werkzeug für die Entwicklung und hat MCP verlassen. Das MCP Bundle ist der Weg, wenn die eigene Anwendung nach außen als MCP Server sprechen soll, für Kunden, Partner oder interne Agents.

Never Code Alone arbeitet seit über zwanzig Jahren mit PHP und Symfony. Sulu, unser eigenes CMS, läuft auf Symfony, unsere Website ebenso. MCP ist bei uns kein Vortragsthema, sondern täglicher Betrieb: Wir sprechen über MCP mit unserem CMS, mit n8n und mit dem Blog. Was wir bei euch einbauen, benutzen wir selbst.

Rund um das MCP Bundle greifen mehrere Leistungen ineinander. Den Rahmen setzt unser PHP Consulting, für den Weg von der Idee zum produktiven Agent gibt es das Vibe Coding Consulting. Wer Unternehmensdaten für Agents öffnen will, findet den Aufbau in der NCA MCP Middleware. 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. Für den Datenschutz gibt es die DSGVO Beratung.

Das Model Context Protocol beschreibt, wie ein KI Client mit einem externen Dienst spricht. Der Dienst stellt Fähigkeiten bereit, der Client ruft sie auf. Das Bundle übernimmt die Protokollarbeit und lässt dich bei dem bleiben, was du ohnehin schreibst: normale Symfony Services.

Es gibt vier Arten von Fähigkeiten:

• Tools: Methoden, die der Agent aufrufen darf, etwa eine Lagerabfrage oder eine Preisberechnung
• Resources: Inhalte, die der Agent über eine URI liest
• Resource Templates: Ressourcen mit Parametern in der URI
• Prompts: vorbereitete Textbausteine, die der Client anbietet

Seit Version 0.12 registriert das Bundle diese Elemente über den Container statt über die dateibasierte Suche des SDK. Das ist der wichtigere Teil, als es klingt: Alles, was im Container hängt, lässt sich mit den üblichen Mitteln testen, austauschen und mocken. Mit debug:mcp zeigt die Konsole, welche Fähigkeiten registriert sind und welcher Handler dahintersteht. Im Profiler taucht dieselbe Übersicht bei jedem Request auf, nicht nur bei MCP Anfragen. Wie einzelne PHP Methoden zu Werkzeugen werden, zeigt unsere Seite zu Tool Calling in Symfony AI.

Die Installation ist ein Composer Aufruf. Anders als bei Mate handelt es sich nicht um eine Dev Dependency, denn der Server läuft im Betrieb mit.

Die Konfiguration liegt unter mcp: in der Bundle Konfiguration. Seit 0.13 hängt alles an benannten Servern unter dem Schlüssel servers:. Jeder Server bekommt eine eigene Identität, eigene Transports, einen eigenen Session Store, eine eigene HTTP Route und eine eigene registry:.

Diese registry: ist Pflicht und bestimmt, was der Server nach außen zeigt. Entweder eine Liste, die alle Arten abdeckt, oder eine Aufteilung nach tools, prompts, resources, resource_templates und apps. Eingetragen werden Service IDs, Klassennamen, Namespace Präfixe oder *. Damit ist die alte stillschweigende Regel weg, dass einfach jedes registrierte Element auf dem einen Server landet. Für Sicherheit und Übersicht ist das ein deutlicher Gewinn.

Die größte Änderung in Version 0.13 ist die Mehrzahl. Eine Anwendung kann mehrere MCP Server betreiben, jeder mit eigenem Zuschnitt. Das löst ein Problem, das vorher nur mit getrennten Anwendungen zu lösen war: Ein öffentlicher Server zeigt harmlose Lesewerkzeuge, ein interner Server zeigt zusätzlich alles, was schreibt.

Dazu kommt die Gegenrichtung. Unter clients: lässt sich die Anwendung als MCP Client konfigurieren. Jeder benannte Client besitzt eine Menge entfernter Server, erreichbar über stdio oder HTTP. Zwei Interfaces regeln den Zugriff:

• McpClientInterface als Service mcp.client.name
• ServerConnectionInterface als Service mcp.client.name.server.server

Diese Services besitzen den Lebenszyklus der Verbindung. Sie verbinden bei der ersten Nutzung und trennen beim Kernel Reset. Dazu bringt ServerConnectionInterface die Methode complete() mit, die completion/complete weiterreicht. Damit kann der Client einen entfernten Server bitten, ein Prompt Argument oder ein Argument eines Resource Templates zu vervollständigen. Auch getProtocolVersion() und sendRootsListChanged() sind neu, und clients.name.roots zeigt auf einen Service mit RootsCallbackInterface und ersetzt das alte Flag capabilities.roots.

MCP entwickelt sich weiter, und alte Clients verschwinden nicht über Nacht. Version 0.13 bedient die Revision 2026 07 28 auf demselben Endpoint wie die ältere Handshake Ära. Das SDK ordnet jede Anfrage ein und leitet sie an den passenden Ablauf weiter. Für Betreiber heißt das: kein zweiter Endpoint, keine Umstellung für bestehende Clients.

Wer das enger fassen will, nutzt servers.name.protocol_versions und legt fest, welche Revisionen ein Server beantwortet. Bleibt die Option leer, erbt der Server einfach, was das SDK in beiden Ären kann.

Drei weitere Optionen kommen dazu:

• request_state signiert den Zustand, den eine Antwort über mehrere Runden durch den Client trägt. Der Schlüssel dafür darf jetzt aus einer Umgebungsvariable kommen, gehört also nicht ins Repository
• cache setzt die Cache Hinweise, die der moderne Zweig an seine Antworten hängt, mit Überschreibung pro Methode
• subscriptions konfiguriert die Auslieferung der Streams von subscriptions/listen

Für Sessions gibt es seit 0.8 einen Store auf Basis von Symfonys SessionHandlerInterface. Damit läuft die Sitzungsverwaltung über dieselbe Infrastruktur wie im Rest der Anwendung. Wer einen öffentlichen Server betreibt, sollte zusätzlich http.allowed_hosts setzen und den Schutz gegen DNS Rebinding bewusst konfigurieren statt abzuschalten.

Seit Version 0.11 kann das Bundle mehr als Text zurückgeben. Über die Attribute #[AsMcpApp] und #[AsMcpAppTool] entstehen interaktive HTML Oberflächen als Ressourcen. Das zugehörige Tool liefert ein Kontext Array, das Symfony serverseitig mit Twig rendert. HTML over the wire, wie man es aus Symfony Projekten kennt.

Für Teams mit Symfony Hintergrund ist das der bequemste Einstieg in Agent Oberflächen. Es braucht kein zusätzliches Frontend Framework und keine zweite Codebasis. Das Feature wird über mcp.apps.enabled geschaltet und ist damit bewusst eine Entscheidung, keine Nebenwirkung.

Wie bei jedem Feature dieser Art gilt: Was ein Agent aufrufen darf, gehört in die registry: des passenden Servers und nicht auf den öffentlichen. Und alles, was aus der Anwendung zurückkommt, ist für das Modell Datenmaterial und keine Anweisung. Diese Trennung sauber zu halten, ist der Kern jeder Absicherung. Mehr dazu in unserer Beratung zu Agentic AI Coding Guardrails.

Die Frage kommt in Gesprächen fast immer in derselben Form: Wir haben Daten und wollen, dass eine KI damit arbeitet. Was brauchen wir? Die Antwort hängt daran, wer die Fähigkeiten sehen soll.

Das MCP Bundle passt, wenn:

• die eigene Symfony Anwendung Fähigkeiten für Agents bereitstellen soll, intern oder für Kunden
• Geschäftslogik als Tool erreichbar sein muss, ohne dass jemand die Datenbank direkt anfasst
• unterschiedliche Zielgruppen unterschiedliche Ausschnitte sehen sollen, was seit 0.13 über mehrere Server sauber geht
• die Anwendung selbst entfernte MCP Server nutzen soll, wofür es jetzt die Client Seite gibt

Es passt nicht, wenn es nur darum geht, einem Coding Agent beim Entwickeln zu helfen. Dafür ist Symfony AI Mate gedacht, das genau deshalb seit 0.13 kein MCP Server mehr ist. Und es passt nicht als schneller Zugang zu Rohdaten. Ein Tool, das beliebige Abfragen durchreicht, ist kein Tool, sondern ein offenes Tor.

Zu bedenken bleibt der experimentelle Status. Das Bundle steht nicht unter der Backward Compatibility Promise, Konfiguration und Interfaces können sich zwischen Minor Versionen ändern. 0.13 zeigt das deutlich: registry: ist neu und Pflicht, capabilities.roots ist ersetzt. Wer das Bundle produktiv einsetzt, braucht Tests, die den Vertrag der eigenen Tools absichern, und einen Blick ins Changelog vor jedem Update.

Diese Seite hier ist über MCP entstanden. Unser Sulu CMS spricht über einen MCP Server mit dem Agent, Bilder kommen über n8n dazu, die Verteilung läuft ebenfalls automatisiert. Wir kennen deshalb nicht nur die Konfiguration, sondern auch die Stellen, an denen so ein Aufbau im Alltag hakt.

Was sich in der Praxis bewährt hat: Tools klein und fachlich schneiden statt eine Universalschnittstelle bauen. Antworten knapp halten, weil jedes Feld Tokens kostet. Wie viel dabei zu holen ist, zeigt unser Artikel zu optimierten MCP Responses. Und jedes Tool bekommt einen Test, der den Vertrag festhält, sonst merkt niemand, wenn ein Update die Antwortform ändert.

Wir helfen Teams, ihre Symfony Anwendung als MCP Server aufzusetzen: Zuschnitt der Server und ihrer registry:, Absicherung der Route über security.yaml, Tests für die eigenen Tools und die Prüfung in der Pipeline. Zur Einordnung, welches Werkzeug im Umfeld wozu taugt, gibt es unser Glossar für KI Tools 2026 und die Übersicht der Vibe Coding Tools.

Diese Fragen kommen in Gesprächen zum MCP Bundle am häufigsten auf.