WordPress MCP vs Headless CMS MCP: Qual se adapta melhor aos agentes de IA?

WordPress MCP agora tem uma rota oficial: a Abilities API, que chegou no WordPress 6.9, mais o MCP Adapter que transforma abilities em ferramentas que um agente pode chamar. Bom. CMSs headless chegaram nesse ponto mais cedo com servidores first-party próprios, enquanto sites baseados em git evitam muito dessa bagunça forçando cada edição de agente através de um pull request antes que possa chegar à produção. Nenhuma dessas stacks é segura por padrão. A diferença real é onde a segurança mora: na caixa, ou no trabalho que você faz ao seu redor. Este post compara stacks em vez de plugin contra plugin, e depois oferece a você um scorecard e uma visão cautelosa sobre onde sites executados por agentes podem viver em 2027.

O que o MCP muda: seu site ganha um agente que pode escrever

MCP somente leitura é uma caixa de busca com melhor comportamento. Um agente busca posts, os resume e identifica lacunas, e se o trabalho ficar errado, o site não é danificado. Nada quebra.

Acesso de escrita é diferente. Uma vez que um servidor expõe ferramentas de criar, atualizar, publicar e deletar, o agente se torna um usuário funcionando do seu site, com todo direito que seu token carrega. Pode reescrever uma página de preços às 3 da manhã. Pode publicar um rascunho que ninguém aprovou, e pode ser empurrado para qualquer erro pelo texto que lê no caminho. Mais sobre isso em breve.

A escolha de CMS portanto deixa de ser principalmente sobre editores e templates. Se torna uma questão de permissões, e quatro sub-questões fazem a maior parte do trabalho difícil.

1. Quão precisamente você pode limitar o que o agente é permitido fazer?
2. Pode ficar em rascunho, ou cada escrita vai ao vivo?
3. Existe uma trilha de auditoria, e você pode reverter?
4. Pode um humano ver o resultado antes do público?

Isso não é uma preocupação de nicho agora. A AISI do Reino Unido contou ferramentas MCP publicadas aumentando de cerca de 5.000 para 177.000 durante um ano, com downloads indo de 80.000 para 14 milhões. São muitos servidores para confiar, ou recusar confiar. Se você quer uma rotina para tomar essa decisão, escrevi uma em vetting Claude Code skills, plugins e MCP servers, e o quadro mais amplo de executar MCP em produção está no post MCP servers production stack.

WordPress, a rota oficial: a Abilities API e o MCP Adapter

A Abilities API chegou no WordPress 6.9. Dá ao core, themes e plugins um jeito padrão de declarar o que podem fazer, com schemas de entrada e callbacks de permissão anexados. O MCP Adapter fica acima dessa camada. É descrito como o pacote oficial WordPress para integração MCP, fica sob a organização WordPress GitHub, e pertence à iniciativa AI Building Blocks for WordPress. Seu trabalho é estreito mas importante: expor abilities como ferramentas MCP, recursos e prompts.

O que o README documenta:

• Transportes HTTP e STDIO, mais uma McpTransportInterface para protocolos customizados. Clientes se conectam através de WP-CLI sobre STDIO, ou apontando um cliente HTTP para /wp-json/mcp/mcp-adapter-default-server.
• Uma feature que chama de permissões granulares: autenticação de transporte por servidor e verificações de permissão por ability.
• As habilidades são privadas por padrão. Definir meta.public (ou meta.mcp.public) como true expõe uma.
• O servidor padrão oferece três meta-ferramentas: mcp-adapter/discover-abilities, mcp-adapter/get-ability-info e mcp-adapter/execute-ability.
• Tratamento de erros plugável e observabilidade através de McpErrorHandlerInterface e McpObservabilityHandlerInterface.

Privado por padrão é o instinto certo. Uma habilidade que ninguém marcou como pública não pode ser alcançada por um agente, por mais engenhosa que seja a instrução. Agora veja o que está ausente dessa lista: nenhum papel de agente apenas para rascunho, nenhuma etapa de aprovação integrada, nenhum registro de auditoria. Os ganchos de observabilidade são um lugar para construir um. Eles não são um registro de auditoria completo.

O controle de rascunho vive dentro das habilidades. Alguém tem que escrevê-las. Um plugin de terceiros, MS WordPress Abilities, mostra bem a forma desse trabalho. Ele registra 29 habilidades (26 personalizadas, mais três principais que aceitaram visibilidade MCP) e oferece uma atualização em dois estágios, preview-post-update e depois apply-post-update, enquanto patch-post-content não precisa de preparação. Design sensato. Ainda é uma escolha do autor, não do WordPress. De acordo com o mesmo README, o WordPress principal e o plugin IA oficial enviam apenas algumas habilidades por padrão.

Também ainda está se estabilizando. Uma issue aberta em 18 de março de 2026 apontou que o README do adaptador ainda falava sobre a necessidade da Abilities API depois que ela havia sido incorporada ao núcleo (issue 150). Em 24 de junho de 2026, um colaborador comentou lá que novas habilidades principais e de site pertencem ao plugin IA e à Abilities API, não ao adaptador, e que muitos documentos do adaptador ainda ensinam o modelo mais antigo de registrar habilidades arbitrárias e definir mcp.public. Depois, em 5 de fevereiro de 2026, um mantenedor do WordPress AI disse que não conhecia nenhum diretório de plugins implementando Abilities API ou suporte MCP (discussion 204). A infraestrutura é oficial. O catálogo de habilidades seguras e úteis continua limitado.

WordPress, a rota do plugin: muitas opções, um histórico de segurança limitado

A outra rota do WordPress é um plugin que fornece seu próprio servidor MCP. Nomes que aparecem em páginas de comparação de fornecedores incluem Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server e AI Engine. Estou os tratando como uma categoria aqui. Sem classificação. Também não estou repetindo suas reivindicações de recursos como fato. Uma ressalva importa: as páginas de comparação populares são executadas por fornecedores de plugins que se listam, então leia-as como marketing com uma tabela anexada.

O que a categoria oferece é velocidade. Instale o plugin, cole um token em seu cliente IA e você obtém ferramentas para posts, mídia e frequentemente usuários e configurações. O que custa é confiança. Você está entregando a um autor terceirizante um ponto de extremidade que pode agir como um usuário do WordPress, em um site PHP com uma área de administração completa atrás dele.

O único registro de segurança público que estou citando aqui pertence a um plugin, AI Engine:

• CVE-2025-11749. Em versões até 3.1.3, com a opção No-Auth URL ativada, o token do bearer MCP vazou pelas rotas REST públicas do site. Invasores não autenticados poderiam se autenticar no ponto de extremidade MCP e criar contas de administrador. Corrigido em 3.1.4 e publicado no NVD em 5 de novembro de 2025 (análise da SentinelOne, que situa o vazamento no endpoint /mcp/v1/ e diz que nenhum código de exploração pública verificado foi confirmado).
• CVE-2026-8719. Publicado em 17 de maio de 2026, classificado como alto (CVSS 8.8). Na versão 3.4.9, o caminho do token de bearer OAuth do MCP não verificava a capacidade de administrador, então um usuário de nível de assinante com um token válido poderia acessar ferramentas MCP em nível de administrador e se tornar um administrador (aviso do GitHub).
• Uma lista mais longa. WPScan lista muitos mais, incluindo uma tomada de conta de ferramentas de usuário MCP em multissite (corrigida em 3.6.1) e criação de conta de administrador via CSRF (corrigida em 3.6.6).

Seja justo sobre o que isso prova. É um plugin. Plugins populares atraem escrutínio, que é em parte por que este tem um registro, e um registro vazio em outro lugar não é evidência de segurança. Ainda assim, o padrão importa. Ambos os bugs principais são falhas de autorização na porta MCP, exatamente onde um agente recebe seu poder. Lembre-se dessa parte.

Servidores MCP de Headless CMS: Sanity, Strapi, Contentful e Payload

Plataformas headless construíram seus servidores MCP em torno do modelo de dados. Não ao redor de um admin PHP. Essa diferença aparece na documentação.

Sanity

Sanity executa um servidor hospedado em https://mcp.sanity.io sobre HTTP Streamable, com OAuth por padrão e autenticação de token como opção. Agentes podem executar consultas GROQ, gerenciar lançamentos e corrigir documentos com consciência do seu esquema. A configuração é npx sanity@latest mcp configure. O pacote @sanity/mcp-server local mais antigo está obsoleto. Essa é a rota atual.

Os documentos descrevem escrita orientada por rascunho: create_documents faz rascunhos a menos que você passe um releaseId, patch_documents salva na versão de rascunho ou lançamento, e conteúdo publicado nunca é modificado diretamente. Publicar é uma ferramenta separada. Patches para cada documento se aplicam como uma única transação. Um token pessoal compartilha sua função e o vincula a alterações no histórico de revisão, enquanto um token definido no cabeçalho Authorization atua dentro de sua própria função e escopo. Há duas ressalvas. O servidor também expõe administração de desenvolvimento e projeto (implantação de esquema, conjuntos de dados, origens CORS), então escopo o token com cuidado. E create_release não agenda nada, o que deve acontecer no Studio ou na API HTTP Actions.

Strapi

O servidor MCP do Strapi é integrado e executado dentro de sua própria instância. Apareceu pela primeira vez na v5.47.0 e alcançou disponibilidade geral na v5.49.0 (blog Strapi, 3 de setembro de 2026). Por padrão está desativado: server.mcp.enabled é false. Autentica-se com tokens de API de administrador e expõe ferramentas find, create, update, publish e unpublish por tipo de conteúdo. Um token nunca pode exceder as permissões do seu proprietário, e desativar o proprietário o revoga. Não cria tipos de conteúdo ou carrega mídia; essas operações ainda passam pela REST API (Strapi).

Contentful e Payload

Contentful publica um servidor MCP oficial de código aberto (licença MIT, pacote npm @contentful/mcp-server) que permite aos agentes gerenciar entradas e ativos, atualizar tipos de conteúdo e automatizar tarefas como marcação e migrações. Precisa de um token de acesso de gerenciamento e uma ID de espaço (Contentful). Existe um servidor comunitário separado que aponta para o oficial. Payload adiciona MCP através de um plugin oficial em vez de um servidor autônomo. Até aqui chego com relação ao Payload.

Se você está avaliando Sanity contra WordPress em termos mais amplos, Sanity vs WordPress for enterprise cobre o lado não-MCP. Comece por lá para essa parte da decisão.

Jamstack baseado em git: o pull request é a rede de segurança

O terceiro padrão não tem nenhum servidor CMS. O conteúdo vive no repositório como Markdown, MDX ou JSON tipado, e o site é Astro ou Next.js. Um agente de codificação edita arquivos. Abre um pull request, o host constrói um deploy de visualização, e uma pessoa lê o diff antes de fazer merge. Vercel e Netlify fazem deploy baseado em git e deploys de visualização, o que é tudo que esse padrão precisa de um host.

Esse loop de pull request não é exótico. Next.js documenta como suporta agentes de codificação de IA, e um tutorial do Microsoft Azure Static Web Apps mostra a fiação padrão: um workflow do GitHub Actions que dispara em pull request aberto, sincronizado, reaberdo e fechado, com um job separado para derrubar a visualização. É maquinário de entrega ordinário. Faz parte do apelo.

Por que funciona para agentes é simples. Cada mudança é um diff revisável. Nada chega à produção até que uma pessoa faça merge. Rollback é um git revert. O site público é saída estática, então não há login de administrador para que um token de agente roubado acesse.

Os custos são reais, porém. Editores não-técnicos encontram atrito, porque git não é sua ferramenta. Nada aqui é um servidor MCP documentado com histórico de segurança; o agente é um agente de codificação com acesso ao repositório, então sua exposição é o escopo de seu token git e tudo que seu shell possa alcançar. A higiene da cadeia de suprimentos ainda se aplica. Cobri isso em Next.js, Astro and Nuxt security in 2026.

Riscos de MCP em qualquer stack e os controles que os contêm

A NSA publicou uma Ficha de Informações de Segurança Cibernética sobre segurança de MCP em junho de 2026, e a Microsoft escreveu sobre o estado da segurança de MCP em 2026. Tirando o vocabulário, quatro riscos continuam aparecendo.

• Permissões herdadas. O agente pode fazer tudo que as credenciais do servidor MCP dele podem fazer. Um token de administrador significa um agente administrativo.
• Envenenamento de ferramentas. Descrições de ferramentas são lidas pelo modelo, então um servidor malicioso ou comprometido pode esconder instruções nelas. É por isso que servidores de terceiros merecem uma revisão antes de instalar.
• Injeção de prompt. Conteúdo que o agente lê (um comentário, uma página raspada, um ticket de suporte colado em um rascunho) pode carregar instruções. O agente pode obedecê-las com seu próprio acesso de escrita.
• Tokens sobre-privilegiados. A conveniência empurra as pessoas a entregar um token amplo. Não façam isso.

Os controles são chatos. Funcionam. Dê ao agente tokens com menor privilégio, prefira escopos somente leitura ou apenas rascunho, e coloque aprovação humana antes de publicar e deletar. Mantenha logs de auditoria que você realmente lerá. Rotacione tokens quando alguém sair. Nada disso é específico de stack, e esse é o ponto. A stack apenas decide quanto do trabalho já está feito para você.

O cartão de desempenho de prontidão do agente

Aqui está a comparação em um só lugar. As classificações vêm de recursos documentados e do registro público, com as fontes nomeadas acima. Ninguém executou essas pilhas através de uma suite de testes para esta tabela. Trate-a como uma comparação documentada, não como um resultado de laboratório.

Forte significa que a documentação a cobre por padrão. Parcial significa documentado mas incompleto, ou apoiado apenas por um registro breve. Depende da configuração significa que a pilha não decide. Sua configuração é que decide. Fraco significa problemas documentados.

Por que cada classificação, resumidamente.

WordPress + Adaptador. As permissões são fortes porque cada capacidade tem sua própria verificação e as capacidades são privadas até serem marcadas públicas. O controle de rascunho depende das capacidades que você instala, como o exemplo de atualização em estágio mostrou. A auditoria é parcial: interfaces de observabilidade existem, mas um registro de auditoria nativo não. A autenticação é parcial, com autenticação de transporte por servidor documentada em um nível elevado. O registro é parcial porque o pacote é novo e sua documentação está visivelmente em meio à migração.

Plugins WordPress. Nada é uniforme em uma categoria, então a maioria das células depende do plugin. O registro é fraco onde documentado: as entradas do AI Engine acima, e somente essas. Essa distinção importa.

Sanity. Tokens com escopo de função, escritas com padrão de rascunho, lançamentos e histórico de revisões conquistam as classificações fortes. A visualização é parcial porque um lançamento é um conceito de encenação, mas o servidor MCP não pode agendar ou publicar lançamentos. O registro é parcial no sentido de ser breve. Não é ruim.

Strapi. Ferramentas por tipo de conteúdo e tokens vinculados ao proprietário são fortes em permissões e autenticação. Publicar e despublicar são ferramentas separadas, e o servidor fica desligado até você ligá-lo. Auditoria e visualização dependem de como você executa sua instância. Auto-hospedagem também significa que a aplicação de patches é sua.

Contentful. O servidor oficial precisa de um token de gerenciamento e um ID de espaço, o que se lê como acesso amplo, então classifiquei permissões e autenticação como parciais. Tratamento de rascunho, auditoria e visualização dependem de como você configura espaços e funções. O trabalho importante está nessa configuração.

Payload. Um plugin oficial existe. Além disso, não tenho documentação primária para classificar, então cada célula se lê como depende da configuração. Essa é uma lacuna no que posso verificar. Não é um veredito.

Jamstack baseado em Git. Forte em quatro colunas porque o padrão em si as fornece: permissões de repositório no nível de branch, um pull request como porta de publicação, histórico git e reversões, deploys de preview. A autenticação depende do agente de codificação e seu token git. O registro é parcial porque não há superfície de admin CMS para atacar. A ferramenta de agente ainda carrega os mesmos riscos MCP que tudo mais.

Como escolher hoje, por situação

Você tem um WordPress estate existente

Fique quieto e seja rigoroso. Use o adaptador oficial, marque apenas as habilidades que você precisa como públicas e escreva ou escolha habilidades que preparem mudanças antes de aplicá-las. Um plugin de terceiros amplo com um token com capacidade de admin é a configuração mais arriscada nesta toda comparação. Se você quiser soltar o WordPress pela frente primeiro, o desenvolvimento WordPress headless é um caminho intermediário.

Você está começando uma nova construção

Se os agentes ajudarem a executá-lo, comece com headless ou baseado em git. Sanity ou Strapi oferecem drafts e tokens scoped prontos para uso. Astro ou Next.js em um repo oferece diffs e previews. Esse é um padrão forte para novos trabalhos.

Sua equipe de conteúdo é grande ou não técnica

Uma equipe de editores que vivem em uma interface visual não gostará de pull requests. Headless com um estúdio de edição adequado funciona melhor para eles, desde que o agente seja confinado a drafts. O editor do WordPress continua genuinamente bom aqui. Esse é um ponto a seu favor.

Você tem necessidades de conformidade

Pergunte onde o trilho de auditoria vive e quem é dono dele. O histórico Git é uma resposta forte. O histórico de revisão do Sanity é outro. Para WordPress, você estará construindo logging você mesmo. Opções auto-hospedadas (Strapi, WordPress) mantêm dados em sua infraestrutura, mas colocam patches em você, enquanto um servidor hospedado muda esse ônus para o fornecedor.

Chegando 2027: por que Jamstack pode ser a melhor casa para sites executados por IA

Esta seção é opinião, não uma descoberta, e a mantenho solta.

Por que Jamstack pode sair na frente. O conteúdo é estruturado e tipado. Toda mudança de agente pode ser um diff que um humano revisa. Deploys de preview mostram o resultado antes de ficar ao vivo. O rollback é um revert git. O site público não tem superfície de admin para um token de agente roubado alcançar. Os agentes são bons em editar arquivos e ruins em ser confiáveis, e essa configuração é construída para exatamente essa combinação.

Por que WordPress pode não perder. Tem a maior base de instalação e pool de talentos. A API de Abilities agora está no core, com um adaptador oficial ao lado. Fornecedores de plugins iteram rapidamente. A iteração rápida corrige muito, mesmo que tenha criado as CVEs acima.

O que WordPress precisaria. MCP no core, com habilidades mapeadas para capacidades por padrão. Funções de agente apenas rascunho. Um registro de auditoria nativo. Um registro de segurança melhor para plugins MCP. Essa é uma lista curta, e nada disso é impossível.

Se essa visão tem você pesando uma mudança, o guia para deixar WordPress é por onde começar.

Linha prática: para um novo site que agentes ajudarão a executar, comece com Jamstack ou headless. Para um WordPress estate existente, use o adaptador oficial com habilidades de menor privilégio em vez de um plugin de terceiros amplo. Seja chato aqui.

FAQ

Posso executar WordPress MCP em modo somente leitura?

Sim, em princípio. As habilidades são privadas por padrão, então exponha apenas as habilidades que leem dados e deixe qualquer coisa que escreva não registrada ou desmarcada. O adaptador não tem um único switch somente leitura. A disciplina fica em quais habilidades você registra.

Quais clientes de IA podem se conectar?

Para WordPress, qualquer coisa que fale MCP sobre HTTP ou STDIO (via WP-CLI). A documentação do Sanity lista Claude Code, Cursor, VS Code, Lovable, Replit e v0 como clientes compatíveis, e as sessões OAuth lá normalmente expiram após 7 dias. A escolha do cliente não é a parte difícil.

Um servidor MCP hospedado é mais seguro do que um auto-hospedado?

Ele troca um risco por outro. Um servidor hospedado como o do Sanity move patches para o fornecedor, mas você confia em seu scoping e sua higiene de token. Um servidor dentro de sua instância, como o do Strapi, mantém tudo em sua infraestrutura. As atualizações são seu trabalho.

Devo construir meu próprio servidor MCP?

Apenas se você precisar de um conjunto restrito de ferramentas que as oficiais não oferecem. Um servidor pequeno e dedicado com três ferramentas é mais fácil de entender do que um amplo. Há um passo a passo para construir um servidor MCP com Supabase e TypeScript. Mantenha a superfície pequena.

A ressalva mais aguda é a óbvia: um agente herda tudo que seu token pode fazer, e o único registro público de segurança de MCP nesta comparação é a lista de CVEs de um plugin WordPress, o que é motivo suficiente para delimitar tokens antes de escolher uma pilha. As classificações acima vêm da documentação e avisos públicos, não de testes. Trate a escolha de pilha como secundária ao modelo de permissões.