O MCP no WordPress já ultrapassou a fase de teste informal. Com a Abilities API incorporada ao núcleo desde o WordPress 6.9 e o MCP Adapter disponibilizado como pacote oficial, qualquer instalação WordPress pode oferecer funções próprias para serem utilizadas por agentes de IA. A principal mudança em relação às soluções anteriores é a existência de um padrão comum, acompanhado de um sistema de permissões baseado nas capabilities do WordPress — e não apenas em instruções inseridas no prompt.
Neste artigo, você verá o que mudou, como os componentes se relacionam e quais requisitos devem ser atendidos antes de habilitar essa tecnologia em um ambiente de produção.
MCP: o que é e por que passou a fazer parte do WordPress
O Model Context Protocol, conhecido pela sigla MCP, é um protocolo aberto criado para uniformizar a maneira como sistemas de inteligência artificial identificam e acionam funções oferecidas por aplicações externas. Em vez de cada ferramenta desenvolver uma integração própria, o agente utiliza MCP, enquanto o sistema conectado disponibiliza tools, que são funções executáveis, e resources, que representam fontes de informação.
No WordPress, essa abordagem resolve uma dificuldade recorrente. A conexão entre uma IA e um site por meio da REST API sempre foi possível, mas cada projeto precisava recriar componentes como autenticação, descoberta de recursos, validação de dados e tratamento de falhas. Isso gerava integrações frágeis, trabalhosas para auditar e pouco reutilizáveis entre diferentes clientes.
Abilities API: a fundação incorporada ao core
A Abilities API foi adicionada ao núcleo do WordPress 6.9, lançado em 2 de dezembro de 2025. Ela oferece uma camada para o registro de “habilidades” do site: funções tipadas, identificáveis e executáveis que podem ser chamadas por REST, WP-CLI, Command Palette, WPGraphQL ou diretamente por uma solicitação feita por um LLM.
Cada ability precisa definir quatro elementos essenciais:
'name' => 'minha-agencia/listar-pedidos-pendentes',
'input_schema' => [ /* definição tipada da entrada */ ],
'output_schema' => [ /* definição tipada da saída */ ],
'permission_callback' => function () { /* verifica a capability adequada */ },
'execute_callback' => function () { /* executa a operação */ },
O próprio core inclui três abilities prontas: core/get-site-info, core/get-user-info e core/get-environment-info. Elas funcionam principalmente como exemplos do modelo, e não como recursos completos destinados a atender uma necessidade específica.
Um aspecto frequentemente subestimado é a importância dos schemas de entrada e saída. Eles não existem apenas para cumprir uma formalidade: são o mecanismo que permite ao agente compreender quais funções estão disponíveis e quais argumentos podem ser utilizados, sem depender de uma descrição manual da API dentro do prompt.
MCP Adapter: conectando as abilities ao agente
A Abilities API, por si só, não implementa o protocolo MCP. Essa conversão é feita pelo MCP Adapter, um pacote oficial do projeto WordPress distribuído por meio dos lançamentos no GitHub, dentro da iniciativa AI Building Blocks.
O adapter transforma as abilities registradas em elementos compatíveis com MCP e disponibiliza três ferramentas para descoberta:
mcp-adapter-discover-abilities— apresenta as habilidades disponíveis;mcp-adapter-get-ability-info— fornece informações sobre uma habilidade determinada;mcp-adapter-execute-ability— dispara a execução da habilidade.
A separação entre descoberta, consulta e execução é intencional. Dessa maneira, o agente primeiro identifica o que existe, depois verifica os detalhes e somente então chama a função, em vez de receber uma lista extensa de operações logo no início da conexão.
Por padrão, nenhuma ability é publicada. Para torná-la visível ao agente, é necessário marcar essa exposição de forma explícita:
'meta' => array( 'mcp' => array( 'public' => true ) ),
Dois meios de transporte para situações diferentes
O transporte por STDIO inicia o servidor MCP como um processo secundário do WP-CLI, sem disponibilizá-lo pela rede:
wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin
Esse formato é indicado para desenvolvimento local e para cenários em que você controla diretamente a máquina responsável por executar o WordPress.
Já o transporte por HTTP publica o servidor no endereço /wp-json/mcp/mcp-adapter-default-server. A autenticação é feita com senhas de aplicativo por meio de Basic Auth. Como essas credenciais são transmitidas em base64, o uso de HTTPS é obrigatório — trata-se de uma exigência de segurança, não de uma recomendação opcional.
Após a criação da sessão, todas as requisições seguintes precisam incluir o cabeçalho Mcp-Session-Id. A sessão é encerrada depois de 24 horas sem atividade.
O risco de segurança que não pode ser ignorado
Existe um detalhe fundamental para determinar se a integração será segura: o callback de permissão padrão do transporte verifica apenas se o usuário está autenticado, usando is_user_logged_in().
Isso significa que, se você não definir um callback específico no transporte, qualquer pessoa com uma sessão ativa — inclusive um usuário com a função de Assinante — poderá acessar o servidor MCP. Em um site institucional que não permite novos cadastros, o impacto tende a ser limitado. Porém, em uma instalação com registro público, área restrita para membros ou operação de WooCommerce, a exposição pode ser muito mais ampla do que a expressão “bloqueado por padrão” dá a entender.
O modelo de permissões aplicado individualmente às abilities, por outro lado, é consistente. O permission_callback de cada habilidade é executado a cada chamada, vinculando o agente às capabilities efetivamente existentes no WordPress. Um agente não consegue obter uma autorização apenas por solicitá-la; sem a capability correspondente, a operação não é permitida.
Antes de ativar MCP em um site de cliente, verifique pelo menos os seguintes pontos:
- Crie um usuário exclusivo e com privilégios mínimos. Não utilize sua conta de administrador.
- Defina um callback de permissão explícito no transporte. Não dependa simplesmente da condição de usuário autenticado.
- Não use
__return_trueem abilities capazes de criar, excluir ou modificar configurações. - Exija HTTPS em todas as conexões, especialmente por causa das senhas de aplicativo.
- Mantenha o HTTP restrito a consultas. Ações de escrita devem permanecer no STDIO ou protegidas por um servidor acessível somente a administradores.
- Implemente registros de observabilidade, permitindo identificar comportamentos inesperados do agente.
- Troque as senhas de aplicativo quando houver mudanças na equipe. Não há revogação individual por cliente.
O que o ecossistema ainda não oferece
O MCP Adapter ainda está antes da versão 1.0. Na prática, isso envolve atualizações manuais, necessidade de configurar a exposição individualmente em cada site e possibilidade concreta de alterações de comportamento entre versões.
Entretanto, a maior deficiência não está necessariamente no código, mas na infraestrutura ao redor. O adapter executa comandos, mas não administra ambientes de staging, cria snapshots nem oferece rollback. Quando um agente comete um erro — e isso inevitavelmente pode acontecer — o adapter não responde sozinho o que deve ocorrer em seguida.
Sem staging, backups automáticos e um procedimento de reversão previamente testado, permitir operações de escrita via MCP em produção significa repassar esse risco ao cliente. Por isso, adotar MCP no WordPress é menos uma decisão sobre instalar um plugin e mais uma escolha relacionada à arquitetura e à operação da infraestrutura.
Como começar agora
Para quem administra alguns sites, a estratégia mais prudente em 2026 é iniciar com recursos somente de leitura. Você pode disponibilizar abilities para consultar informações como situação de pedidos, indicadores de conteúdo e integridade do site. Depois, conecte essas funções a um cliente MCP e familiarize-se com o modelo de permissões antes de autorizar qualquer alteração.
Em operações com dezenas de sites, o cenário é diferente. Nesse caso, o principal benefício está na criação de um conjunto padronizado de abilities reutilizável entre os projetos, combinado com transporte controlado, registros centralizados e um ambiente de staging realmente funcional.
Na Amicatek, o WordPress é nossa principal especialidade, e consideramos a Abilities API a transformação mais significativa do core em muitos anos para quem pretende trabalhar seriamente com inteligência artificial. Se você quer descobrir quais recursos podem ser disponibilizados no seu site — e fazer isso sem criar uma brecha de segurança —, converse com nossa equipe. Avaliamos seu ambiente e planejamos a implementação em conjunto com o seu time.