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.
Bu makale, mcp cms’imi Next.js, Supabase, MCP ve agent flows ile nasıl inşa ettiğimi anlatıyor. Mimariyi, araç katmanını, admin dashboard’u ve içerik hattını (content pipeline) ele alıyorum; böylece tüm sistemin pratikte nasıl çalıştığını görebilirsiniz.
Neden Genel Bir Headless Stack Kullanmak Yerine Bir MCP CMS İnşa Ettim
Siteyi ve CMS’i aynı Next.js uygulamasında oluşturdum; çünkü tek bir kod tabanı, tek bir veri modeli ve tek bir yayınlama akışı istiyordum. Yeterince kopuk stack kullandım; bunların bakım borcuna ne kadar hızlı dönüştüğünü biliyorum. Ön yüz, CMS ve otomasyon katmanı ayrı yerlerde yaşadığında, her değişiklik olması gerekenden daha fazla zaman maliyeti çıkarır.
Benim mcp cms’im; public site, admin UI, API route’ları ve AI tooling’i tek bir ürün sınırı içinde tutuyor. Bu sayede SEO meta verilerini, lokalizasyonu veya makale mantığını üç ayrı sistem arasında zıplamadan değiştirebiliyorum. Ayrıca, içeriğin bir araçta yaşayıp gerçek mantığın başka bir yerde yaşadığı “sync problemi”nin tipik halinden de kaçınıyorum.
Pratikte bu, daha hızlı iterasyon ve daha az bozuk kenar (broken edge) sağladı. Sistemi gözlemlemeyi de kolaylaştırdı; çünkü her yazma aksiyonu aynı katmandan akıyor. Operasyonel içerik sistemlerini nasıl düşündüğüm hakkında daha fazla bağlam istersen, Multi-Agent Content Pipeline in Next.js With Search Console yazım bu iş akışının araştırma tarafını gösteriyor.
Sistemin arkasındaki temel fikir
Temel fikir basit: CMS bir form builder gibi davranmamalı. Typed content, kontrollü yazımlar ve gözetimi kaybetmeden daha hızlı yayınlamama yardımcı olabilecek bir otomasyon katmanı istedim. Bu yüzden mimariyi katı tuttum ve sınırları net belirledim.
Geleneksel bir CMS’ten Ne Değiştirdim
Geleneksel bir CMS genellikle içerik düzenlemeyi ürün kod tabanından ayırır. Bu kulağa esnek geliyor; ancak site daha fazla özelleştikçe ekipleri çoğu zaman yavaşlatır. Benim mcp cms bu ayrımı kaldırıyor. Artık içerik, SEO ve workflow mantığını tek bir yerde yönetebiliyorum; bu da daha az ek yükle daha fazla kaldıraç (leverage) sağlıyor.
MCP, Kontrol Katmanı Olarak Nasıl Kullanılıyor
En önemli karar, MCP’yi sistemin ortasına yerleştirmekti. AI özelliklerinin tek bir sohbet penceresine ya da tek bir dashboard’a hapsolmasını istemedim. Farklı istemcilerden aynı arka uç (backend) kurallarını konuşabilen yeniden kullanılabilir bir komut katmanı istedim.
Bu yüzden hem bağımsız bir MCP server hem de uygulama içinde bir MCP route’u oluşturdum. mcp cms üzerinden açığa çıkan araçlar; blog CRUD, publishing, SEO analysis, article generation, research, image generation ve sitemap checks içeriyor. Başka bir deyişle, agent katmanı ne yapacağını tahmin etmiyor. Gerçek araçları, gerçek durum (state) ile çağırıyor.
Bu yaklaşım Model Context Protocol specification ile uyumlu ve iç sistemleri yapılandırmayı sevdiğim şekilde örtüşüyor: tek bir sözleşme (contract), birden fazla istemci, kopyalama yok. Ayrıca aynı aksiyonları admin dashboard içinde ve harici MCP client’larından yeniden kullanmayı kolaylaştırdı.
MCP üzerinden açığa çıkardığım araçlar
Araç yüzeyi (tool surface) bilerek geniş. Agent’ların sadece sohbet etmesini değil, faydalı işler yapmasını istedim.
Bu araç tasarımı mcp cms’in omurgasıdır. Sistemi birleştirilebilir (composable) tutar ve her operasyonu gözlemlenebilir hale getirir.
Bu mimari neden gerçek işte önemli
Web siteleri ve içerik sistemleri inşa ederken yaptığım işlerde en büyük darboğaz genellikle yazmak değildir. Koordinasyondur. MCP bu koordinasyon maliyetini azaltır; çünkü aynı aksiyon dashboard’tan, sohbet arayüzünden ya da başka bir agent flow’dan çağrılabilir. Sonuç olarak adımları tekrar etmek için daha az zaman harcıyor, çıktıyı iyileştirmek için daha çok zaman ayırıyorum.
Admin Dashboard, MCP CMS’i Bir Kontrol Odasına Dönüştürüyor
Admin alanının sıkıcı bir CRUD ekranı gibi hissetmesini istemedim. Onu bir kontrol odası olarak inşa ettim. Taslaklar, çeviriler, görseller, SEO ve yayınlama için post yönetimi var; ayrıca AI workflow’larını çalıştırabildiğim ve hareket ederken izleyebildiğim bir operasyonel katman da bulunuyor.
Dashboard içinde, MCP sohbeti sistemin geri kalanıyla aynı içerik araçlarını açığa çıkarır. Post’ları listeleyebilirim, bir taslağı inceleyebilirim, SEO analysis’i tetikleyebilirim, araştırmayı başlatabilirim ya da doğal dil isteğiyle tüm pipeline’ı çalıştırabilirim. Önemli olan kısım şu: sohbet sihirli değil. mcp cms’in geri kalanının kullandığı aynı typed actions ile temellendirilmiş.
Bu tasarım pratikte zaman kazandırır. Her yeni workflow için arayüzleri yeniden inşa etmem gerekmiyor. Sadece başka bir tool’u ya da başka bir kontrol yolunu açığa çıkarıyorum. Sistem seviyesinde otomasyonu nasıl düşündüğümü görmek istersen, How I Built My CMS With MCP and Agent Flows bu kurulumun etrafındaki daha geniş makaledir.
Dashboard’tan neler yapabiliyorum
Dashboard, kontrolü kaybetmeden hızlı hareket etmemi sağlar.
Neden basit bir editör yerine kontrol odası kullanıyorum
Basit bir editör, sadece yazıp yayınlamaya ihtiyacınız olduğunda işe yarar. Benim ihtiyacım daha fazlasıydı. Workflow’ları gözlemleyebileceğim, değişiklikleri onaylayabileceğim ve bir model rotadan çıktığında müdahale edebileceğim bir yer istedim. mcp cms’in gerçek değeri burada: sadece içerik girişi değil, operasyonel kontrol sağlıyor.
MCP CMS Agent Flow’u Aslında Nasıl Çalışıyor
Agent flow tek bir dev prompt değil. Her adımda kaliteyi kontrol edebilmem için onu aşamalara böldüm. Bu önemli; çünkü içerik işi dağınık (messy). Araştırma, SEO, yapı ve düzenleme her biri farklı türde muhakeme gerektirir.
En sık kullandığım akış şu:
Bu akışı defalarca test ettim; çünkü sahte bir demo pipeline istemedim. Bir aşamanın geri bildirim (feedback) üretip başka bir aşamaya geri itebilmesini sağlayan bir sistem istedim. Bu feedback döngüsü, mcp cms’in tek seferlik (single-pass) bir yazma asistanından daha iyi çalışmasının nedenlerinden biri.
Flow’u aşamalara ayırmanın nedeni
Her aşama farklı bir problemi çözer. Araştırma hallucination’ı azaltır. SEO yapıyı keskinleştirir. Düzenleme kaliteyi korur. Yayınlama nihai çıktıyı temizler. Bu görevleri ayırmak, sistemi zaman içinde daha güvenilir ve geliştirmesi daha kolay hale getirir.
Agent’ların rotadan çıkmasını nasıl engelliyorum
Agent’ları typed inputs, açık çıktılar (explicit outputs) ve kalite kontrolleriyle kısa bir tasma (short leash) altında tutuyorum. Bu, belirsiz bir prompt zincirinden daha iyi sonuç verir. Ayrıca, üretim işi için otomasyona güvendiğinizde başarısızlıkların teşhis edilmesini de kolaylaştırır.
Search Console, MCP CMS’i Daha Akıllı Hale Getiriyor
Sistemin en güçlü yanlarından biri, sadece prompt’lara güvenmemem. Search Console verisini araştırma sürecine bağlıyorum; böylece agent’lar varsayımlar yerine gerçek talep sinyallerinden çalışıyor. Bu, konu seçimi adımını iyileştiriyor ve gerçekten sıralanabilecek içerikleri önceliklendirmeme yardımcı oluyor.
Search Console katmanı snapshot’ları Supabase’te saklar ve anahtar kelime fırsatlarını, düşük CTR sayfalarını ve içerik boşluklarını hesaplar. Ben bu içgörüleri mcp cms içinde hem araştırmayı hem de SEO’yu yönlendirmek için kullanıyorum. Yani sistem sadece makale üretmiyor. Daha iyi yayınlama kararları vermeme yardımcı oluyor.
Google’ın kendi Search Console documentation bunun neden önemli olduğunu doğruluyor: arama performansı verisi optimizasyona rehberlik etmeli; sadece sezgiye değil. Bu prensibi pipeline içinde doğrudan kullanıyorum.
Veri katmanının bana verdikleri
Neden burada veri sezgiden daha iyi
Yaratıcı çalışmayı seviyorum; ama içerik stratejisi kanıt ister. Search Console sinyallerini kullandığımda hangi sayfaların yardıma ihtiyacı olduğunu ve hangi konuların yeni makaleleri hak ettiğini görebiliyorum. Bu da mcp cms’i statik bir admin panelden çok daha faydalı yapıyor.
Neden Okuma Yollarını ve Yazma Yollarını Ayırıyorum
Blog’un okuma tarafını ve yazma tarafını özellikle ayırdım. Public sayfalar yalnızca içerik katmanından okur; admin aksiyonları ise mutasyon katmanından yazar. Bu, render’ı hızlı ve yayınlamayı güvenli tutar.
Bu ayrım önemli; çünkü her iki tarafın işi farklı. Okuma katmanı cache, metadata ve temiz fallback davranışı ister. Yazma katmanı authentication, validation ve kontrollü mutasyonlar ister. mcp cms içinde iki katman aynı contract’ları paylaşır; ama asla birbirine karışmaz.
Bu ayrım ayrıca gelecekte arayüz eklemeyi kolaylaştırır. Başka bir dashboard inşa edersem ya da başka bir MCP client bağlarsam, tüm sistemi yeniden tasarlamam gerekmez. Sadece yeni araçları aynı yazma sınırına yönlendiririm.
Bu ayrım neyi koruyor
Neden bu yapıyı tercih ediyorum
Her şeyin her şeyle konuştuğu sistemlerin başarısız olduğunu gördüm. Bu mimari o riski azaltır. mcp cms’e istikrarlı bir çekirdek verir ve ürünün evrimini kolay tutar.
Gerçek Sonuçlar ve Pratik Tavizler
En büyük sonuç şık bir dashboard değildi. Kaldıraçtı. Artık fikirden araştırılmış taslağa, taslaktan SEO review’a geçerken araçlar arasında zıplamak zorunda kalmıyorum. Bu zaman kazandırır ve bağlamı (context) bozulmadan tutar.
Ayrıca sistemin ne yaptığını daha iyi görüyorum. Pipeline’ı izleyebilirim, agent kararlarını inceleyebilirim ve gerektiğinde akışı ayarlayabilirim. Bu, ham otomasyon hızından daha önemlidir. İyi bir mcp cms, sürecinizi güçlendirmeli; daha da opaklaştırmamalı.
Yine de tavizler var. Özel bir sistem, hazır bir CMS’ten daha fazla mühendislik eforu gerektirir. Hataları, özellikleri ve bakımını siz üstlenirsiniz. Benim için bu maliyet, workflow’un siteme ve içerik stratejime uyduğu için buna değer.
Kazandıklarım
Hâlâ yönetmem gerekenler
İçerik İşletim Sistemleri Hakkında Artık Nasıl Düşünüyorum
Bu proje, içerik altyapısı hakkında düşünme biçimimi değiştirdi. Artık CMS yazılımını gönderileri saklamak için bir yer olarak görmüyorum. Onu içerik üretimi, gözden geçirme ve yayınlama için bir işletim sistemi olarak görüyorum. Bu zihniyet değişimi, bu mcp cms’in dekoratif değil gerçekten faydalı hissettirmesinin nedeni.
Benzer bir şey inşa ediyorsanız, önce workflow ile başlayın. Ardından yazma sınırını (write boundary) tanımlayın. Sonra sadece otomasyona değer aksiyonlar için MCP araçları ekleyin. Bu sıra sistemi sağlıklı tutar.
Ayrıca AI agents, scaling e-commerce with Next.js ve my SEO dashboard ile ilgili diğer yazılarımı okumanızı öneririm. Bu parçalar, bu kurulumun arkasındaki yapı taşlarını açıklar ve parçaların nasıl birbirine bağlandığını gösterir.
Sonuç
Bu inşadan çıkan ana dersler basit:
Bu mcp cms’i; kendime kaldıraç, daha iyi görünürlük ve daha temiz bir yayınlama akışı vermek için inşa ettim. Kendi içerik sisteminizi tasarlıyorsanız, önce workflow ile başlayın; sonra araçları onun etrafında şekillendirin.
İsterseniz, yukarıdaki ilgili yazıları okuyun ya da kendi CMS’inizi nasıl yapılandıracağınızla ilgili bir yorum bırakın.