WooCommerce 11.3 MCP, guia prático da migração

WooCommerce 11.3 MCP é a mudança em que, no anúncio oficial de 21 de outubro de 2026, as abilities de produto e pedido passam a depender do plugin WordPress MCP Adapter, e o endpoint legado /wp-json/woocommerce/mcp deixa de atender clientes MCP. A autenticação antiga por chave REST da loja deixa de servir a esse caminho. Quem já conectava um assistente de IA à loja precisa migrar antes de atualizar ou logo após o aviso no admin.

Para uma loja pequena ou uma agência que mantém vários sites, o ponto central não é ganhar produtividade com IA, e sim preservar um acesso técnico controlado a catálogo e pedidos. WooCommerce 11.3 MCP separa o núcleo da loja do transporte MCP, e a documentação oficial trata a integração ainda como prévia para desenvolvedores. Isso significa que detalhes de API e padrões de cliente podem mudar em versões futuras, mesmo depois da migração descrita abaixo.

Se a sua operação nunca usou MCP, a atualização do WooCommerce em si não cria sozinha uma conexão de IA. O tema só passa a ser urgente quando existe cliente apontando para o endpoint antigo, extensão que dependia dele, ou plano de ligar um assistente a produtos e pedidos com Application Password WooCommerce e o Adapter.

O que o WooCommerce 11.3 MCP confirma na documentação?#

A documentação oficial confirma que, a partir do WooCommerce 11.3, as abilities canônicas de produto e pedido ficam habilitadas por padrão no núcleo, e a conexão MCP exige o plugin WordPress MCP Adapter ativo. O endpoint /wp-json/woocommerce/mcp e a autenticação por chave REST com cabeçalho X-MCP-API-Key são removidos. Pedidos a esse endereço passam a responder com HTTP 410 e mensagem JSON-RPC orientando o Adapter. A feature mcp_integration em WooCommerce > Configurações > Avançado > Recursos deixa de existir de fato, e a checagem dessa feature no código do WooCommerce passa a retornar sempre falsa, conforme o aviso do blog de desenvolvedores em 21 de outubro de 2026 e a página de MCP do WooCommerce.

Também saem as abilities derivadas da REST que só existiam para o endpoint legado, entre elas woocommerce/products-list, woocommerce/products-get, woocommerce/products-create, woocommerce/products-update, woocommerce/products-delete, woocommerce/orders-list, woocommerce/orders-get, woocommerce/orders-create e woocommerce/orders-update. Filtros só do caminho antigo, como woocommerce_mcp_include_ability, woocommerce_mcp_allow_insecure_transport e woocommerce_check_rest_ability_permissions_for_method, deixam de rodar. Pacotes embutidos wordpress/mcp-adapter e wordpress/abilities-api deixam de vir no WooCommerce porque a Abilities API entra no WordPress núcleo na linha mínima do WooCommerce 11.3, e o Adapter oficial passa a ser o plugin canônico. O anúncio cita o MCP Adapter 0.7.0 como primeiro lançamento publicado no WordPress.org e marca como obsoleto o empacotamento do adapter só como biblioteca Composer.

O que a documentação não promete é resultado comercial, redução de tempo de operação ou qualidade automática do texto da IA. Ela descreve contrato técnico, remoções e caminho de migração. Se a sua equipe lia o endpoint legado como API estável de longo prazo, esse enquadramento já vinha depreciado desde o WooCommerce 10.9, em maio e junho de 2026, quando as abilities canônicas foram apresentadas.

Na prática, o que eu vejo com mais frequência em lojas pequenas é achar que desligar o recurso MCP no WooCommerce ainda controla a exposição. Depois do 11.3, o controle real fica no plugin Adapter, no usuário WordPress usado na Application Password e nas abilities que cada extensão marca como públicas para MCP.

Quem é afetado e quem pode ignorar a migração?#

Você é afetado se um cliente MCP ainda aponta para /wp-json/woocommerce/mcp com chave REST do WooCommerce, se uma extensão esperava abilities nesse endpoint via namespace woocommerce/, metadado expose_in_deprecated_woocommerce_mcp ou o filtro woocommerce_mcp_include_ability, ou se o código customizado usa classes e fábricas removidas ligadas ao transporte antigo. Lojas que tinham a feature MCP do WooCommerce ligada recebem aviso no admin após atualizar, com link para a documentação e atalho para instalar ou ativar o Adapter.

Você pode ignorar a migração MCP se nunca conectou assistente de IA por esse protocolo e não depende de extensão que falava com o endpoint legado. Nesse caso, WooCommerce 11.3 MCP ainda importa como notícia de plataforma, porque abilities de produto e pedido existem no núcleo, mas sem Adapter ativo elas não ficam disponíveis para clientes MCP. O aviso no admin some para todos os administradores depois que alguém o dispensa ou ativa o plugin pelo próprio aviso.

Agências precisam inventariar ambientes de staging e produção por site, porque um único cliente desktop com URL antiga quebra só na loja atualizada. Também vale listar usuários e chaves REST criadas só para MCP antigo, pois o blog oficial autoriza revogar essas chaves depois da troca. Quem opera multilojas sem inventário costuma descobrir a quebra no primeiro pedido em que a IA tenta listar estoque e recebe 410.

O erro que mais custa caro aqui é atualizar produção no mesmo dia em que um fluxo de atendimento já depende do assistente, sem ter testado o novo endpoint com um usuário de permissão mínima. O custo não é só técnico. É interrupção de operação e risco de alguém resolver com administrador e senha principal, o que amplia o dano se a credencial vazar.

O que o MCP oficial faz e o que ele não faz?#

O WordPress MCP Adapter expõe abilities do WordPress e de plugins, inclusive as do WooCommerce, a clientes compatíveis com o Model Context Protocol. Sozinho, o plugin não adiciona tela mágica no wp-admin nem instala uma IA na loja. Ele cria o endereço do servidor padrão em /wp-json/mcp/mcp-adapter-default-server, autentica o cliente como um usuário WordPress e deixa o assistente descobrir e executar abilities públicas, sempre sujeito às permissões desse usuário e ao callback de cada ability. A página do plugin MCP Adapter no WordPress.org e o guia da iniciativa de Abilities e agentes no WordPress News descrevem esse papel de ponte.

No servidor padrão, o cliente não recebe uma ferramenta MCP separada para cada ability WooCommerce. Ele vê três metaferramentas, mcp-adapter-discover-abilities, mcp-adapter-get-ability-info e mcp-adapter-execute-ability, e precisa descobrir, inspecionar o esquema e só então executar. Em site WooCommerce 11.3 com Adapter, a descoberta deve listar abilities como woocommerce/products-query e woocommerce/order-notes-query, além de operações de pedido documentadas. Cada execução revalida permissão. A documentação do WooCommerce marca a implementação MCP como prévia para desenvolvedores, então padrões de integração podem mudar.

O que o MCP oficial não faz, segundo o material de orientação a donos de site do Adapter, é decidir sozinho o catálogo de ações disponíveis. Quem registra abilities é o WordPress ou o plugin. Ability sem exposição pública efetiva para MCP não aparece. O assistente também não ultrapassa o papel do usuário autenticado. Se a conexão usa um Editor, ela não faz o que só um Administrador faria. E o Adapter não substitui conferência humana de preço, estoque, status de pedido ou mensagem enviada a cliente.

Muita gente acha que ligar MCP abre a loja inteira para a IA, e quase sempre está enganada no mecanismo, porque a superfície real é abilities públicas mais o papel do usuário. O risco prático, porém, continua alto quando esse usuário é administrador e a Application Password fica salva em notebook compartilhado.

Como migrar MCP loja WooCommerce sem perder a conexão de IA?#

Para migrar MCP loja WooCommerce sem depender do endpoint WooCommerce MCP removido, a ordem oficial é instalar e ativar o Adapter, criar Application Password em usuário dedicado e apontar o cliente ao novo servidor. Faça isso em staging antes de produção sempre que a loja já use o assistente em rotina. WooCommerce 11.3 MCP quebra o caminho antigo de propósito, então só atualizar o plugin da loja sem mexer no cliente gera 410.

Siga estes passos, com validação em cada um.

1. Em staging, atualize ou simule WooCommerce 11.3 e confirme se o admin exibe o aviso sobre MCP.
2. Instale e ative o plugin com wp plugin install mcp-adapter --activate, ou pelo instalador do WordPress.org, e verifique se o plugin permanece ativo após cache e rede de plugins.
3. Crie um usuário WordPress só para o assistente, com o menor conjunto de capacidades que ainda permita as abilities desejadas, e nunca reutilize a conta pessoal do dono da loja.
4. Em Usuários > Perfil desse usuário, gere uma Application Password com nome identificável do cliente MCP, copie na hora e guarde em cofre, porque o WordPress mostra o valor uma vez.
5. No cliente MCP, troque a URL para https://sua-loja/wp-json/mcp/mcp-adapter-default-server, use o usuário WordPress e a Application Password nos campos WP_API_USERNAME e WP_API_PASSWORD, e remova chave REST e cabeçalho X-MCP-API-Key do fluxo MCP.
6. Teste descoberta de abilities e uma operação somente leitura, por exemplo consulta de produtos, antes de qualquer escrita de status de pedido.
7. Só então repita em produção, revogue Application Passwords de teste e, se existirem, as chaves REST criadas só para o endpoint legado.

A documentação de Application Passwords do WordPress reforça HTTPS, revogação individual e o fato de que essa senha não serve para login interativo no wp-admin. Se a seção Application Passwords não aparece, confira certificado HTTPS e plugins de segurança que desligam o recurso. Conexões remotas HTTP sem criptografia ficam fora do desenho seguro descrito pelas fontes oficiais.

Quando acompanho agências com várias lojas, o padrão que funciona melhor é um cofre por cliente, uma Application Password por ferramenta e um checklist de staging com captura da resposta 410 no endpoint antigo. Assim ninguém interpreta o sumiço do MCP como falha misteriosa de hospedagem.

Quais abilities WooCommerce produto pedido entram no caminho novo?#

As abilities WooCommerce produto pedido do caminho canônico, apresentadas em 12 de maio de 2026 para o ciclo do WooCommerce 10.9 e mantidas como base no 11.3, cobrem consulta, criação, atualização e exclusão de produtos, além de consulta de pedidos, atualização de status e inclusão de notas. A documentação do 11.3 também cita woocommerce/order-notes-query para consulta de notas de pedido. Os nomes canônicos incluem woocommerce/products-query, woocommerce/product-create, woocommerce/product-update, woocommerce/product-delete, woocommerce/orders-query, woocommerce/order-update-status e woocommerce/order-add-note, conforme o aviso de abilities canônicas de 12 de maio de 2026.

Isso não é lista aberta de tudo que a REST faz. O desenho canônico prioriza operações de domínio com esquema de entrada e saída, enums conscientes do WooCommerce e callbacks de permissão. Operações só de leitura aparecem marcadas como readonly e idempotentes no anúncio de 2026-05-12, enquanto escritas declaram se são destrutivas e como tratar repetição. Se a sua automação antiga criava pedidos pelo ability REST-espelhado woocommerce/orders-create do endpoint depreciado, esse identificador específico entra na lista do que o 11.3 remove, e a equipe precisa verificar se existe ability canônica equivalente para o fluxo ou se a automação deve voltar à REST tradicional.

Extensões que expunham abilities só no endpoint legado não migram sozinhas. O servidor padrão do Adapter ignora expose_in_deprecated_woocommerce_mcp e o filtro antigo. Para continuar visível ao MCP, a ability precisa de exposição pública efetiva via meta.mcp.public verdadeiro ou, na ausência desse campo, meta.public verdadeiro, segundo a documentação do WooCommerce e do Adapter. Sem esse ajuste, o lojista instala o Adapter, a conexão autentica, e a lista de abilities do negócio customizado vem incompleta.

Em projetos de extensão, eu priorizo primeiro mapear quais ações o assistente realmente usa no dia a dia, porque portar todas as abilities antigas sem dono funcional só amplia superfície de ataque. O mínimo suficiente costuma ser mais seguro e mais fácil de auditar depois de um incidente.

Quais riscos de segurança e LGPD surgem ao dar acesso de IA à loja?#

Dar acesso de IA à loja significa permitir que um cliente externo execute ações no mesmo universo de permissões de um usuário WordPress, e pedidos trazem dados pessoais de clientes. Pela Lei nº 13.709/2018 (LGPD), dado pessoal é informação ligada a pessoa identificada ou identificável, e tratamento inclui acesso, uso, transmissão e processamento. A loja, ao decidir finalidade e meios, atua como controladora desses tratamentos. Colar nome, endereço, telefone ou histórico de compra em ferramenta de IA sem base legal, contrato e avaliação de risco cria exposição desnecessária.

Riscos técnicos concretos incluem Application Password com papel de administrador, notebook sem disco cifrado, cliente MCP em máquina compartilhada, ausência de HTTPS, e aceitar escrita automática de status de pedido sem revisão. Há também o risco de alucinação, no sentido de resultado incorreto gerado pelo modelo, que a documentação de IA da casa editorial trata como limite a conferir. O Adapter e o WooCommerce aplicam permissões, porém não garantem que o texto sugerido pela IA esteja certo sobre preço, prazo ou política de troca.

Limites honestos da recomendação de usar IA na operação incluem custo de revisão humana, possível transferência internacional de dados conforme a ferramenta escolhida, e a prévia para desenvolvedores do MCP no WooCommerce. Nenhuma dessas peças autoriza prometer ganho de receita. Se a loja não tem processo para conferir saída da IA, o caminho mais seguro é não habilitar abilities de escrita.

Eu trato pedido e cliente como zona sensível por padrão. Se a equipe só precisa de apoio em catálogo interno sem dado de comprador, começo por abilities de produto em usuário sem acesso amplo a pedidos. Ampliar depois é mais barato do que explicar vazamento depois.

Como limitar permissões e conferir o resultado da IA?#

Limite permissões criando usuário dedicado, concedendo só o necessário às abilities usadas, gerando Application Password exclusiva por cliente MCP e revogando credenciais antigas após a migração. A documentação do WooCommerce diz para não usar senha da conta nem chave REST no fluxo MCP novo, e recomenda usuário com apenas as capabilities necessárias. O servidor padrão exige usuário autenticado com capability read, e cada ability WooCommerce aplica o próprio callback. Isso é piso, não teto de endurecimento.

Na operação diária, separe leitura e escrita. Use primeiro consultas de produto e pedido em staging. Só libere atualização de status ou criação de produto quando houver roteiro de conferência. Guarde log do que o assistente pediu e do que a loja alterou. Revogue a Application Password se o notebook for perdido, se um freelancer sair, ou se um teste expirar. Nomeie a senha com o nome do cliente e do ambiente, para achar rápido no perfil do usuário.

Conferir resultado significa validar campos críticos antes de comunicar o cliente final. Preço, estoque, frete, status de pagamento e dados pessoais merecem olho humano. Se a IA redigir resposta a comprador, revise tom, prazo e base legal de retenção. Se a IA alterar status, confirme no painel WooCommerce e no e-mail transacional o que de fato saiu. Ferramenta alguma elimina essa etapa quando há risco financeiro ou reputacional.

O hábito que mais reduz incidente em equipe pequena é proibir escrita automática em produção na primeira semana após migrar MCP. A conexão pode existir, a descoberta pode funcionar, e a escrita continua manual até a equipe ver o padrão de erro do modelo no próprio catálogo.

Qual alternativa sem IA continua válida para a loja?#

A alternativa sem IA continua sendo operar a loja pelo wp-admin e, quando houver integração sistema a sistema, usar a REST API do WooCommerce com chaves em WooCommerce > Configurações > Avançado > REST API, conforme a documentação oficial da REST API. Esse caminho não depende do WordPress MCP Adapter nem do protocolo MCP. Ele serve ERP, planilha assistida por script, aplicativo interno ou middleware que já falava REST sem assistente generativo.

Escolha REST sem IA quando a tarefa é determinística, quando a equipe não quer enviar dados de pedido a modelo generativo, ou quando o custo de revisão da IA supera o benefício. Chaves REST ainda exigem cuidado, porque também herdam o poder do usuário associado e existem níveis leitura, escrita e leitura/escrita. A diferença prática é o modo de uso. Script estável com contrato fixo costuma ser mais previsível do que agente que descobre abilities e monta parâmetros em linguagem natural.

Também é válido simplesmente não integrar. Loja pequena com poucos pedidos diários pode manter catálogo e atendimento no painel, sem Adapter e sem REST externa. WooCommerce 11.3 MCP não obriga loja alguma a adotar assistente. Obriga quem já usava o endpoint legado a migrar ou abandonar esse acesso.

Para a maioria das lojas que eu vejo sem processo de revisão, a alternativa sem IA é a escolha mais sóbria até existir dono claro para credenciais, staging e checklist de conferência. Adotar MCP depois, com escopo mínimo, dói menos do que ligar tudo cedo e apagar incêndio em pedido real.

O que ainda não se sabe ou pode mudar depois de 2026-10-21?#

Ainda não se sabe, só pelo anúncio de 21 de outubro de 2026, o calendário completo de novas abilities de núcleo e extensões WooCommerce que a equipe diz estar preparando. Também permanece o aviso de prévia para desenvolvedores na documentação MCP, o que autoriza mudanças de detalhe de implementação e de padrões de integração em releases futuras. Quem precisa de contrato engessado para auditoria interna deve registrar versão do WooCommerce, versão do Adapter e data do teste de descoberta.

Outro ponto em aberto para cada loja, e não para o vendor, é o enquadramento jurídico do fornecedor de IA usado no cliente MCP, inclusive transferência internacional e subprocessamento. A documentação WooCommerce e WordPress explica autenticação e abilities. Ela não substitui análise de contrato, base legal LGPD nem política interna de retenção. Se a agência atende cliente regulado ou com alto volume de dado sensível no sentido da lei, a resposta correta pode ser bloquear abilities de pedido no MCP e manter só fluxos REST auditados.

Por fim, customizações antigas que dependiam de filtros removidos podem falhar de formas específicas por site. Só inventário e teste revelam se uma ability privada de plugin deixa de aparecer após a troca de metadados. Esse diagnóstico não vem pronto no aviso do admin.

Eu registro versão, data e evidência de teste em cada go-live de MCP, porque a frase de que estava funcionando ontem quase nunca reconstrói o estado quando o cliente MCP, o proxy Node e o papel do usuário mudam ao mesmo tempo.

Perguntas frequentes sobre WooCommerce 11.3 MCP#

Antes de atualizar uma loja que já fala com assistente, as dúvidas mais comuns em agência misturam prazo, plugin, senha e medo de perder pedido. As respostas abaixo fecham o ciclo prático do WooCommerce 11.3 MCP com base só no que as fontes oficiais confirmam até 21 de outubro de 2026, e deixam explícito onde a decisão vira política interna da loja e não regra do software.

Preciso instalar o WordPress MCP Adapter em toda loja WooCommerce 11.3?#

Não. Você precisa do WordPress MCP Adapter quando deseja conexão MCP de clientes de IA com as abilities do site, inclusive produto e pedido do WooCommerce. Lojas sem cliente MCP e sem extensão dependente do endpoint legado podem atualizar o WooCommerce sem instalar o Adapter só por causa desta notícia. Se no futuro a equipe quiser experimentação com assistente, aí o plugin passa a ser requisito de transporte, não um complemento cosmético.

Application Password WooCommerce é a mesma coisa que chave REST?#

Não. No fluxo MCP novo a autenticação remota usa usuário WordPress e Application Password, e a documentação do WooCommerce pede explicitamente para não usar senha da conta nem chave REST da loja nesse caminho. A chave REST continua relevante para a REST API tradicional, gerida em Configurações avançadas, e pode ser revogada se existia só para o endpoint MCP antigo. Misturar os dois tipos de credencial no mesmo campo do cliente é causa frequente de falha de autenticação após a migração.

O endpoint WooCommerce MCP volta a funcionar com algum filtro?#

Pelo que o anúncio e a documentação do 11.3 descrevem, o endpoint /wp-json/woocommerce/mcp foi removido e responde 410, enquanto filtros exclusivos desse caminho deixam de executar. Não há, nessas fontes, um interruptor oficial para ligar de novo o transporte legado. O caminho suportado é o servidor padrão do Adapter. Se um fornecedor terceiro promete reativar o endpoint antigo por hack, trate como risco de compatibilidade e segurança, não como procedimento documentado pelo WooCommerce.

Posso deixar a IA alterar status de pedido sozinha no primeiro dia?#

Você pode tecnicamente, se o usuário tiver permissão e a ability de atualização de status estiver disponível, mas isso amplia impacto de erro e de alucinação sobre pagamento e logística. O desenho mais prudente para loja pequena é começar por leitura, conferir descoberta e esquemas, e só então autorizar escrita com revisão humana. Nenhuma fonte oficial do WooCommerce afirma que a IA deve operar pedidos sem supervisão, e a própria natureza de prévia do MCP reforça cautela operacional.

E se eu não quiser IA, mas precisar integrar ERP?#

Use a REST API do WooCommerce com chave de escopo mínimo e HTTPS, ou outro middleware já validado pela equipe, sem instalar o Adapter só por moda. ERP com contrato fixo de campos costuma se beneficiar mais de endpoint REST estável do que de agente com descoberta dinâmica. O WooCommerce 11.3 MCP resolve o transporte de abilities para MCP. Ele não é pré-requisito universal de integração empresarial.

Conclusao#

Para a maioria das lojas pequenas e agências, o caminho sóbrio após 21 de outubro de 2026 é tratar WooCommerce 11.3 MCP como mudança de conexão, não como atalho de crescimento. Se existe cliente no endpoint legado, migre com Adapter, Application Password e usuário mínimo em staging, depois em produção. Se não existe uso de MCP, não fabrique urgência, e mantenha REST ou painel quando a operação já funciona sem modelo generativo.

A resposta muda quando há extensão customizada no endpoint antigo, porque aí entra trabalho de metadados e teste de abilities públicas. Também muda quando pedidos e dados pessoais entram no alcance do assistente, porque LGPD e revisão humana passam a condicionar o desenho. O primeiro passo útil é inventariar URLs de cliente MCP, chaves REST de propósito antigo e a lista exata de ações que a equipe quer permitir.

Sem inventário, a atualização vira surpresa. Com inventário e escopo mínimo, a loja preserva controle e evita trocar um endpoint depreciado por um acesso amplo demais.

Este texto tem caráter informativo e educativo sobre a mudança técnica do WooCommerce 11.3 no uso de MCP, Adapter e credenciais. Não substitui avaliação profissional de segurança, privacidade, adequação à LGPD nem consultoria de implementação no ambiente específico da sua loja ou dos seus clientes.