So integrieren Sie Ihren KI-Agenten über MCP in Magnolia DXP

Praktische, kontextbezogene Unterstützung, speziell entwickelt für Teams, die im Unternehmen für die Digital Experience zuständig sind.

KI wird zunehmend zu einem festen Bestandteil der Art und Weise, wie digitale Teams Kundenerlebnisse gestalten, verwalten und verbessern. Die Vorteile liegen auf der Hand: schnellere Umsetzung, weniger Routinearbeit und die Möglichkeit, Ideen direkt in die Praxis umzusetzen, ohne darauf angewiesen zu sein, dass gerade ein erfahrener Entwickler Zeit hat. Für Kunden, die unter Lieferdruck stehen, und für Partner, die ihr Fachwissen auf verschiedene Projekte ausweiten möchten, ist diese Anziehungskraft kaum zu übersehen.

Bei der Arbeit mit CMS in Unternehmen stößt generische KI jedoch an ihre Grenzen. Ein universeller Assistent kann zwar Code schreiben oder Dokumentation zusammenfassen. Was er jedoch in der Regel nicht kann, ist, die Realität eines konkreten Magnolia-DXP-Projekts zu verstehen: Wie es strukturiert ist, wo sich die Konfiguration befindet, was die laufende Instanz weiß, welche Vorlagen und Dialoge verfügbar sind oder auf welche Konventionen sich ein Kunden- oder Partnerteam tagtäglich stützt.

In einem CMS-Projekt reicht es nicht aus, wenn die Ausgabe plausibel aussieht. Eine Vorlage, die zwar dargestellt wird, den Redakteuren aber nichts Nützliches bietet, ein Dialogfeld, das den falschen Feldtyp verwendet, oder ein Konfigurationswert, der das Deployment außer Acht lässt, verursachen dennoch Überprüfungsaufwand, Nacharbeit und Risiken.

Der Magnolia MCP Developer’s Server ist die Ebene, die diese Lücke schließt. Anstatt KI als eine generische Funktion zu betrachten, die einfach an ein CMS angehängt wird, verbindet er die Unterstützung mit der tatsächlichen Magnolia-DXP-Umgebung des Kunden – der Projektstruktur, der laufenden Instanz und dem Magnolia-spezifischen Fachwissen.

Ein Magnolia-DXP-Projekt ist nicht nur ein Ordner mit Quelldateien. Es ist ein Netzwerk aus Vorlagen, Dialogen, Modulen für die einfache Entwicklung, Konfigurationen in YAML und JCR, registrierten Komponenten und Konventionen, die ein Team im Laufe zahlreicher Projekte entwickelt hat. Generic KI nimmt davon nichts wahr. Es betrachtet eine Datei isoliert, stellt eine plausible Vermutung an und schreibt etwas, das dem entspricht, was passen sollte.

Der MCP-Entwicklerserver erhält stattdessen eine strukturierte Ansicht des Projekts. Er ist so konzipiert, dass er die registrierten Vorlagen und Dialoge durchläuft, die Verknüpfungen einer Komponente überprüft, die mit dem Projekt gelieferte Konfiguration ausliest und den Verweisen zwischen ihnen folgt. Wenn die Frage lautet: „Füge dem bestehenden Hero-Dialogfeld ein Feld hinzu“, kann der Assistent diese anhand der tatsächlichen Definition des Hero-Dialogfelds beantworten, anstatt eine Definition aus Namenskonventionen abzuleiten.

Dies ist vor allem dort von Bedeutung, wo Magnolia-DXP-Projekte schwer zu durchschauen sind: bei sich gegenseitig überschreibenden Light-Modulen, gemischten YAML-/JCR-Konfigurationen, Multi-Site-Setups, bei denen die Konventionen von Site zu Site abweichen, und bei Partner-Toolkits, die auf das Standard-Magnolia-DXP aufgesetzt sind. Ein kontextbezogener Assistent kann den Überblick über die Ebenen behalten und Fragen dazu beantworten, welche Ebene zur Laufzeit tatsächlich Vorrang hat – denn genau dort liegen in der Regel die Fehlerquellen.

Nichts davon läuft als ein einziges monolithisches Tool. Der MCP Developer’s Server ist pluginbasiert: Das API-Plugin kommuniziert mit den Magnolia-APIs, um JCR-Inhalte in Testszenarien zu erstellen und Definitionsprobleme aufzudecken; das Log-Plugin überwacht das Protokoll der laufenden Magnolia DXP auf Probleme, während der Assistent arbeitet; das CLI-Plugin stellt dem Assistenten alle Funktionen der Magnolia-CLI zur Verfügung, von der Erstellung von Seiten bis hin zu Komponenten; und das Figma-Plugin generiert Magnolia-DXP-Ausgaben direkt aus einem Figma-Entwurf.

Die Figma-Generierung ist der Bereich, in dem der Server derzeit am leistungsfähigsten ist – sie steht im Mittelpunkt der aktuellen Tests –, während ein HTML-Plugin, das aus bestehenden HTML-Seiten generiert, noch in der Entwicklung ist. Das ist ein bewusster Ausgangspunkt, keine Obergrenze: Dank derselben Plugin-Architektur, die heute hinter der Figma-zu-Magnolia-Konvertierung steht, können neue Funktionen als eigenständiges Plugin hinzugefügt werden, anstatt den gesamten Code neu schreiben zu müssen.

Der Projektkontext vermittelt dem Assistenten, worum es geht. Die andere Hälfte besteht darin, ihm zu sagen, wie es sein soll. Hier kommt kuratiertes Fachwissen ins Spiel.

Das Fachwissen zu Magnolia DXP lässt sich nicht in einer einzigen Eingabeaufforderung, dem Trainings-Cut-off eines einzelnen Modells oder dem Kopf eines einzelnen Entwicklers zusammenfassen. Es gehört in bearbeitbare, versionierte Leitfäden, die das Projekt begleiten. Der MCP Developer’s Server ist genau darauf ausgerichtet: Best-Practice-Hinweise, Konventionen für bestimmte Projektarten, Integrationsmuster und „So machen wir das“-Regeln können als Leitfäden verfasst, nach Aufgabe und Projektart getaggt und bei Bedarf automatisch ausgewählt werden.

Daraus ergeben sich zwei Dinge. Erstens: Die gleichen Richtlinien, die ein Partner bei allen Implementierungen weitergibt, sind nun auch die Richtlinien, die der Assistent verwendet – was bedeutet, dass neue Entwickler, interne Prüfer und KI-Agenten alle auf eine einzige verlässliche Informationsquelle zurückgreifen, statt auf drei. Zweitens: Wenn sich die Vorgehensweise ändert – sei es durch eine neue Validierungsregel, ein neues Designsystem oder eine neue Art der Komponentenstrukturierung –, werden die Richtlinien nur einmal bearbeitet, und jede nachfolgende KI-gestützte Aufgabe greift darauf zurück.

Für ein Unternehmen ist das der Unterschied zwischen „Wir haben KI eingeführt“ und „Wir haben geregelt, wie sich KI in unseren Projekten verhält.“ Das Modell ist nicht mehr die einzige Autoritätsquelle.

Kuratiertes Fachwissen funktioniert nur, wenn die Kuratierung von Ihnen selbst stammt. Magnolia DXP enthält einen Standard-Fähigkeitssatz – Markdown-Dateien mit strukturiertem Frontmatter, die dem Assistenten mitteilen, wie eine Komponente benannt werden soll, welcher Feldtyp in welchen Dialog gehört und wie ein Light-Modul angelegt werden soll. Sie enthalten die Empfehlungen von Magnolia DXP selbst und stellen für die meisten Teams einen sinnvollen Ausgangspunkt dar. Sie sind jedoch nicht als endgültige Vorgabe gedacht.

Der MCP Developer’s Server behandelt sie entsprechend. Skills werden geladen und sind nicht fest codiert: Der Server und jedes Plugin stellen ein Skill-Verzeichnis bereit, der Skill-Loader fasst sie zu einem einzigen Satz zusammen, und jeder Skill verfügt über Tags, Ziele und eine Priorität. Eine höhere Priorität hat Vorrang. Ein Projekt, das andere Regeln für die Benennung von Komponenten benötigt, verzweigt sich nicht von den Vorgaben von Magnolia DXP – es überlagert den Teil, mit dem es nicht einverstanden ist, und übernimmt den Rest weiterhin.

Dank der bereitgestellten Tools handelt es sich um einen einstufigen Vorgang und nicht um eine umständliche Arbeit am Dateisystem. mgnl_dev_list_skills gibt alle derzeit geladenen Skills zurück, gefiltert nach Tag oder Ziel, sodass ein Entwickler genau sehen kann, welche Vorgaben aktuell gelten, bevor er Änderungen vornimmt. „mgnl_dev_customize_skill“ erstellt eine lokale Kopie eines bestehenden Skills zur Überschreibung, wobei das Original an Ort und Stelle verbleibt. „mgnl_dev_generate_skill“ erstellt ein neues Skill von Grund auf, wenn es in den Konventionen des Teams kein entsprechendes Upstream-Äquivalent gibt. Partner, die ihr eigenes Toolkit pflegen, können noch einen Schritt weiter gehen, indem sie Skills in ihrem eigenen Plugin bereitstellen, sodass die Richtlinien zusammen mit dem Code, der davon abhängt, weitergegeben werden.

Das sorgt dafür, dass die Guidance-Ebene konsistent bleibt. Die Standardeinstellungen von Magnolia DXP werden mit jeder neuen Version verbessert und finden auch weiterhin Anwendung in Projekten, die sie noch nie genutzt haben. Die Regeln, die ein Team überschrieben hat, bleiben überschrieben. Niemand muss sich zwischen Upstream-Updates und den eigenen Konventionen entscheiden.

Quelldateien beschreiben die Absicht. Die laufende Instanz beschreibt die Realität. In einer Unternehmensumgebung sind diese beiden fast nie identisch, und genau in dieser Lücke entstehen die meisten Produktionsstörungen.

Der MCP Developer’s Server ist so konzipiert, dass er mit einer laufenden Magnolia-DXP-Instanz kommuniziert und nicht nur mit der Quelle. Wenn eine generierte Änderung von etwas abhängt, das dem Live-System bekannt ist – beispielsweise die Version eines bereitgestellten Moduls, ein aktivierter Workflow, eine Berechtigungsgruppe, der Pfad einer Integration oder der Status einer veröffentlichten Seite –, kann der Assistent die Instanz abfragen und dies überprüfen, anstatt zu raten. Wenn das Projekt und die Instanz nicht übereinstimmen, wird diese Diskrepanz offengelegt und nicht verschleiert.

In der Praxis bedeutet dies, dass generierte Inhalte in der Umgebung validiert werden, in der sie tatsächlich ausgeführt werden. Eine Änderung am Dialog wird anhand des Live-JCR überprüft. Ein Konfigurationswert wird aus dem Deployment-System zurückgelesen. Die Diagnose einer fehlerhaften Seite kann relevante Protokolleinträge und den aktuellen Knotenzustand umfassen – und nicht nur eine Vermutung auf der Grundlage des Vorlagencodes. Der Abstand zwischen „Die KI hat dies vorgeschlagen“ und „Dies kann sicher zusammengeführt werden“ wird kleiner – und genau das ist die eigentliche Hürde für die Einführung in Unternehmen.

All das – Projektkontext, kuratierte Anleitungen, Zugriff auf Live-Instanzen – hätte als geschlossene Integration umgesetzt werden können, die an einen einzelnen KI-Client oder eine IDE gebunden ist. Das ist jedoch nicht der Fall. Der Name des Produkts verrät bereits, worum es geht: Der Magnolia MCP Developer’s Server nutzt das Model Context Protocol (MCP), den aufstrebenden offenen Standard für die Anbindung von KI-Assistenten an externe Tools und Kontexte.

Diese Entscheidung hat einige Konsequenzen, die es wert sind, ausdrücklich erwähnt zu werden. Die gleichen Funktionen können von jedem MCP-fähigen Client genutzt werden – heute die IDE eines Entwicklers, morgen eine andere IDE, der eigene Orchestrator eines Partners oder eine automatisierte Pipeline. Sie sind nicht an die Schnittstelle eines einzelnen Anbieters gebunden. Neue Funktionen – zusätzliche APIs, Design-Source-Reader, Validierungsabläufe, Protokollierungsintegrationen, partnerspezifische Tools – können als MCP-Server hinzugefügt und jedem Nutzer zur Verfügung gestellt werden, ohne dass die Clients neu geschrieben werden müssen.

Für Magnolia DXP ist MCP das, was verhindert, dass die KI-Ebene zu einem statischen Experiment wird. Das CMS bleibt das System of Record. Der MCP Developer’s Server stellt die KI-Funktionen als Composable-Tools bereit. Kunden und Partner können diese im Tempo des gesamten KI-Ökosystems übernehmen, austauschen und erweitern – und nicht nur im Rhythmus einzelner Produktveröffentlichungen.

Der MCP Developer’s Server läuft lokal auf dem eigenen Rechner des Entwicklers und lässt sich mit einem einzigen Terminalbefehl installieren. Er wird für jeden Server individuell konfiguriert, sodass ein Team je nach Umgebung unterschiedliche Parameter und Plugins verwenden kann, anstatt für jedes Projekt eine feste Konfiguration zu verwenden. Es gibt keine Cloud-Version – das Tool ist von Grund auf auf die lokale Nutzung ausgelegt, was bedeutet, dass Projektcode und Konfiguration die eigene Umgebung des Entwicklers niemals verlassen.

Um einen Agenten anzubinden, sind einige Schritte erforderlich: Installieren Sie den Server, geben Sie Ihrem Agenten die erforderlichen Informationen an (ein Figma-Zugriffstoken, das Framework, in dem Sie entwickeln – vieles davon kann er direkt aus dem lokalen Magnolia-DXP-Projekt selbst übernehmen), stellen Sie die Verbindung erneut her und beginnen Sie mit der Erstellung anhand von Vorlagen.

Für Magnolia DXP bedeutet das einen Assistenten, der das Projekt analysiert, mit der Live-Instanz kommuniziert, Magnolia-spezifisches Fachwissen einbringt und die Ergebnisse überprüft – und nicht einen generischen Codegenerator, der auf ein CMS ausgerichtet ist.

Das ist die Richtung: Eine KI-fähige Digital Experience Plattform, bei der intelligente Unterstützung kein separates Produkt neben dem CMS ist, sondern eine Ebene, die mit der Art und Weise verknüpft ist, wie Teams digitale Erlebnisse bereits entwickeln und betreiben.