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.
Por que eu construí um MCP CMS em vez de usar uma stack headless genérica
Eu construí o site e o CMS no mesmo app Next.js porque eu queria uma base de código, um modelo de dados e um fluxo de publicação. Eu já usei stacks desconectadas o suficiente para saber como elas viram rapidamente dívida de manutenção. Quando o front-end, o CMS e a camada de automação ficam em lugares separados, cada mudança custa mais tempo do que deveria.
Meu mcp cms mantém o site público, a interface de admin, as rotas de API e as ferramentas de IA dentro de um mesmo limite de produto. Isso significa que eu consigo mudar metadados de SEO, localização (localization) ou lógica de artigos sem ter que pular entre três sistemas. Eu também evito o problema comum de “sincronização”, em que o conteúdo vive em uma ferramenta e a lógica real vive em outro lugar.
Na prática, isso me deu iterações mais rápidas e menos arestas quebradas. Também deixou o sistema mais fácil de observar, porque toda ação de escrita passa pela mesma camada. Se você quiser mais contexto sobre como eu penso em sistemas operacionais de conteúdo, meu post sobre Multi-Agent Content Pipeline in Next.js With Search Console mostra o lado de pesquisa desse fluxo.
A ideia central por trás do sistema
A ideia central é simples: o CMS deve se comportar como um produto, não como um construtor de formulários. Eu queria conteúdo tipado, escritas controladas e uma camada de automação que pudesse me ajudar a publicar mais rápido sem perder a supervisão. Por isso mantive a arquitetura rígida e os limites bem definidos.
O que eu mudei em relação a um CMS tradicional
Um CMS tradicional geralmente separa a edição de conteúdo do código do produto. Isso parece flexível, mas costuma desacelerar as equipes quando o site fica mais customizado. Meu mcp cms remove essa divisão. Agora eu consigo gerenciar conteúdo, SEO e lógica de workflow em um único lugar, o que me dá mais alavancagem com menos overhead.
Como o MCP CMS usa MCP como camada de controle
A decisão mais importante foi colocar o MCP no meio do sistema. Eu não queria recursos de IA presos dentro de uma única janela de chat ou de um único dashboard. Eu queria uma camada de comandos reutilizável que pudesse conversar com as mesmas regras de backend a partir de diferentes clientes.
Por isso eu construí tanto um servidor MCP standalone quanto uma rota MCP dentro do app. As ferramentas expostas pelo mcp cms incluem CRUD de blog, publicação, análise de SEO, geração de artigos, pesquisa, geração de imagens e checagens de sitemap. Em outras palavras, a camada de agentes não “adivinha” o que fazer. Ela chama ferramentas reais com estado real.
Essa abordagem se alinha com a especificação do Model Context Protocol e com a forma como eu gosto de estruturar sistemas internos: um contrato, múltiplos clientes, sem duplicação. Ela também facilitou reutilizar as mesmas ações dentro do dashboard de admin e a partir de clientes MCP externos.
Ferramentas que eu expus via MCP
A superfície de ferramentas é ampla de propósito. Eu queria que os agentes fizessem trabalho útil, não apenas conversar.
Esse design de ferramentas é a espinha dorsal do mcp cms. Ele mantém o sistema componível e faz com que cada operação seja observável.
Por que essa arquitetura importa no trabalho real
No meu trabalho construindo sites e sistemas de conteúdo, o maior gargalo raramente é escrever. O gargalo é coordenação. O MCP reduz esse custo de coordenação porque a mesma ação pode ser chamada a partir do dashboard, da interface de chat ou de outro fluxo de agente. Como resultado, eu passo menos tempo repetindo passos e mais tempo melhorando o resultado.
O dashboard de admin transforma o MCP CMS em uma central de controle
Eu não queria que a área de admin parecesse uma tela de CRUD chata. Eu construí como uma central de controle. Ela tem gerenciamento de posts para rascunhos, traduções, imagens, SEO e publicação, além de uma camada operacional onde eu posso rodar workflows de IA e acompanhar o movimento deles.
Dentro do dashboard, o chat MCP expõe as mesmas ferramentas de conteúdo que o resto do sistema. Eu posso listar posts, inspecionar um rascunho, disparar análise de SEO, iniciar pesquisa ou rodar o pipeline completo com uma solicitação em linguagem natural. A parte importante é que o chat não é mágica. Ele está ancorado nas mesmas ações tipadas que o restante do mcp cms usa.
Esse design economiza tempo na prática. Eu não preciso reconstruir interfaces para cada novo workflow. Eu só exponho outra ferramenta ou outro caminho de controle. Se você quiser ver como eu penso em automação no nível do sistema, How I Built My CMS With MCP and Agent Flows é o artigo mais amplo sobre essa configuração.
O que eu consigo fazer a partir do dashboard
O dashboard me permite avançar rápido sem perder o controle.
Por que eu uso uma central de controle em vez de um editor simples
Um editor simples funciona quando você só precisa escrever e publicar. Eu precisava de mais. Eu queria um lugar onde eu pudesse observar workflows, aprovar mudanças e intervir quando um modelo se desviasse do caminho. Esse é o valor real do mcp cms: ele me dá controle operacional, não apenas entrada de conteúdo.
Como o fluxo de agente do MCP CMS funciona de verdade
O fluxo de agente não é um único prompt gigante. Eu dividi em etapas para conseguir controlar a qualidade em cada passo. Isso importa porque trabalho com conteúdo é bagunçado. Pesquisa, SEO, estrutura e edição exigem raciocínios diferentes.
Aqui está o fluxo que eu uso com mais frequência:
Eu testei esse fluxo repetidamente porque eu não queria um pipeline de demonstração falso. Eu queria um sistema em que uma etapa possa empurrar feedback de volta para outra etapa. Esse ciclo de feedback é uma das razões pelas quais o mcp cms funciona melhor do que um assistente de escrita de passagem única.
Por que eu dividi o fluxo em etapas
Cada etapa resolve um problema diferente. Pesquisa reduz alucinação. SEO deixa a estrutura mais afiada. Edição protege a qualidade. Publicação limpa a saída final. Separar essas tarefas torna o sistema inteiro mais confiável e mais fácil de melhorar ao longo do tempo.
Como eu mantenho os agentes sem desviar
Eu mantenho os agentes com rédeas curtas usando entradas tipadas, saídas explícitas e checagens de qualidade. Isso me dá um resultado melhor do que uma cadeia de prompts vaga. Também torna falhas mais fáceis de diagnosticar, o que importa quando você depende de automação para trabalho de produção.
Search Console deixa o MCP CMS mais inteligente
Uma das partes mais fortes do sistema é que eu não dependo apenas de prompts. Eu conecto os dados do Search Console ao processo de pesquisa, então os agentes trabalham a partir de sinais reais de demanda, em vez de suposições. Isso melhora a etapa de seleção de tópicos e me ajuda a priorizar conteúdos que realmente podem ranquear.
A camada do Search Console armazena snapshots no Supabase e calcula oportunidades de keyword, páginas com CTR baixo e lacunas de conteúdo. Eu uso esses insights dentro do mcp cms para direcionar tanto a pesquisa quanto o SEO. Isso significa que o sistema não está apenas gerando artigos. Ele está me ajudando a tomar melhores decisões de publicação.
A própria documentação do Search Console do Google sustenta por que isso importa: dados de desempenho de busca devem orientar otimização, e não apenas intuição. Eu aplico esse princípio diretamente no pipeline.
O que a camada de dados me dá
Por que dados superam intuição aqui
Eu gosto de trabalho criativo, mas estratégia de conteúdo precisa de evidência. Quando eu uso sinais do Search Console, eu consigo ver quais páginas precisam de ajuda e quais tópicos merecem novos artigos. Isso torna o mcp cms muito mais útil do que um painel de admin estático.
Por que eu separo caminhos de leitura e caminhos de escrita
Eu separei intencionalmente o lado de leitura e o lado de escrita do blog. Páginas públicas só leem via camada de conteúdo, enquanto ações de admin escrevem via camada de mutação. Isso mantém o render rápido e a publicação segura.
Essa separação importa porque cada lado tem um trabalho diferente. A camada de leitura precisa de cache, metadados e um comportamento de fallback limpo. A camada de escrita precisa de autenticação, validação e mutações controladas. No mcp cms, as duas camadas compartilham os mesmos contratos, mas nunca se misturam.
Essa separação também facilita adicionar interfaces futuras. Se eu construir outro dashboard, ou se eu conectar outro cliente MCP, eu não preciso redesenhar o sistema inteiro. Eu só aponto novas ferramentas para o mesmo limite de escrita.
O que essa separação protege
Por que eu prefiro essa estrutura
Eu já vi sistemas falharem porque tudo conversa com tudo. Essa arquitetura reduz esse risco. Ela dá ao mcp cms um núcleo estável e mantém o produto fácil de evoluir.
Resultados reais e concessões práticas
O maior resultado não foi um dashboard sofisticado. Foi alavancagem. Agora eu consigo ir de uma ideia para um outline pesquisado, depois para um rascunho e, em seguida, para uma revisão de SEO sem ficar pulando entre ferramentas. Isso economiza tempo e mantém o contexto intacto.
Eu também ganho mais visibilidade do que o sistema está fazendo. Eu consigo acompanhar o pipeline, inspecionar decisões dos agentes e ajustar o fluxo quando necessário. Isso importa mais do que velocidade bruta de automação. Um bom mcp cms deve fortalecer seu processo, não deixá-lo mais opaco.
Mas existem concessões. Um sistema customizado exige mais esforço de engenharia do que um CMS pronto. Você assume os bugs, as funcionalidades e a manutenção. Para mim, esse custo vale a pena porque o workflow se encaixa no meu site e na minha estratégia de conteúdo.
O que eu ganhei
O que eu ainda preciso gerenciar
Como eu penso em sistemas operacionais de conteúdo agora
Esse projeto mudou a forma como eu penso em infraestrutura de conteúdo. Eu não vejo mais software de CMS como um lugar para armazenar posts. Eu vejo como um sistema operacional para criação, revisão e publicação de conteúdo. Essa mudança de mentalidade é por isso que este mcp cms parece útil em vez de apenas decorativo.
Se você estiver construindo algo parecido, comece pelo workflow primeiro. Depois defina o limite de escrita. Em seguida, adicione ferramentas MCP apenas para ações que mereçam automação. Essa ordem mantém o sistema sadio.
Eu também recomendo ler meus artigos relacionados sobre AI agents, scaling e-commerce with Next.js e my SEO dashboard. Essas partes explicam os blocos de construção por trás dessa configuração e mostram como as peças se conectam.
Conclusão
As principais lições dessa construção são simples:
Eu construí este mcp cms para me dar alavancagem, melhor visibilidade e um fluxo de publicação mais limpo. Se você estiver desenhando seu próprio sistema de conteúdo, comece pelo workflow e depois molde as ferramentas ao redor dele.
Se quiser, leia os posts relacionados acima ou deixe um comentário com como você estruturaria seu próprio CMS.