Porque um servidor MCP no seu plugin WordPress é a jogada de IA que sobrevive

#Porque um servidor MCP no seu plugin WordPress é a jogada de IA que sobrevive

Dois pontos de dados de uma semana, maio de 2026.

Bryce Adams, fundador da Metorik, no WP Product Talk: a nova integração MCP da empresa atraiu 500 utilizadores em poucos dias após um lançamento discreto em preview, a adoção mais rápida de uma funcionalidade na sua experiência de dez anos. Mesma conversa, mesmo Adams: os clientes que saem da Metorik têm um MRR médio 40 por cento inferior aos que ficam. Leu isto como a IA a apanhar os casos de uso de commodity (relatórios básicos, dashboards simples) e a deixar em paz o trabalho analítico central.

A GravityKit tornou open-source o Block MCP esta semana. É um servidor MCP WordPress que opera ao nível do bloco, em vez de tratar o conteúdo do post como uma única string de HTML. A equipa construiu-o porque os servidores MCP existentes baseados na REST API removem os delimitadores de blocos que o WordPress usa para identificar blocos, colapsando o conteúdo estruturado num bloco Classic. Esbarraram no bug vezes suficientes no próprio site para se comprometerem com uma correção.

Não são duas histórias. E uma história. Em 2026, o plugin WordPress que envia um servidor MCP e o plugin que compoe. O plugin que cola uma chatbox na administração e o plugin que e canibalizado.

Este texto e a continuação do nosso pilar de implementação de IA e liga-se directamente ao nosso trabalho de desenvolvimento de servidores MCP e a história de integração da Abilities API no WordPress 7.0. O argumento aqui e comercial: retenção, churn e qual superfície compoe.

#TL;DR

• Dois pontos de dados de maio de 2026 dizem o mesmo. Metorik MCP: 500 utilizadores em dias, adopção mais rápida em dez anos. Adams: MRR dos que saem 40 por cento inferior aos retidos, sugerindo que a IA apanha casos de commodity. GravityKit Block MCP: open-source, corrige o bug de remoção de delimitadores de bloco via REST API.
• Um servidor MCP expõe as operações de domínio do plugin como tools invocáveis pelo agente, que se compoem no agente escolhido pelo utilizador. Uma chatbox presa na administração do plugin so compoe consigo mesma.
• A camada de commodity do plugin (relatórios, dashboards, variantes de gráficos) e canibalizada por ferramentas de IA genericas que conseguem responder as mesmas perguntas a partir de dados em bruto. A camada profunda de domínio do plugin (atribuição personalizada, matematica de coortes, plumbing de integração) sobrevive porque a IA não tem o contexto de domínio a menos que o plugin lho de via MCP.
• O contrato do servidor MCP vive no repositório do plugin. Esse contrato e estável através das versões de modelos. Uma chatbox treinada contra o comportamento de um fornecedor de modelo específico muda sob o mantedor a cada seis semanas.
• Acção: envie um servidor MCP, exponha de três a sete operações de domínio como tools, documente o contrato no repositório, versione a superfície MCP separadamente da versão de UI do plugin.

#O experimento natural que o Adams conduziu

O Adams disse no WP Product Talk que estava nervoso com a IA pela mesma razão que qualquer autor de plugin esta nervoso com a IA em 2026: o fundo da piramide de valor (relatórios básicos, agregações simples) e exactamente onde a IA e mais rápida a copiar. Podia imaginar um mundo onde o Claude ou o ChatGPT, apontados aos mesmos dados em bruto do Shopify ou WooCommerce, produzem os mesmos gráficos que a Metorik produz, de graca.

O que encontrou em vez disso, depois de um ano a observar, foi que os clientes que saiam da Metorik eram sistematicamente os de baixo MRR. MRR médio dos que saem 40 por cento abaixo dos retidos. A sua interpretação: a IA fez exactamente o que ele temia no fundo da piramide, e exactamente nada no topo.

Isto é um experimento natural porque o Adams não o desenhou. Aconteceu-lhe enquanto o mercado se deslocava. Os dados dizem-lhe quais as funções que a Metorik fornece que são de commodity (foram para a IA) e quais são duradouras (a Metorik retém o cliente). O Adams listou os casos de uso dos clientes retidos como: atribuição de gastos de publicidade, matemática de coortes, segmentação personalizada, integração com APIs de stock e fulfilment, agregação multi-loja. Estas não são funções de gráfico. São operações de domínio que exigem a implementação específica da Metorik, contra a forma de dados específica que o produto conquistou ao longo de uma década.

Para o leitor português, o paralelo é direto. A cena de agências WordPress no eixo Lisboa-Porto cresceu nos últimos dois anos em torno da integração com SaaS B2B nacional, em particular InvoiceXpress, Moloni e Cegid Primavera. Quando um cliente B2B português pede uma loja WooCommerce com faturação certificada AT, o problema não é o plugin de faturação, é a maneira como ele compõe com o agente interno do cliente que já anda a falar com o Claude ou com o Copilot da Microsoft. A discussão em torno do trabalho do Felix Arntz e do Felipe Elia na WP AI Client, levada ao WordCamp Europe e antecipada na WordCamp Portugal de 2026, vai exatamente nesta direção: expor capacidades do WordPress como tools que o agente do cliente possa invocar. Sem um servidor MCP no plugin de faturação certificada, o caminho direto entre o agente e a AT fica bloqueado por mais uma camada de middleware. Com um servidor MCP, o caminho fica aberto, e o plugin torna-se canalização indispensável em vez de uma caixa de chat que ninguém usa.

Depois apareceu a integração MCP, e 500 clientes retidos pegaram nela na primeira semana.

A integração MCP não é uma nova funcionalidade do produto. É uma forma de o agente do cliente (Claude Desktop, Claude Code, ChatGPT Enterprise, uma stack interna personalizada) chamar essas mesmas operações de domínio dos clientes retidos como tools. O cliente faz agora no seu agente o que costumava fazer iniciando sessão na Metorik. A Metorik não os perdeu, tornou-se canalização invisível debaixo do workflow do agente.

Esse é o fosso.

#Porque o Block MCP importa mais do que a sua forma de plugin sugere

O Block MCP da GravityKit e tecnicamente um plugin pequeno. Um servidor MCP WordPress, expondo edição ao nível do bloco como tools. A razão pela qual importa e que identifica o modo de falha de todas as tentativas anteriores de MCP no WordPress.

Os servidores MCP existentes do WordPress (e ha vários) escrevem através da REST API do WordPress. A REST API trata content como uma única string de HTML. O WordPress usa internamente comentários HTML como delimitadores de blocos (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Quando o agente edita a string de conteúdo e a escreve de volta, os comentários delimitadores de blocos so sobrevivem se o agente souber deles. A maioria dos agentes não sabe. A ida e volta do HTML remove os delimitadores. O post que era uma stack estruturada de vinte blocos torna-se um único bloco Classic ao guardar.

O gestor de ops estratégico da GravityKit, Casey Burridge, disse que a equipa esbarrou no bug repetidamente no próprio site. Qualquer pessoa que tenha tentado construir um agente de edição de conteúdo contra a REST API do WordPress esbarrou nele.

O Block MCP corrige o modo de falha ao expor operações ao nível do bloco como tools MCP. add_block, update_block, move_block, delete_block, em vez de get_content mais set_content. O agente ve o post como uma árvore, não uma string. O contrato e estável através das actualizações de blocos do WordPress, porque o contrato e definido no servidor MCP, não em qualquer serializador de HTML que o core do WordPress envie hoje.

MCP envolto em REST fica ferramenta de commodity. MCP desenhado em torno do domínio torna-se uma superfície duradoura. O Block MCP e o primeiro servidor MCP WordPress a operar na camada de domínio (os blocos são o primitivo de domínio do conteúdo do WordPress), em vez de operar na camada de transporte da API.

Este e o padrão. Cada autor de plugin deve perguntar: qual é o primitivo de domínio do meu plugin, e o meu servidor MCP esta a expo-lo, ou esta a expor um endpoint REST envolto?

#O que e um servidor MCP, em dois paragrafos

O Model Context Protocol e um standard aberto da Anthropic para a forma como os agentes de IA descobrem e chamam tools. Um servidor MCP expõe uma lista de tools (cada uma com um nome, uma descrição, uma JSON schema para inputs e uma implementação), e qualquer agente capaz de MCP (Claude Desktop, Claude Code, ChatGPT Enterprise, stacks personalizadas) pode ligar-se, descobrir as tools e chama-las. O servidor pode ser local (stdio) ou remoto (SSE / HTTP). Para um plugin WordPress, o caso local e a forma correcta: o servidor corre ao lado do plugin, o agente liga-se a partir da máquina do utilizador.

O autor do plugin define as tools. Esse e todo o ponto. As tools são as operações de domínio do plugin, nomeadas no vocabulario do plugin, com schemas de input que reflectem o modelo de dados do plugin. O agente opera agora ao nível de conhecimento de domínio do plugin. O cliente faz no chat o que costumava fazer clicando em cinco ecrãs de administração.

No nosso tech radar, o Anthropic Model Context Protocol esta no anel Adopt, WordPress Abilities API em Trial (a superfície canonica de integração no WordPress 7.0 e posteriores), e recentemente adicionamos wp-agentic-admin (CloudFest Hackathon 2026) em Assess como implementação de referência do padrão.

#A matriz dois por dois

O plugin WordPress de 2026 vive numa matriz dois por dois:

O quadrante de domínio raso (linha de cima) e onde a maioria dos lançamentos de “plugin de IA WordPress” se senta. Envolvem uma camada fina de funcionalidade básica (exportação CSV, gráficos simples, sugestões de reescrita de conteúdo) e ou adicionam uma chatbox ou não tem MCP de todo. Ambas as colunas são becos sem saída. A chatbox treina habitos de utilizador contra a superfície de commodity do plugin, e o servidor MCP não tem nada de diferenciado para expor.

O quadrante de domínio profundo (linha de baixo) e onde vivem os plugins duradouros. Metorik, JetEngine da Crocoblock, GravityForms, GravityView da GravityKit, são exemplos cada um. Sem MCP, estes plugins retem clientes mas tornam-se invisíveis aos workflows de agentes. Com MCP, compoem-se em workflows de agentes e tornam-se canalização indispensável.

A pergunta interessante para um autor de plugin neste quadrante não e “devemos enviar MCP” (sim), e “quais são as três a sete operações correctas a expor”.

#Escolher as operações a expor

Os autores de plugins muitas vezes querem expor cada endpoint CRUD como tools MCP. Isto e errado. O ponto do MCP não e acesso a API, e operações ao nível de domínio. Uma lista longa de tools triviais confunde o agente e produz chamadas de baixa qualidade. Uma lista curta de operações significativas e o que torna o agente útil.

A heuristica que usamos:

1. Liste as acções que um cliente toma no seu plugin numa semana típica. Ordene por frequência.
2. Agrupe-as em clusters de acções relacionadas. Para a Metorik, um cluster pode ser “consultas de atribuição de publicidade”, outro “segmentação de coortes”.
3. Para cada cluster, defina uma única tool MCP que recebe os parâmetros do cluster e devolve o resultado do cluster. A tool e a operação de domínio, não o endpoint da API.
4. Limite a lista a sete. Se tem mais de sete, não terminou o clustering.
5. Cada tool recebe uma descrição de um parágrafo no servidor MCP. A descrição e o que o agente le para decidir quando usa-la. Optimize para a leitura do agente, não para a completude da documentação humana.

Um autor de plugin que siga isto obtem uma superfície MCP com cinco a sete tools, cada uma significativa, cada uma relevante para o cliente retido. O agente le as descrições e escolhe correctamente. O workflow diário do cliente inclui agora as operações de domínio do plugin como pedidos em linguagem natural.

#O contrato vive no repositório

Autores de plugins que começam por “vamos adicionar o Claude a nossa administração” metem o contrato no sítio errado.

Uma chatbox colada a administração do plugin tem um contrato que vive no prompt da chatbox, na mensagem de sistema e na camada de chamada de tools. Quando o fornecedor de modelo subjacente muda o formato de function-calling (isto aconteceu três vezes nos últimos 18 meses na Anthropic, OpenAI e Google), a chatbox parte-se até o mantedor actualizar o wrapper. O contrato da chatbox não e duradouro. O seu ciclo de vida e a API do fornecedor de modelo.

O contrato de um servidor MCP vive no repositório do plugin como uma JSON schema por tool. O contrato e estável através das versões de modelos. Quando a Anthropic actualiza o tool-calling do Claude, o agente actualiza, não o servidor MCP. Quando a OpenAI envia uma nova forma de function-calling, o mesmo servidor MCP continua a funcionar, porque o MCP e o standard a que o fornecedor de modelo se adapta. O autor do plugin escreve as tools uma vez e envia-as.

Esta e a forma de engenharia duradoura. A chatbox e a forma descartável.

O cliente nota isto num horizonte de vários anos. A chatbox que funcionou em 2025 partiu duas vezes em 2026. O servidor MCP que foi enviado em 2025 ainda funciona em 2026 com o agente escolhido pelo cliente. O cliente confia no plugin que envia a superfície duradoura.

#Contraposição: e o wp-agentic-admin?

Um leitor que analise o projeto CloudFest Hackathon 2026 wp-agentic-admin encontra outro modelo: um WebLLM no browser (Qwen 1.7B ou 7B via WebGPU), executado inteiramente no dispositivo do utilizador e ligado à WordPress Abilities API através de um loop ReAct. A lógica fica local, sem custo de API e sem modelo remoto.

Esse modelo tem o seu lugar. É uma boa correspondência para o administrador WordPress single-tenant, hobbyista ou paranóico em relação à privacidade que quer triar o seu próprio site sem dependência externa. Não é a resposta duradoura para plugins que servem equipas B2B que já correm Claude Enterprise, ChatGPT Enterprise ou stacks de agentes self-hosted em todos os seus workflows internos.

Para essas equipas, o agente com o qual querem falar ao plugin WordPress é o mesmo agente que usam para o CRM, o data warehouse, o issue tracker e a documentação. O servidor MCP é o que torna o plugin disponível a esse agente. O WebLLM no browser é um universo paralelo sem alcance composicional.

Ambos os modelos são validos. O padrão do servidor MCP e o que se alinha com a forma como as equipas de clientes B2B já trabalham.

#O que isto significa para o leitor da wppoland

Se envia um plugin WordPress ou WooCommerce: construa o servidor MCP. Três a sete operações de domínio, expostas como tools, contrato no repositório, versionado separadamente da versão de UI do plugin. Faca isto antes de adicionar uma chatbox. Se so pode fazer uma coisa, faça o servidor MCP.

Se opera um site WordPress a escala (multi-site, agência, enterprise): quando avalia plugins para adopção, pergunte “envia um servidor MCP” da mesma forma que costumava perguntar “tem uma REST API”. A pergunta MCP e o equivalente em 2026.

Se e um cliente da wppoland a avaliar onde investir esforço de engenharia em 2026: e aqui que sugerimos investir. Construímos Claude skills e servidores MCP personalizados para equipas B2B que correm workflows agent-first no WordPress. O entregável e o servidor MCP, as tools de domínio, o contrato e o onboarding da equipa. O entregável não e uma chatbox.

#Argumento final

O ponto de dados da Metorik de maio de 2026 e o lançamento open-source do Block MCP são o mesmo sinal em escalas diferentes. O plugin que expõe as suas operações de domínio como tools MCP compoe-se com qualquer agente que o cliente adopte. O plugin que não o faz e canibalizado na camada de commodity e fica invisível na camada de domínio.

Existe uma pequena janela operacional em 2026 para enviar MCP antes que o mercado espere que cada plugin o tenha. Os autores de plugins que pegam na superfície MCP este ano são os que estarão na allow-list do integrador de agentes quando o mercado o alcançar.

#Fontes

• Bryce Adams no WP Product Talk (transcrição via WP Product Talk)
• Documentação da integração MCP da Metorik
• Lançamento open-source do GravityKit Block MCP
• Anthropic Model Context Protocol
• Retrospectiva de 8 anos do JetEngine da Crocoblock e MCP Command Center

#Relacionados no nosso site

• Pilar: Consultoria de implementação de IA
• Desenvolvimento de servidores MCP
• WordPress 7.0 features: infraestrutura de IA e resumo da Abilities API
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Última verificação: 2026-05-23