I did not want another generic CMS bolted on top of my site. In my experience, that setup always creates friction. I wanted an mcp cms that felt like part of the product, not an external system I had to fight every day.
This article explains how I built my mcp cms with Next.js, Supabase, MCP, and agent flows. I cover the architecture, the tool layer, the admin dashboard, and the content pipeline so you can see how the whole system works in practice.
Warum ich ein MCP-CMS gebaut habe, statt eine generische Headless-Stack zu verwenden
Ich habe die Website und das CMS in derselben Next.js-App gebaut, weil ich eine einzige Codebasis, ein einziges Datenmodell und einen einzigen Publishing-Flow wollte. Ich habe genug voneinander getrennte Stacks genutzt, um zu wissen, wie schnell daraus Wartungsschulden werden. Wenn Frontend, CMS und Automationsschicht an getrennten Orten leben, kostet jede Änderung mehr Zeit, als sie sollte.
Mein mcp cms hält die öffentliche Website, die Admin-UI, die API-Routen und die AI-Tools innerhalb einer Produkt-Grenze. Das bedeutet, dass ich SEO-Metadaten, Lokalisierung oder Artikel-Logik ändern kann, ohne über drei Systeme springen zu müssen. Außerdem vermeide ich das übliche „Sync-Problem“, bei dem Inhalte in einem Tool leben und die eigentliche Logik irgendwo anders.
In der Praxis führte das zu schnelleren Iterationen und weniger kaputten Kanten. Außerdem ließ sich das System leichter beobachten, weil jede Schreibaktion durch dieselbe Schicht läuft. Wenn du mehr Kontext dazu willst, wie ich über operative Content-Systeme denke, zeigt mein Post zu Multi-Agent Content Pipeline in Next.js With Search Console die Research-Seite dieses Workflows.
Die Kernidee hinter dem System
Die Kernidee ist einfach: Das CMS soll sich wie ein Produkt verhalten, nicht wie ein Formular-Builder. Ich wollte typisierte Inhalte, kontrollierte Writes und eine Automationsschicht, die mir hilft, schneller zu veröffentlichen, ohne den Überblick zu verlieren. Deshalb habe ich die Architektur strikt gehalten und die Grenzen klar definiert.
Was ich von einem traditionellen CMS geändert habe
Ein traditionelles CMS trennt normalerweise das Bearbeiten von Inhalten vom Product-Codebase. Das klingt flexibel, bremst Teams aber oft, sobald die Website stärker angepasst wird. Mein mcp cms entfernt diese Trennung. Ich kann jetzt Inhalte, SEO und Workflow-Logik an einem Ort verwalten, was mir mehr Hebelwirkung mit weniger Overhead gibt.
Wie das MCP-CMS MCP als Control-Layer nutzt
Die wichtigste Entscheidung war, MCP in die Mitte des Systems zu setzen. Ich wollte, dass AI-Funktionen nicht in einem einzelnen Chat-Fenster oder einem Dashboard gefangen sind. Ich wollte eine wiederverwendbare Command-Schicht, die mit denselben Backend-Regeln von verschiedenen Clients sprechen kann.
Deshalb habe ich sowohl einen eigenständigen MCP-Server als auch eine MCP-Route innerhalb der App gebaut. Die Tools, die über das mcp cms verfügbar sind, umfassen Blog-CRUD, Publishing, SEO-Analyse, Artikelgenerierung, Research, Bildgenerierung und Sitemap-Checks. Mit anderen Worten: Die Agent-Schicht rät nicht, was zu tun ist. Sie ruft echte Tools mit echtem Zustand auf.
Dieser Ansatz passt zur Model Context Protocol specification und zu der Art, wie ich interne Systeme strukturieren mag: ein Vertrag, mehrere Clients, keine Duplikate. Außerdem machte es das einfache Wiederverwenden derselben Aktionen im Admin-Dashboard und von externen MCP-Clients möglich.
Tools, die ich über MCP freigelegt habe
Die Tool-Oberfläche ist bewusst breit. Ich wollte, dass die Agenten sinnvolle Arbeit leisten, nicht nur chatten.
Dieses Tool-Design ist das Rückgrat des mcp cms. Es hält das System komponierbar und macht jede Operation beobachtbar.
Warum diese Architektur in echter Arbeit wichtig ist
Bei meiner Arbeit, Websites und Content-Systeme zu bauen, ist der größte Engpass selten das Schreiben. Der Engpass ist die Koordination. MCP reduziert diese Koordinationskosten, weil dieselbe Aktion aus dem Dashboard, der Chat-Ansicht oder einem anderen Agent-Flow aufgerufen werden kann. Dadurch verbringe ich weniger Zeit damit, Schritte zu wiederholen, und mehr Zeit damit, das Ergebnis zu verbessern.
Das Admin-Dashboard macht das MCP-CMS zur Control Room
Ich wollte nicht, dass der Admin-Bereich sich wie ein langweiliges CRUD-Screen anfühlt. Ich habe ihn als Control Room gebaut. Er bietet Post-Management für Entwürfe, Übersetzungen, Bilder, SEO und Publishing – plus eine operative Schicht, in der ich AI-Workflows ausführen und beobachten kann, wie sie sich bewegen.
Im Dashboard macht der MCP-Chat dieselben Content-Tools verfügbar wie der Rest des Systems. Ich kann Posts auflisten, einen Entwurf inspizieren, SEO-Analyse triggern, Research starten oder den kompletten Pipeline-Flow mit einer Anfrage in natürlicher Sprache ausführen. Der wichtige Punkt ist: Der Chat ist keine Magie. Er basiert auf denselben typisierten Aktionen, die auch der Rest des mcp cms nutzt.
Dieses Design spart in der Praxis Zeit. Ich muss keine Interfaces für jeden neuen Workflow neu bauen. Ich stelle einfach ein weiteres Tool oder einen weiteren Control-Pfad bereit. Wenn du sehen willst, wie ich Automatisierung auf Systemebene denke, ist How I Built My CMS With MCP and Agent Flows der umfassendere Artikel zu diesem Setup.
Was ich vom Dashboard aus tun kann
Das Dashboard lässt mich schnell arbeiten, ohne die Kontrolle zu verlieren.
Warum ich einen Control Room statt eines einfachen Editors nutze
Ein einfacher Editor funktioniert, wenn du nur schreiben und veröffentlichen musst. Ich brauchte mehr. Ich wollte einen Ort, an dem ich Workflows beobachten, Änderungen freigeben und eingreifen kann, wenn ein Modell vom Kurs abweicht. Das ist der echte Wert des mcp cms: Es gibt mir operativen Einfluss, nicht nur eine Eingabemaske für Content.
Wie der MCP-CMS-Agent-Flow tatsächlich funktioniert
Der Agent-Flow ist kein einziger riesiger Prompt. Ich habe ihn in Stufen aufgeteilt, damit ich die Qualität in jedem Schritt kontrollieren kann. Das ist wichtig, weil Content-Arbeit chaotisch ist. Research, SEO, Struktur und Editing brauchen jeweils unterschiedliches Denken.
Hier ist der Flow, den ich am häufigsten verwende:
Ich habe diesen Flow wiederholt getestet, weil ich keine Fake-Demo-Pipeline wollte. Ich wollte ein System, in dem eine Stufe Feedback an eine andere Stufe zurückgeben kann. Diese Feedback-Schleife ist einer der Gründe, warum das mcp cms besser funktioniert als ein einzelner, passiver Writing-Assistant.
Warum ich den Flow in Stufen aufteile
Jede Stufe löst ein anderes Problem. Research reduziert Halluzinationen. SEO schärft die Struktur. Editing schützt die Qualität. Publishing bereinigt den finalen Output. Wenn man diese Aufgaben trennt, wird das gesamte System zuverlässiger und lässt sich über die Zeit leichter verbessern.
Wie ich verhindere, dass die Agenten abdriften
Ich halte die Agenten mit typisierten Inputs, expliziten Outputs und Quality-Checks kurz. Das gibt mir ein besseres Ergebnis als eine vage Prompt-Kette. Außerdem lassen sich Fehler leichter diagnostizieren, was wichtig ist, wenn du Automatisierung für Produktionsarbeit nutzt.
Search Console macht das MCP-CMS smarter
Einer der stärksten Teile des Systems ist, dass ich mich nicht nur auf Prompts verlasse. Ich verknüpfe Search-Console-Daten in den Research-Prozess, sodass die Agenten mit echten Nachfrage-Signalen arbeiten statt mit Annahmen. Das verbessert den Schritt zur Themenauswahl und hilft mir, Content zu priorisieren, der tatsächlich ranken kann.
Die Search-Console-Schicht speichert Snapshots in Supabase und berechnet Keyword-Chancen, Seiten mit niedriger CTR und Content-Lücken. Ich nutze diese Erkenntnisse im mcp cms, um sowohl Research als auch SEO zu steuern. Das bedeutet: Das System generiert nicht nur Artikel. Es hilft mir, bessere Publishing-Entscheidungen zu treffen.
Googles eigene Search Console documentation untermauert, warum das wichtig ist: Suchleistungsdaten sollten die Optimierung steuern – nicht nur Intuition. Ich wende dieses Prinzip direkt in der Pipeline an.
Was mir die Datenebene gibt
Warum hier Daten Intuition schlagen
Ich mag kreative Arbeit, aber Content-Strategie braucht Evidenz. Wenn ich Search-Console-Signale nutze, kann ich sehen, welche Seiten Hilfe brauchen und welche Themen neue Artikel verdienen. Das macht das mcp cms viel nützlicher als ein statisches Admin-Panel.
Warum ich Read Paths und Write Paths trenne
Ich habe bewusst die Read-Seite und die Write-Seite des Blogs getrennt. Öffentliche Seiten lesen nur über die Content-Schicht, während Admin-Aktionen über die Mutation-Schicht schreiben. Das hält das Rendering schnell und das Publishing sicher.
Diese Trennung ist wichtig, weil jede Seite eine andere Aufgabe hat. Die Read-Schicht braucht Caching, Metadaten und sauberes Fallback-Verhalten. Die Write-Schicht braucht Authentifizierung, Validierung und kontrollierte Mutationen. Im mcp cms teilen sich beide Schichten dieselben Contracts, aber sie verschwimmen niemals.
Diese Trennung macht es außerdem einfacher, später neue Interfaces hinzuzufügen. Wenn ich ein weiteres Dashboard baue oder wenn ich einen weiteren MCP-Client verbinde, muss ich nicht das ganze System neu entwerfen. Ich zeige einfach neue Tools auf dieselbe Write-Grenze.
Was diese Trennung schützt
Warum ich diese Struktur bevorzuge
Ich habe gesehen, wie Systeme scheitern, weil alles mit allem spricht. Diese Architektur reduziert dieses Risiko. Sie gibt dem mcp cms einen stabilen Kern und hält das Produkt leicht weiterentwickelbar.
Echte Ergebnisse und praktische Tradeoffs
Das größte Ergebnis war nicht ein fancy Dashboard. Es war Hebelwirkung. Ich kann jetzt von der Idee zu einem recherchierten Outline zu einem Entwurf zu einer SEO-Review wechseln, ohne zwischen Tools hin- und herzuspringen. Das spart Zeit und hält den Kontext intakt.
Ich bekomme außerdem bessere Sichtbarkeit darüber, was das System macht. Ich kann die Pipeline beobachten, Agent-Entscheidungen inspizieren und den Flow anpassen, wenn nötig. Das ist wichtiger als reine Automatisierungs-Geschwindigkeit. Ein gutes mcp cms sollte deinen Prozess stärker machen – nicht undurchsichtiger.
Es gibt jedoch Tradeoffs. Ein maßgeschneidertes System erfordert mehr Engineering-Aufwand als ein fertiges CMS. Du übernimmst die Bugs, die Features und die Wartung. Für mich lohnt sich diese Investition, weil der Workflow zu meiner Website und meiner Content-Strategie passt.
Was ich gewonnen habe
Was ich weiterhin managen muss
Wie ich jetzt über Content Operating Systems denke
Dieses Projekt hat verändert, wie ich über Content-Infrastruktur denke. Ich sehe CMS-Software nicht mehr als einen Ort, um Posts zu speichern. Ich sehe sie als ein Operating System für Content-Erstellung, Review und Publishing. Diese Denkverschiebung ist der Grund, warum sich dieses mcp cms nützlich anfühlt – statt nur dekorativ zu sein.
Wenn du etwas Ähnliches baust, starte zuerst mit dem Workflow. Definiere danach die Write-Grenze. Füge anschließend nur dann MCP-Tools hinzu, wenn Aktionen eine Automatisierung wirklich verdienen. Diese Reihenfolge hält das System gesund.
Ich empfehle außerdem, meine verwandten Artikel zu AI agents, scaling e-commerce mit Next.js und meinem SEO-Dashboard zu lesen. Diese Beiträge erklären die Bausteine hinter diesem Setup und zeigen, wie die Teile zusammenhängen.
Fazit
Die wichtigsten Learnings aus diesem Build sind simpel:
Ich habe dieses mcp cms gebaut, um mir Hebelwirkung, bessere Sichtbarkeit und einen saubereren Publishing-Flow zu geben. Wenn du dein eigenes Content-System entwirfst, starte mit dem Workflow und forme danach die Tools darum herum.
Wenn du möchtest, lies die verwandten Posts oben oder hinterlasse einen Kommentar dazu, wie du dein eigenes CMS strukturieren würdest.