O MCP Adapter, plugin canônico do WordPress para conectar agentes de IA a um site, passou de 50 mil instalações ativas na versão 0.7.1. O número de tarefas de escrita que ele consegue executar hoje é zero.
A conta não é nossa. Está no issue #402 do repositório oficial do adapter, aberto por Andy Peatling em 20 de outubro de 2026: “hoje o adapter não consegue fazer nenhum dos 20 pedidos de dono de site do benchmark Building”. Zero de vinte. Não é uma avaliação de qualidade do protocolo, é o estado da lista de abilities registradas.
Para quem opera site que não pode parar, o dado interessante não é esse. É o que acontece quando o adapter sai do caminho.
O que o benchmark mediu de fato
O projeto WordPress Agent Benchmarks rodou 21 pedidos típicos de dono de site, com dois agentes, cada pedido duas vezes: uma com o MCP Adapter instalado como única porta de entrada, outra sem ele.
Na rodada com o adapter, o agente só alcança o que alguém escreveu como ability. O core registra três, e as três apenas leem: informação do site, do usuário e do servidor. Poucos plugins registraram abilities até agora. O próprio benchmark atribui a lacuna às abilities que ninguém escreveu ainda, não aos agentes nem ao MCP.
Na rodada sem o adapter, o agente recebeu a credencial do dono do site na REST API nativa. Com isso cobriu quase tudo o que um administrador faz pelo painel. E fez mais: usou as rotas REST do WooCommerce, do Redirection e de outros três plugins sem ninguém explicar que elas existiam, só lendo o que a API expõe.
Esse é o resultado que merece atenção em reunião de arquitetura. A comparação real não é “MCP contra nada”. É “três abilities de leitura contra uma credencial de administrador falando HTTP”.
O atalho que funciona é o que você não quer em produção
Application password no WordPress não tem escopo. Ela herda tudo o que o usuário dono dela pode fazer. Não existe modo somente leitura nativo, não existe limite por rota, não existe restrição por capability, não existe expiração.
Então o caminho que “funciona” hoje para colocar um agente operando um site é entregar acesso equivalente a administrador por HTTP, sem nenhum desses controles. Numa operação crítica isso não é integração, é chave mestra emitida sem prazo de validade.
O core sabe do problema. George Stephanis, que escreveu o recurso original no WordPress 5.6, mantém o feature plugin application-passwords-scoped, um protótipo de permissões por senha construído apenas sobre hooks que o core já entrega. Ele prototipa sete controles:
- limite por lista de roles
- bloqueio de grupos de capability, como plugins ou usuários
- modo somente leitura, restringindo REST a GET, HEAD e OPTIONS
- allowlist de abilities nomeadas, com modo exclusivo de abilities
- expiração da senha, com exemplo de 7 dias
- bloqueio de XML-RPC sem derrubar a REST
- teto do emissor, para que uma senha criada por um admin para outra pessoa não exceda o acesso do próprio admin
Oito commits, nove issues abertas, exige WordPress 6.9 e PHP 7.4. Não é core, e a escolha de nomenclatura e de enforcement fora do plugin ainda está aberta. Ou seja: enquanto isso não chega ao core, escopo de credencial de agente é problema de quem opera, resolvido em casa.
O que o adapter ganha, e com que previsibilidade
O issue #402 define quatro marcos, com o percentual de pedidos do benchmark que cada um destrava: páginas, imagens e configurações levam a 30%; pessoas e migração de blog a 45%; plugins, menus e redirecionamentos a 90%; formulário de contato e atualizações fecham em 100%. A lista de abilities faltantes é explícita: content-create, content-update, content-delete, media-upload, media-update, settings-update, user-create, term-create, comment-create, mais uma ponte REST para listar e chamar rotas de plugin.
O detalhe operacional: na data de abertura, nenhum item do issue tinha responsável nem PR vinculado. As colunas “Who” e “PR” estão vazias. Não há data prometida.
Do outro lado, o plugin AI publicou a versão 1.4.0 em 6 de outubro de 2026, com 89 commits em 275 arquivos, e lista as abilities de escrita (core/content-create, core/media-upload, core/settings-update, core/term-create, core/user-create e companhia) como planejadas para a 1.5.0, descritas como exploratórias.
E a 1.4.0 já mexeu nos nomes das abilities de leitura: core/read-content virou core/content-query, core/read-users virou core/users-query, core/read-settings virou core/settings-get. Os nomes antigos seguem funcionando como aliases depreciados, e ai/get-post-details foi depreciada em favor do modo de post único de core/content-query. O mínimo do plugin subiu para WordPress 7.0.3.
Leia isso como aviso de contrato instável: a interface que você usaria para automatizar operação crítica renomeou três abilities em uma versão menor. Integração acoplada a nome de ability vai precisar de manutenção em cada release.
Como dar acesso a um agente sem abrir o site
Há duas propriedades do adapter que ajudam, e vale usá-las de forma deliberada: segundo o FAQ do plugin, uma ability só chega ao agente por MCP se estiver marcada como pública, e as verificações de permissão continuam rodando contra o usuário autenticado. Exposição é opt-in. Trate como allowlist, não como configuração padrão.
- Crie usuário dedicado ao agente, com a role mínima que resolve a tarefa. Nunca a sua conta.
- Separe credencial de leitura e credencial de escrita. Credenciais diferentes, usuários diferentes.
- Registre ability própria para a operação específica que o agente precisa, em vez de liberar rota genérica e confiar no bom senso do modelo.
- Logue cada chamada com usuário, ability, parâmetros e resultado. Sem log, não existe pós-incidente.
- Rode em staging com exatamente o mesmo conjunto de abilities públicas da produção, senão o teste não vale.
- Rotacione as application passwords por processo, com data no calendário, já que o core não expira nada.
- Fixe a versão do plugin AI e do adapter, e trate renomeação de ability como mudança que quebra, com teste antes do update.
O que fica
O MCP Adapter não está entregando pouco porque o protocolo é fraco. Está entregando pouco porque o WordPress ainda não escreveu as abilities de escrita, e o roadmap que cobre essa dívida é um issue sem responsável.
A consequência prática é que, em 2026, quem quer um agente operando um site tem duas opções: esperar, ou entregar uma credencial de administrador sem escopo. A primeira não tem data. A segunda é uma decisão de segurança, não de produtividade, e precisa ser tomada com usuário dedicado, permissão mínima, log e rotação.
Se o seu site é daqueles que não podem parar, o caminho barato é fazer o inventário agora: quantas application passwords existem, de quem, com qual role, criadas quando, e qual delas um agente está usando. Essa lista costuma ser mais curta do que deveria e mais poderosa do que alguém imaginava.
Fontes: WordPress/mcp-adapter, issue #402, “MCP adapter: 0% to 100%” (20/10/2026); MCP Adapter 0.7.1 no WordPress.org; WordPress Agent Benchmarks, Building with WordPress e metodologia; What’s new in AI 1.4.0, Make WordPress AI (06/10/2026); application-passwords-scoped, George Stephanis. O benchmark chegou ao nosso radar pela reportagem do The Repository; os números acima foram conferidos nas fontes primárias.
1 comentário