Porque um servidor MCP no seu plugin WordPress e 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 integracao MCP da empresa atraiu 500 utilizadores em poucos dias apos um lancamento discreto em preview, a adopcao mais rapida de uma funcionalidade na sua experiencia de dez anos. Mesma conversa, mesmo Adams: os clientes que saem da Metorik tem um MRR medio 40 por cento inferior aos que ficam. Leu isto como a IA a apanhar os casos de uso de commodity (relatorios basicos, dashboards simples) e a deixar em paz o trabalho analitico central.
A GravityKit tornou open-source o Block MCP esta semana. E um servidor MCP WordPress que opera ao nivel do bloco, em vez de tratar o conteudo do post como uma unica 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 conteudo estruturado num bloco Classic. Esbarraram no bug vezes suficientes no proprio site para se comprometerem com uma correcao.
Nao sao duas historias. E uma historia. Em 2026, o plugin WordPress que envia um servidor MCP e o plugin que compoe. O plugin que cola uma chatbox na administracao e o plugin que e canibalizado.
Este texto e a continuacao do nosso pilar de implementacao de IA e liga-se directamente ao nosso trabalho de desenvolvimento de servidores MCP e a historia de integracao da Abilities API no WordPress 7.0. O argumento aqui e comercial, nao apenas tecnico.
TL;DR
- Dois pontos de dados de maio de 2026 dizem o mesmo. Metorik MCP: 500 utilizadores em dias, adopcao mais rapida 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 remocao de delimitadores de bloco via REST API.
- Um servidor MCP expoe as operacoes de dominio do plugin como tools invocaveis pelo agente, que se compoem no agente escolhido pelo utilizador. Uma chatbox presa na administracao do plugin so compoe consigo mesma.
- A camada de commodity do plugin (relatorios, dashboards, variantes de graficos) e canibalizada por ferramentas de IA genericas que conseguem responder as mesmas perguntas a partir de dados em bruto. A camada profunda de dominio do plugin (atribuicao personalizada, matematica de coortes, plumbing de integracao) sobrevive porque a IA nao tem o contexto de dominio a menos que o plugin lho de via MCP.
- O contrato do servidor MCP vive no repositorio do plugin. Esse contrato e estavel atraves das versoes de modelos. Uma chatbox treinada contra o comportamento de um fornecedor de modelo especifico muda sob o mantedor a cada seis semanas.
- Accao: envie um servidor MCP, exponha de tres a sete operacoes de dominio como tools, documente o contrato no repositorio, versione a superficie MCP separadamente da versao 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 razao que qualquer autor de plugin esta nervoso com a IA em 2026: o fundo da piramide de valor (relatorios basicos, agregacoes simples) e exactamente onde a IA e mais rapida 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 graficos 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 medio dos que saem 40 por cento abaixo dos retidos. A sua interpretacao: a IA fez exactamente o que ele temia no fundo da piramide, e exactamente nada no topo.
Isto e um experimento natural porque o Adams nao o desenhou. Aconteceu-lhe enquanto o mercado se deslocava. Os dados dizem-lhe quais as funcoes que a Metorik fornece que sao de commodity (foram para a IA) e quais sao duradouras (a Metorik retem o cliente). O Adams listou os casos de uso dos clientes retidos como: atribuicao de gastos de publicidade, matematica de coortes, segmentacao personalizada, integracao com APIs de stock e fulfilment, agregacao multi-loja. Estas nao sao funcoes de grafico. Sao operacoes de dominio que exigem a implementacao especifica da Metorik, contra a forma de dados especifica que o produto conquistou ao longo de uma decada.
Para o leitor portugues, o paralelo e directo. A cena de agencias WordPress no eixo Lisboa-Porto cresceu nos ultimos dois anos em torno da integracao com SaaS B2B nacional, em particular InvoiceXpress, Moloni e Cegid Primavera. Quando um cliente B2B portugues pede uma loja WooCommerce com facturacao certificada AT, o problema nao e o plugin de facturacao, e a maneira como ele compoe com o agente interno do cliente que ja anda a falar com o Claude ou com o Copilot da Microsoft. A discussao 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 exactamente nesta direccao: expor capacidades do WordPress como tools que o agente do cliente possa invocar. Sem um servidor MCP no plugin de facturacao certificada, o caminho directo 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 canalizacao indispensavel em vez de uma caixa de chat que ninguem usa.
Depois apareceu a integracao MCP, e 500 clientes retidos pegaram nela na primeira semana.
A integracao MCP nao e uma nova funcionalidade do produto. E uma forma de o agente do cliente (Claude Desktop, Claude Code, ChatGPT Enterprise, uma stack interna personalizada) chamar essas mesmas operacoes de dominio dos clientes retidos como tools. O cliente faz agora no seu agente o que costumava fazer iniciando sessao na Metorik. A Metorik nao os perdeu, tornou-se canalizacao invisivel debaixo do workflow do agente.
Esse e 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 edicao ao nivel do bloco como tools. A razao 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 varios) escrevem atraves da REST API do WordPress. A REST API trata content como uma unica string de HTML. O WordPress usa internamente comentarios HTML como delimitadores de blocos (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Quando o agente edita a string de conteudo e a escreve de volta, os comentarios delimitadores de blocos so sobrevivem se o agente souber deles. A maioria dos agentes nao sabe. A ida e volta do HTML remove os delimitadores. O post que era uma stack estruturada de vinte blocos torna-se um unico bloco Classic ao guardar.
Isto nao e hipotetico. O gestor de ops estrategico da GravityKit, Casey Burridge, disse que a equipa esbarrou no bug repetidamente no proprio site. Qualquer pessoa que tenha tentado construir um agente de edicao de conteudo contra a REST API do WordPress esbarrou nele.
O Block MCP corrige o modo de falha ao expor operacoes ao nivel 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 arvore, nao uma string. O contrato e estavel atraves das actualizacoes de blocos do WordPress, porque o contrato e definido no servidor MCP, nao em qualquer serializador de HTML que o core do WordPress envie hoje.
O ponto mais profundo: a diferenca entre “MCP envolto em REST” e “MCP desenhado em torno do dominio” e a diferenca entre ferramenta de commodity e uma superficie duradoura. O Block MCP e o primeiro servidor MCP WordPress a operar na camada de dominio (os blocos sao o primitivo de dominio do conteudo do WordPress), em vez de operar na camada de transporte da API.
Este e o padrao. Cada autor de plugin deve perguntar: qual e o primitivo de dominio 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 expoe uma lista de tools (cada uma com um nome, uma descricao, uma JSON schema para inputs e uma implementacao), 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 maquina do utilizador.
O autor do plugin define as tools. Esse e todo o ponto. As tools sao as operacoes de dominio do plugin, nomeadas no vocabulario do plugin, com schemas de input que reflectem o modelo de dados do plugin. O agente opera agora ao nivel de conhecimento de dominio do plugin. O cliente faz no chat o que costumava fazer clicando em cinco ecras de administracao.
No nosso tech radar, o Anthropic Model Context Protocol esta no anel Adopt, WordPress Abilities API em Trial (a superficie canonica de integracao no WordPress 7.0 e posteriores), e recentemente adicionamos wp-agentic-admin (CloudFest Hackathon 2026) em Assess como implementacao de referencia do padrao.
A matriz dois por dois
O plugin WordPress de 2026 vive numa matriz dois por dois:
| Sem servidor MCP | Tem servidor MCP | |
|---|---|---|
| Dominio raso | Commodity, e canibalizado | Engenharia desperdicada |
| Dominio profundo | Retido, mas invisivel para agentes | Compoe |
O quadrante de dominio raso (linha de cima) e onde a maioria dos lancamentos de “plugin de IA WordPress” se senta. Envolvem uma camada fina de funcionalidade basica (exportacao CSV, graficos simples, sugestoes de reescrita de conteudo) e ou adicionam uma chatbox ou nao tem MCP de todo. Ambas as colunas sao becos sem saida. A chatbox treina habitos de utilizador contra a superficie de commodity do plugin, e o servidor MCP nao tem nada de diferenciado para expor.
O quadrante de dominio profundo (linha de baixo) e onde vivem os plugins duradouros. Metorik, JetEngine da Crocoblock, GravityForms, GravityView da GravityKit, sao exemplos cada um. Sem MCP, estes plugins retem clientes mas tornam-se invisiveis aos workflows de agentes. Com MCP, compoem-se em workflows de agentes e tornam-se canalizacao indispensavel.
A pergunta interessante para um autor de plugin neste quadrante nao e “devemos enviar MCP” (sim), e “quais sao as tres a sete operacoes correctas a expor”.
Escolher as operacoes a expor
Os autores de plugins muitas vezes querem expor cada endpoint CRUD como tools MCP. Isto e errado. O ponto do MCP nao e acesso a API, e operacoes ao nivel de dominio. Uma lista longa de tools triviais confunde o agente e produz chamadas de baixa qualidade. Uma lista curta de operacoes significativas e o que torna o agente util.
A heuristica que usamos:
- Liste as accoes que um cliente toma no seu plugin numa semana tipica. Ordene por frequencia.
- Agrupe-as em clusters de accoes relacionadas. Para a Metorik, um cluster pode ser “consultas de atribuicao de publicidade”, outro “segmentacao de coortes”.
- Para cada cluster, defina uma unica tool MCP que recebe os parametros do cluster e devolve o resultado do cluster. A tool e a operacao de dominio, nao o endpoint da API.
- Limite a lista a sete. Se tem mais de sete, nao terminou o clustering.
- Cada tool recebe uma descricao de um paragrafo no servidor MCP. A descricao e o que o agente le para decidir quando usa-la. Optimize para a leitura do agente, nao para a completude da documentacao humana.
Um autor de plugin que siga isto obtem uma superficie MCP com cinco a sete tools, cada uma significativa, cada uma relevante para o cliente retido. O agente le as descricoes e escolhe correctamente. O workflow diario do cliente inclui agora as operacoes de dominio do plugin como pedidos em linguagem natural.
O contrato vive no repositorio
Esta e a parte do argumento que a maioria dos autores de plugins ignora quando pega primeiro em “vamos adicionar o Claude a nossa administracao”.
Uma chatbox colada a administracao 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 tres vezes nos ultimos 18 meses na Anthropic, OpenAI e Google), a chatbox parte-se ate o mantedor actualizar o wrapper. O contrato da chatbox nao e duradouro. O seu ciclo de vida e a API do fornecedor de modelo.
O contrato de um servidor MCP vive no repositorio do plugin como uma JSON schema por tool. O contrato e estavel atraves das versoes de modelos. Quando a Anthropic actualiza o tool-calling do Claude, o agente actualiza, nao 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 é a forma de engenharia duradoura. A chatbox é 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 sao validos. O padrao do servidor MCP e o que se alinha com a forma como as equipas de clientes B2B ja trabalham.
O que isto significa para o leitor da wppoland
Se envia um plugin WordPress ou WooCommerce: construa o servidor MCP. Tres a sete operacoes de dominio, expostas como tools, contrato no repositorio, versionado separadamente da versao de UI do plugin. Faca isto antes de adicionar uma chatbox. Se so pode fazer uma coisa, faca o servidor MCP.
Se opera um site WordPress a escala (multi-site, agencia, enterprise): quando avalia plugins para adopcao, 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 esforco de engenharia em 2026: e aqui que sugerimos investir. Construimos Claude skills e servidores MCP personalizados para equipas B2B que correm workflows agent-first no WordPress. O entregavel e o servidor MCP, as tools de dominio, o contrato e o onboarding da equipa. O entregavel nao e uma chatbox.
Argumento final
O ponto de dados da Metorik de maio de 2026 e o lancamento open-source do Block MCP sao o mesmo sinal em escalas diferentes. O plugin que expoe as suas operacoes de dominio como tools MCP compoe-se com qualquer agente que o cliente adopte. O plugin que nao o faz e canibalizado na camada de commodity e fica invisivel na camada de dominio.
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 superficie MCP este ano sao os que estarao na allow-list do integrador de agentes quando o mercado o alcancar.
Fontes
- Bryce Adams no WP Product Talk (transcricao via WP Product Talk)
- Documentacao da integracao MCP da Metorik
- Lancamento 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 implementacao 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)
Ultima verificacao: 2026-05-23



