CMS MCP Server: Wie KI-Agenten Content in Liferay migrieren

Key Takeaways

• Der Wandel zu Agenten: Content Operations entwickeln sich von einfachen Chatbots zur Texterstellung hin zu autonomen KI-Agenten, die komplette Aufgabenketten innerhalb von Systemen ausführen können.

• Objektbasierte Architektur: Das neue Liferay CMS setzt vollständig auf Liferay Objects. Das bedeutet, dass jede Definition automatisch native Headless APIs mitbringt, die von der KI analysiert und verarbeitet werden können.

• Überwachte Automatisierung: Durch die Nutzung des DXP MCP Servers können Teams komplexe Legacy-Content-Migrationen in schnelle, überwachte Agenten-Workflows verwandeln – statt aufwendiger, individuell entwickelter Skriptprojekte.

• Semantische Fähigkeiten: KI-Agenten übernehmen die Strukturerstellung, die feldgenaue Content-Generierung sowie die kontextbezogene taxonomische Kategorisierung statt einfachen Textvergleichen.

Für viele Digitalteams ist die Migration von bestehendem Web-Content in ein modernes CMS die größte Hürde auf dem Weg zur Modernisierung – oft langsam, teuer und ressourcenintensiv.

Dieser Artikel zeigt, wie Unternehmen traditionelle, komplexe Skriptprojekte umgehen, indem sie autonome KI-Agenten und das Model Context Protocol (MCP) nutzen, um den Umstieg zu automatisieren. Wir beleuchten, wie dieser neue Ansatz schwierige Content-Migrationsprojekte im neuen Liferay CMS in schnelle, überwachte Workflows verwandelt und die Herangehensweise von DXP-Teams an ihren digitalen Footprint grundlegend verändert.

Was bedeutet „Chat is dead“ für Enterprise Content Operations?

Die Aussage „Chat is dead“ verdeutlicht, dass generative KI über konversationelle Chatbots hinausgeht und sich hin zu autonomen Software-Agenten entwickelt, die darauf ausgelegt sind, ganze Aufgabenketten auszuführen. Im Juni 2026 zitierte die Financial Times einen leitenden Mitarbeiter von OpenAI genau mit diesen drei Worten. Das Unternehmen, das Chatbots zum Massenphänomen gemacht hat, baut sein Flaggschiff-Produkt nun um Agenten herum auf – Software, die nicht nur Fragen beantwortet, sondern Aufgaben erledigt. Was auch immer man von dem Slogan halten mag: Die Richtung steht außer Frage. Die erste Welle generativer KI hat Texte für uns verfasst; die nächste steuert unsere Systeme.

Für Content Operations ist dieser zweite Wandel noch bedeutender als der erste. Ein Chatbot, der einen Artikel entwirft, überlässt immer noch alles Weitere dem Editor: das Aufsetzen der Struktur, das Ausfüllen der Felder, das Zuweisen von Kategorien, das Veröffentlichen und die Wiederverwendung an anderer Stelle. Ein Agent übernimmt die gesamte Kette.

Mit dem neuen Liferay CMS und dem DXP MCP Server funktioniert diese Kette schon heute. Wir setzen sie bei Portalworks bereits in Kundenprojekten ein. Und am deutlichsten zahlt sie sich dort aus, wo sich derzeit viele DXP-Teams bewegen: Wie bekommen wir unseren bestehenden Content in das neue CMS?

Warum unterstützt die Liferay Object-Architektur KI-Operationen von Haus aus?

Liferay Objects unterstützen KI-Operationen von Haus aus, weil jede Content-Struktur eine Objektdefinition mit typisierten Feldern, Picklisten, Verknüpfungen und Validierungen ist, die automatisch eigene Headless APIs mitbringt. Im neuen Liferay CMS folgen Einträge, Vokabulare und Spaces genau diesem Muster. Aufgrund dieses Designs gibt es keine redaktionelle Funktion, die ausschließlich hinter einer Schaltfläche in der grafischen Benutzeroberfläche verborgen ist.

Der MCP Server, der seit 2025.Q4 mit DXP ausgeliefert wird und aktuell hinter einem Beta-Feature-Flag liegt, stellt diese strukturelle Oberfläche externen KI-Clients über einen Endpunkt unter /o/mcp mittels eines streamfähigen HTTP-Transport-Layers zur Verfügung. Die Client-Konfiguration umfasst nur wenige Zeilen JSON; der Agent authentifiziert sich als regulärer Nutzer und agiert strikt innerhalb der Rechte dieses Nutzers. Das ist bereits die gesamte Integration.

Es lohnt sich, die Arbeitsteilung präzise zu betrachten. Die Intelligenz stammt vom externen Modell – Liferay analysiert nicht und muss es auch nicht. Was Liferay beiträgt, ist das ideale Gegenstück für ein denkendes Modell zu sein: strikt strukturierte Daten, selbstbeschreibende Schemata und eine vollständige Headless-Abdeckung jeder Operation – was im Kern ein CMS MCP Server ist: eine Protokollschicht, die diese strukturierten Daten in etwas verwandelt, worauf ein Agent direkt agieren kann. Ein LLM, das auf einem Haufen unstrukturierter HTML-Daten arbeitet, muss raten. Arbeitet es hingegen mit Objektdefinitionen mit typisierten Feldern und kuratierten Vokabularen, kann es zielgerichtet agieren.

Welche Content-Aufgaben können KI-Agenten heute im Liferay CMS ausführen?

KI-Agenten, die über eine MCP-Verbindung laufen, können automatisch Datenstrukturen aufbauen, feldgenaue Content-Einträge aus Legacy-Quelldateien generieren und kontextbezogenes taxonomisches Tagging durchführen. Bevor wir auf vollständige Migrationen eingehen, ist hier der genaue operative Workflow, den wir bei Portalworks in aktiven Kundenprojekten nutzen:

• Erstellung von Strukturen: Wir beschreiben in einfacher Sprache, was wir benötigen, wie zum Beispiel: „Wir brauchen eine Content-Struktur für Produktankündigungen: Headline, Teaser, Body, Release-Datum, Produktlinie als Pickliste.“ Der Agent erstellt im zugewiesenen Space über MCP sofort die Ziel-Objektdefinition inklusive Feldern und Pickliste.

Figure 2: Agentengespräch, das die MCP-Tool-Aufrufe zeigt, mit denen eine Objektdefinition erstellt wird, nebeneinander mit der daraus resultierenden Struktur im Liferay CMS

• Erstellung von Content für diese Strukturen: Der Agent füllt die Struktur stapelweise aus dem von uns bereitgestellten Quellmaterial – wie Datenblättern, Meeting-Notizen oder einem alten Produktkatalog. Da die Definition jedes Feld explizit typisiert, wird das Ergebnis feldgenau ausgegeben, und die native Validierung fängt ab, was nicht passt.

Figure 3: Liste der generierten Einträge innerhalb eines Spaces mit ausgefüllten strukturierten Feldern

• Kategorisierung von Assets: Im selben Durchgang weist der Agent Kategorien aus bestehenden Vokabularen zu. Das ist kein einfacher Textvergleich gegen Labels; das Modell versteht die semantische Bedeutung der Kategorien. Eine Kategorie namens „Entscheidungsträger“ im Vergleich zu einer Kategorie namens „Entwickler“ verändert, wie der Agent Inhalte auswählt, gewichtet und formuliert. Ihre Taxonomie hört auf, passive Metadaten zu sein, und wird zu einer aktiven Handlungsanweisung für die KI.

Wie migrieren Unternehmen klassischen Web-Content in das neue Liferay CMS?

Unternehmen migrieren klassischen Web-Content in das neue CMS, indem sie beide Seiten des Transfers über die MCP-Oberfläche leiten und so ein Skriptprojekt in überwachte Agentenarbeit verwandeln. Klassischer Web-Content befindet sich seit 2026.Q1 im Maintenance Mode. Das neue CMS zeigt, wohin sich die Plattform entwickelt – und mitzugehen ist der Grund, auf Liferay zu bleiben.

Das Hindernis war nie die Überzeugung, sondern die Migration selbst. Jahrelang gewachsene Web-Inhalte, Strukturen und Templates bewegen sich nicht von allein, und der klassische Weg mit individueller Export-Transform-Import-Skriptierung ist genau die Art von Projekt, die immer wieder verschoben wird – besonders bei knappen Budgets.

Genau diesen Engpass in der Entwicklung löst MCP auf. Klassischer Web-Content ist über dieselbe MCP-Oberfläche erreichbar wie das neue CMS – auf beiden Seiten des Prozesses. Ein Agent liest bestehende Artikel aus, mappt sie auf die neuen Objektdefinitionen, übernimmt die Kategorisierung und markiert alles, was sich nicht eindeutig zuordnen lässt, für eine menschliche Entscheidung. Die Migration wird zu einer überwachten Agentenaufgabe statt zu einem Skriptprojekt.

Um es klar zu sagen: Das ist kein Knopf nach dem Motto „MCP aktivieren und los“. Eine Migration erfordert einen fundierten Migrationsplan. Klassischer Web-Content enthält Feldtypen und Konstrukte ohne Eins-zu-eins-Entsprechung in Objects; verschachtelte, wiederholbare Felder, Web Content Link Fields oder in Templates eingebettete Logik müssen neu konzipiert und nicht einfach kopiert werden.

Der nachhaltige Ansatz besteht darin, zuerst die Ziel-Objektdefinitionen festzulegen, die Mapping-Regeln inklusive der Ausnahmefälle zu definieren, den Agenten die Ausführung im großen Maßstab überlassen und die Batches zu überprüfen. Das Projekt bleibt ein Projekt, aber es läuft um eine Größenordnung schneller, weil sich der Aufwand fast vollständig vom Schreiben von Transformations-Code auf das Treffen von Mapping-Entscheidungen verlagert.

Können Asset Libraries über MCP in CMS Spaces migriert werden?

Ja, Asset Libraries können systematisch in CMS Spaces migriert werden, da Spaces auf denselben grundlegenden Site-Fundamenten aufbauen wie Asset Libraries. Dadurch kann die MCP-Oberfläche nahtlos beide Entitäten abdecken. Eine Migration von Asset Libraries zu Spaces folgt demselben Automatisierungsmuster: Der Agent überträgt Dokumente und Medien, hält Vokabulare sowie Kategorisierungen intakt und konsolidiert zusammengehörige Inhalte in einem einheitlichen Space. Wenn Ihre Content-Landschaft heute über verteilte Asset Libraries verstreut ist, ist dies der Weg, sie ohne separaten Tools-Aufwand in das neue Modell zu Überführen.

Figure 4: Migrationslauf: Der KI-Agent bittet während der Migration um Anweisungen

Figure 5: Der Agent antwortet mit den migrierten Inhalten

Wie automatisieren KI-Agenten Workflows nach der Migration?

Sobald der Content nativ im strukturierten Repository des neuen CMS liegt, funktioniert dieselbe MCP-Verbindung in die andere Richtung: Externe KI-Agenten können diesen Content abfragen, filtern sowie durchsuchen und die abgerufenen Daten für Verteilkanäle aufbereiten.

Betrachten wir ein konkretes Beispiel aus unserer Arbeit bei Portalworks: die Erstellung eines monatlichen Newsletters. Der Agent fragt alle im letzten Monat veröffentlichten Inhalte ab, filtert und sortiert sie nach Kategorie – und erstellt eine Ausgabe für Kunden der Produktlinie „Energie“ sowie eine für Partner. Anschließend tut er das, was ein guter Editor mit den Inhalten tun würde: Er fasst jeden Beitrag für die von der Kategorie vorgesehene Zielgruppe zusammen, ordnet die Themen nach Relevanz und verfasst eine kurze Einleitung, die die Punkte verbindet. Da der Agent die Kategorien semantisch versteht, lesen sich die beiden Ausgaben völlig unterschiedlich, selbst wenn sie auf demselben Basis-Content aufbauen.

Dieses Muster deckt gleichermaßen zielgruppenspezifische Landingpage-Texte, das Extrahieren von FAQs aus Support-Inhalten und automatisierte Übersetzungsläufe ab, die prob Space eingereiht werden. Um diese Post-Migrations-Funktionalitäten effektiv umzusetzen, können Teams die Systeme aus dem Liferay AI Hub nutzen.

Figure 6: Entwurf für den Newsletter

Wo liegen die Grenzen des aktuellen DXP MCP Servers?

Die Haupteinschränkung des aktuellen DXP MCP Servers liegt darin, dass die visuelle Seitengestaltung weiterhin ein manueller Prozess ist, da Agenten Layout-Fragmente noch nicht auf Display Pages platzieren können. Ein Praxisbericht, der die Grenzen verschweigt, ist kein ehrlicher Bericht – daher müssen diese Lücken benannt werden. Während Content Operations durchgängig funktionieren, erfordert der visuelle Seitenaufbau weiterhin direktes menschliches Eingreifen. Die Tools für Definitionen, Einträge, Kategorisierungen und Abfragen arbeiten jedoch vollständig.

Zudem ist der MCP Server derzeit eine Beta-Funktionalität hinter einem expliziten Feature-Flag (LPD-63311). Was das Beta-Label jedoch verbirgt, ist das hohe Entwicklungstempo. Die quartalsweisen Releases haben dieses Feature mit jedem Zyklus spürbar vorangebracht – der Transport wechselte mit 2026.Q1 auf streamfähiges HTTP, und die Tool-Abdeckung ist stetig gewachsen.

Wer den MCP Server vor sechs Monaten evaluiert hat, sieht heute ein völlig anderes Feature, und die Tendenz zeigt klar in Richtung Einsatzbereitschaft für Produktivumgebungen. Selbst innerhalb der Patch Releases ist der Unterschied spürbar.

Wie hat Liferay seine Plattform-Architektur für das KI-Zeitalter gerüstet?

Liferay hat sich auf das KI-Zeitalter vorbereitet, indem es seine bisherigen Content-Modelle durch ein einziges, einheitliches Konzept ersetzt hat, das ein Low-Code/No-Code-Framework nutzt, mit dem Agenten Datenstrukturen anpassen können, ohne dass System-Deployments erforderlich sind. Tritt man einen Schritt von den einzelnen Features zurück, wird das übergeordnete Muster deutlich. Der native MCP Server stellt diese gesamte architektonische Struktur jedem LLM oder KI-Tool, das ein Unternehmen einsetzen möchte, sicher zur Verfügung.

Zusammengenommen streift Liferay damit seine Altlasten ab – und überreicht seinen Nutzern, was für einen so großen Plattformwechsel ungewöhnlich ist, genau die Werkzeuge, um den technischen Übergang schnell und weitgehend automatisiert zu gestalten. Der Migrationspfad ist nicht nur dokumentiert, sondern programmgesteuert optimiert. Praktischerweise sind die Kernstärken der Plattform – strukturierte Daten und eine tiefe Headless-API-Abdeckung – genau das, was das Zeitalter der KI-Agenten verlangt. Das neue CMS wurde von Grund auf so konzipiert, dass Maschinen jeden Teil davon lesen können, während die Ergänzung durch den Model Context Protocol (MCP) Server bedeutet, dass dieselben Agenten nun auch schreiben können.

Das ist eine Digital Experience Platform (DXP), die mutige, zielgerichtete Schritte direkt in die nächste Phase ihrer Kategorie macht: weg von einfachen Chats hin zum vollständigen Systembetrieb.

Häufig gestellte Fragen (FAQ)

Was ist das Model Context Protocol (MCP)?

Ein offener Standard zur Verbindung von KI-Anwendungen mit externen Systemen. Ein MCP Server beschreibt seine Funktionalitäten als Tools und Ressourcen; jeder KI-Assistent oder jedes KI-Tool, das als MCP-fähiger Client agiert – wie Claude Desktop, GitHub Copilot, Cursor, Gemini CLI oder ein eigener Agent –, kann diese ohne individuell erstellte Integration ermitteln und aufrufen. Die Einrichtung umfasst typischerweise nur wenige Zeilen in der Konfigurationsdatei des jeweiligen Clients (bei Claude Desktop in der Claude Desktop-Konfigurationsdatei), die auf den Endpunkt des Servers verweisen. Da viele Unternehmen Copilot bereits für die interne Nutzung freigegeben haben, ist das Fundament für den Einstieg oft schon vorhanden.

Was macht die MCP-Server-Implementierung eines CMS effektiv?

Eine effektive MCP-Server-Implementierung für ein CMS stützt sich auf vier zentrale Säulen:

• Strukturiertes Datenmodell: Bereitstellung typisierter Felder statt rohem HTML – damit Agenten nicht raten oder unübersichtlichen Code parsen müssen, um den Kontext zu verstehen.

• Abdeckung des gesamten Tool-Lebenszyklus: Unterstützung beim Erstellen, Bearbeiten und Veröffentlichen – statt nur reinem Lesezugriff –, damit Agenten Workflows Ende-zu-Ende und ohne manuelle Zwischenschritte ausführen können.

• Rollenbasierte Berechtigungen: Abbildung realer Benutzerrollen anstelle eines pauschalen Service-Accounts – damit Aktionen sauber protokolliert werden und Sicherheitsrichtlinien unangetastet bleiben.

• Kontextbezogene Taxonomie & Metadaten: Direkte Bereitstellung semantischer Tags und Inhaltsbeziehungen für den Agenten – damit dieser versteht, wie die einzelnen Teile zusammenhängen, und inhaltlich präzisen Content auswählen oder generieren kann.

Kann ich klassischen Web-Content einfach durch Aktivieren von MCP in das neue CMS migrieren?

Nicht ganz. Sie benötigen weiterhin zuerst Ziel-Objektdefinitionen und klare Mapping-Regeln, da einige klassische Feldtypen keine direkte Entsprechung in Objects haben und strukturell neu konzipiert werden müssen. Steht dieser grundlegende Plan, führt der Agent die Migration im großen Maßstab durch – um ein Vielfaches schneller als skriptbasierte Ansätze.

Was ist mit Content, der in Asset Libraries gespeichert ist?

Spaces bauen auf demselben grundlegenden Site-Fundament auf wie Asset Libraries, was bedeutet, dass die MCP-Oberfläche beide nahtlos erreicht. Der KI-Agent kann Dokumente, Medien und deren zugehörige Kategorisierungen über dieselbe aktive MCP-Verbindung problemlos aus Legacy-Asset-Libraries in CMS Spaces migrieren.

Versteht die KI meine Kategorien wirklich oder gleicht sie nur Labels ab?

Der Agent interpretiert sie semantisch, anstatt sich auf einfachen Textvergleich zu verlassen. Kategorienamen und ihre operativen Zusammenhänge beeinflussen direkt, wie der Agent Inhalte auswählt, gewichtet und umschreibt. Deshalb verbessert eine gut gestaltete Taxonomie die Qualität der automatisierten Ergebnisse direkt.

Was sind die aktuellen Einschränkungen?

Der MCP Server ist eine Beta-Funktionalität hinter einem Feature-Flag. Die in der Praxis relevanteste Lücke: Fragmente können noch nicht über einen Agenten auf Seiten platziert werden, sodass der visuelle Seitenaufbau manuell bleibt. Die Tools für Definitionen, Einträge, Kategorisierung und Abfragen funktionieren jedoch durchgängig.

Wie verbinden Entwickler KI-Tools und KI-Agenten über den MCP-Server mit dem Headless-CMS?

Entwickler können KI-Assistenten und KI-Agenten mit dem Headless-CMS verbinden, indem sie einfach ihre Claude-Desktop-Konfigurationsdatei (oder die Konfiguration ihrer bevorzugten KI-Tools) aktualisieren. Die JSON-Konfiguration erfordert, dass die Anfrage über HTTPS an den MCP-Server-Endpunkt gerichtet wird und eine Standardauthentifizierung (z. B. ein API-Schlüssel oder ein Authentifizierungstoken) bereitgestellt wird. Sobald der Zugriff gewährt wurde, kann der Agent Medien-Assets abfragen, die Inhaltsstruktur verwalten, Metadaten durchsuchen und mithilfe dynamischer Parameter neue Inhaltstyp-Schemas oder Felddefinitionen erstellen.

Was macht die MCP-Server-Implementierung eines CMS effektiv?

Eine effektive MCP-Server-Implementierung für ein CMS hängt von vier Dingen ab: einem strukturierten Datenmodell (typisierte Felder statt rohem HTML), damit Agenten nicht raten müssen; einer vollständigen Tool-Abdeckung über das Erstellen, Schreiben und Kategorisieren von Content hinweg (nicht nur das Lesen); Berechtigungen, die reale Nutzerrollen widerspiegeln anstelle eines pauschalen Service-Accounts; sowie einer semantischen Taxonomie-Handhabung, bei der Kategorien tatsächlich verändern, wie ein Agent Inhalte auswählt und formuliert. Ohne den ersten Punkt spielt der Rest keine Rolle.

Von Marc Hermann
Marc Hermann ist Geschäftsführer bei Portalworks, einem spezialisierten Liferay Solution-Partner. Mit über 18 Jahren Erfahrung im Liferay Ökosystem konzentriert sich Marc auf digitale Transformation, B2B-Enterprise-Portale und die Modernisierung von Content Operations durch intelligente Automatisierung.