Jag ville inte ha ett ännu ett generiskt CMS som bara klistras ovanpå min webbplats. I min erfarenhet skapar den typen av upplägg alltid friktion. Jag ville ha ett mcp cms som kändes som en del av produkten, inte ett externt system som jag måste kämpa med varje dag.
Den här artikeln förklarar hur jag byggde mitt mcp cms med Next.js, Supabase, MCP och agentflöden. Jag går igenom arkitekturen, verktygsskiktet, adminpanelen och innehållspipelinen så att du kan se hur hela systemet fungerar i praktiken.
Varför jag byggde ett MCP CMS i stället för att använda en generisk headless-stack
Jag byggde både sajten och CMS:et i samma Next.js-app eftersom jag ville ha en kodbas, en datamodell och ett publiceringsflöde. Jag har använt tillräckligt många frånkopplade stackar för att veta hur snabbt de blir underhållsskuld. När frontend, CMS och automatiseringsskiktet lever på separata ställen kostar varje ändring mer tid än den borde.
Mitt mcp cms håller publika sajten, admin-UI:t, API-rutterna och AI-verktygen inom en och samma produktgräns. Det betyder att jag kan ändra SEO-metadata, lokalisering eller artikellogik utan att hoppa mellan tre system. Jag undviker också det vanliga “synk-problemet” där innehåll bor i ett verktyg och den verkliga logiken finns någon annanstans.
I praktiken gav det mig snabbare iteration och färre trasiga kanter. Det gjorde också systemet lättare att observera, eftersom varje skrivåtgärd går genom samma lager. Om du vill ha mer kontext kring hur jag tänker om operativa innehållssystem, visar mitt inlägg om Multi-Agent Content Pipeline in Next.js With Search Console forskningsdelen av det arbetsflödet.
Den grundläggande idén bakom systemet
Den grundläggande idén är enkel: CMS:et ska bete sig som en produkt, inte som en formulärbyggare. Jag ville ha typat innehåll, kontrollerade skrivningar och ett automatiseringslager som kan hjälpa mig publicera snabbare utan att tappa överblicken. Därför höll jag arkitekturen strikt och gränserna tydliga.
Vad jag ändrade jämfört med ett traditionellt CMS
Ett traditionellt CMS separerar vanligtvis innehållsredigering från produktens kodbas. Det låter flexibelt, men det saktar ofta ner team när sajten blir mer anpassad. Mitt mcp cms tar bort den splitten. Nu kan jag hantera innehåll, SEO och flödeslogik på ett ställe, vilket ger mig mer hävstång med mindre overhead.
Hur MCP CMS använder MCP som kontrollager
Det viktigaste beslutet var att placera MCP mitt i systemet. Jag ville inte att AI-funktioner skulle vara instängda i ett enda chattfönster eller en enda dashboard. Jag ville ha ett återanvändbart kommandolager som kan prata med samma backend-regler från olika klienter.
Därför byggde jag både en fristående MCP-server och en MCP-rutt i appen. Verktygen som exponeras via mcp cms inkluderar blog CRUD, publicering, SEO-analys, artikelgenerering, research, bildgenerering och kontroller av sitemap. Med andra ord: agentlagret gissar inte vad som ska göras. Det anropar riktiga verktyg med verklig state.
Det här upplägget matchar Model Context Protocol specification och hur jag gillar att strukturera interna system: ett kontrakt, flera klienter, ingen duplicering. Det gjorde det också enkelt att återanvända samma åtgärder i adminpanelen och från externa MCP-klienter.
Verktyg jag exponerade via MCP
Verktygsytan är medvetet bred. Jag ville att agenterna skulle göra användbart arbete, inte bara chatta.
Den här verktygsdesignen är ryggraden i mcp cms. Den gör systemet komponerbart och gör varje operation observerbar.
Varför den här arkitekturen spelar roll i verkligt arbete
När jag bygger webbplatser och innehållssystem är den största flaskhalsen sällan att skriva. Flaskhalsen är koordinering. MCP minskar den koordinationskostnaden eftersom samma åtgärd kan anropas från dashboarden, chattgränssnittet eller ett annat agentflöde. Som ett resultat lägger jag mindre tid på att upprepa steg och mer tid på att förbättra resultatet.
Adminpanelen gör att MCP CMS blir ett kontrollrum
Jag ville inte att adminområdet skulle kännas som en tråkig CRUD-skärm. Jag byggde det som ett kontrollrum. Det har posthantering för utkast, översättningar, bilder, SEO och publicering, plus ett operativt lager där jag kan köra AI-flöden och se dem röra sig framåt.
Inuti dashboarden exponerar MCP-chatten samma innehållsverktyg som resten av systemet. Jag kan lista inlägg, inspektera ett utkast, trigga SEO-analys, starta research eller köra hela pipelinen med en naturlighetsspråksförfrågan. Den viktiga delen är att chatten inte är magi. Den är förankrad i samma typade actions som resten av mcp cms använder.
Den designen sparar tid i praktiken. Jag behöver inte bygga om gränssnitt för varje nytt arbetsflöde. Jag exponerar bara ett till verktyg eller en till kontrollväg. Om du vill se hur jag tänker kring automatisering på systemnivå, How I Built My CMS With MCP and Agent Flows är den bredare artikeln om den här uppsättningen.
Vad jag kan göra från dashboarden
Dashboarden låter mig röra mig snabbt utan att tappa kontrollen.
Varför jag använder ett kontrollrum i stället för en enkel editor
En enkel editor fungerar när du bara behöver skriva och publicera. Jag behövde mer. Jag ville ha en plats där jag kan observera flöden, godkänna ändringar och ingripa när en modell börjar glida ur kurs. Det är det verkliga värdet i mcp cms: det ger mig operativ kontroll, inte bara inmatning av innehåll.
Hur MCP CMS agentflödet faktiskt fungerar
Agentflödet är inte ett enda jättelikt prompt. Jag delade upp det i steg så att jag kan kontrollera kvaliteten i varje del. Det spelar roll eftersom innehållsarbete är rörigt. Research, SEO, struktur och redigering kräver olika typer av resonemang.
Här är flödet jag använder oftast:
Jag testade det här flödet upprepade gånger eftersom jag inte ville ha en falsk demo-pipeline. Jag ville ha ett system där ett steg kan skicka feedback tillbaka till ett annat steg. Den feedback-loopen är en av anledningarna till att mcp cms fungerar bättre än en skrivassistent i ett enda pass.
Varför jag delar upp flödet i steg
Varje steg löser ett annat problem. Research minskar hallucinationer. SEO skärper strukturen. Redigering skyddar kvaliteten. Publicering städar den slutliga outputen. När man delar upp de uppgifterna blir hela systemet mer pålitligt och enklare att förbättra över tid.
Hur jag håller agenterna från att drifta
Jag håller agenterna i kort koppel med typade inputs, explicita outputs och kvalitetskontroller. Det ger mig ett bättre resultat än en vag promptkedja. Det gör också fel lättare att diagnostisera, vilket spelar roll när du förlitar dig på automatisering för produktionsarbete.
Search Console gör MCP CMS smartare
En av de starkaste delarna i systemet är att jag inte bara förlitar mig på prompts. Jag kopplar in Search Console-data i research-processen, så att agenterna arbetar utifrån verkliga efterfrågesignaler i stället för antaganden. Det förbättrar steget för ämnesval och hjälper mig prioritera innehåll som faktiskt kan ranka.
Search Console-lagret lagrar snapshots i Supabase och räknar ut nyckelords-möjligheter, sidor med låg CTR och luckor i innehåll. Jag använder de insikterna i mcp cms för att styra både research och SEO. Det betyder att systemet inte bara genererar artiklar. Det hjälper mig att fatta bättre publiceringsbeslut.
Googles egna Search Console-dokumentation stödjer varför detta spelar roll: data om sökprestanda bör styra optimering, inte bara intuition. Jag använder den principen direkt i pipelinen.
Vad datalagret ger mig
Varför data slår intuition här
Jag gillar kreativt arbete, men innehållsstrategi behöver evidens. När jag använder Search Console-signaler kan jag se vilka sidor som behöver hjälp och vilka ämnen som förtjänar nya artiklar. Det gör mcp cms mycket mer användbart än en statisk adminpanel.
Varför jag delar upp read paths och write paths
Jag separerade medvetet den del som läser och den del som skriver i bloggens flöde. Publika sidor läser bara via innehållslagret, medan adminåtgärder skriver via mutationslagret. Det håller rendering snabb och publicering säker.
Den här splitten spelar roll eftersom varje sida har ett annat jobb. Read-lagret behöver caching, metadata och ett rent fallback-beteende. Write-lagret behöver autentisering, validering och kontrollerade mutationer. I mcp cms delar båda lagren samma kontrakt, men de flyter aldrig ihop.
Den här separationen gör det också enklare att lägga till framtida gränssnitt. Om jag bygger en till dashboard, eller om jag kopplar in en annan MCP-klient, behöver jag inte redesigna hela systemet. Jag pekar bara nya verktyg mot samma write-gräns.
Vad den här separationen skyddar
Varför jag föredrar den här strukturen
Jag har sett system misslyckas eftersom allt pratar med allt. Den här arkitekturen minskar den risken. Den ger mcp cms en stabil kärna och håller produkten lätt att utveckla.
Verkliga resultat och praktiska avvägningar
Det största resultatet var inte en snygg dashboard. Det var hävstång. Nu kan jag gå från idé till researchad outline till utkast till SEO-granskning utan att studsa mellan verktyg. Det sparar tid och håller kontexten intakt.
Jag får också bättre insyn i vad systemet gör. Jag kan följa pipelinen, inspektera agentbeslut och justera flödet när det behövs. Det betyder mer än rå hastighet i automatisering. Ett bra mcp cms bör göra din process starkare, inte mer ogenomskinlig.
Det finns dock avvägningar. Ett anpassat system kräver mer ingenjörsarbete än ett färdigt CMS. Du äger buggarna, funktionerna och underhållet. För mig är den kostnaden värd det eftersom arbetsflödet passar min webbplats och min innehållsstrategi.
Vad jag fick
Vad jag fortfarande måste hantera
Hur jag tänker på innehålls-operativsystem nu
Det här projektet förändrade hur jag ser på innehållsinfrastruktur. Jag ser inte längre CMS-programvara som en plats för att lagra inlägg. Jag ser det som ett operativsystem för innehållsskapande, granskning och publicering. Den tankeförskjutningen är varför mitt mcp cms känns användbart i stället för dekorativt.
Om du bygger något liknande: börja med arbetsflödet först. Definiera sedan write-gränsen. Lägg därefter bara till MCP-verktyg för actions som förtjänar automatisering. Den ordningen håller systemet sunt.
Jag rekommenderar också att du läser mina relaterade artiklar om AI agents, scaling e-commerce med Next.js och min SEO-dashboard. De delarna förklarar byggblocken bakom den här uppsättningen och visar hur delarna hänger ihop.
Slutsats
De viktigaste lärdomarna från det här bygget är enkla:
Jag byggde det här mcp cms för att ge mig hävstång, bättre insyn och ett renare publiceringsflöde. Om du designar ditt eget innehållssystem: börja med arbetsflödet och forma sedan verktygen runt det.
Om du vill kan du läsa de relaterade inläggen ovan eller lämna en kommentar om hur du skulle strukturera ditt eget CMS.