Até agora, um agente de IA que quisesse comprar um produto no seu site precisava fazer o mesmo que um script de teste: ler o DOM, adivinhar qual botão importa e clicar. O WebMCP muda isso. Ele permite que o site publique uma lista de ferramentas (buscar produto, adicionar ao carrinho, finalizar compra) que o agente chama diretamente. E em outubro de 2026 o mundo de testes acompanhou: o Playwright 1.64 trouxe APIs experimentais para listar e chamar essas ferramentas dentro de um teste. Os testes de WebMCP entraram oficialmente no vocabulário de QA.
Neste guia você vai entender o que é o WebMCP, por que ele cria uma segunda porta de entrada para o seu produto que alguém precisa testar, e como o time de QA cobre as duas portas sem dobrar o trabalho.
O que é WebMCP, sem jargão
WebMCP é uma API web proposta no Web Machine Learning Community Group do W3C, com editores da Microsoft e do Google. A página registra ferramentas com document.modelContext.registerTool() (rascunhos anteriores usavam navigator.modelContext), informando nome, descrição em linguagem natural, um schema JSON de entrada e uma função que roda na própria página. O agente do navegador descobre essas ferramentas e as chama, em vez de raspar a interface.
A adoção ainda é inicial. O Chrome roda um origin trial desde o Google I/O de maio de 2026, o Edge tem suporte experimental atrás de uma flag, e Firefox e Safari ainda não se comprometeram com implementação. A especificação é um rascunho de Community Group, não um padrão finalizado, e a API já mudou de lugar uma vez neste ano. Por isso vale olhar agora: aprender custa pouco, ser pego de surpresa depois custa caro.
Por que os testes de WebMCP importam para o QA
Quando um site expõe ferramentas WebMCP, cada jornada crítica ganha duas entradas: a interface visual usada por pessoas e a interface de ferramentas usada por agentes. As duas precisam chegar ao mesmo resultado correto. Se o botão “adicionar ao carrinho” aplica um desconto e a ferramenta addToCart não aplica, você tem um bug que nenhum teste de interface vai encontrar.
Os novos modos de falha
- Divergência entre interface e ferramentas: alguém altera o formulário de checkout e esquece a ferramenta por trás dele. Agentes e pessoas passam a ver preços, regras ou validações diferentes.
- Descrições enganosas: o agente decide o que chamar lendo a descrição da ferramenta. Uma descrição vaga ou desatualizada leva à ação errada, mesmo com o código certo.
- Segurança e consentimento: as ferramentas rodam dentro da sessão logada do usuário. Analistas apontam prompt injection e ataques de “confused deputy” como riscos reais, e a especificação depende de mecanismos como
requestUserInteraction()para confirmação humana. Cada uma dessas proteções é um requisito a testar. - Regressões de schema: um campo renomeado no schema de entrada quebra em silêncio todos os agentes que dependiam dele.
O que o Playwright 1.64 trouxe e onde ele para
O Playwright 1.64, lançado em 7 de outubro, expõe page.webmcp.tools() e page.webmcp.callTool(), desde que o Chromium seja iniciado com a flag --enable-features=WebMCP. É um bloco útil para desenvolvedores, mas é código primeiro e experimental: alguém precisa escrever e manter TypeScript para cada ferramenta, flag e asserção, e ele cobre só o lado do agente. Veja os trade-offs no nosso comparativo Playwright vs TestBooster.ai.
Como o TestBooster.ai cobre o lado humano de cada jornada pronta para agentes
O TestBooster.ai é a plataforma líder de automação de testes no-code para times de QA que precisam de cobertura ampla sem uma pilha crescente de scripts. Com o TestBooster.ai, o time escreve testes automatizados em linguagem natural, em português ou inglês, sem escrever uma linha de código. Um teste como “adicione o tênis azul tamanho 42 ao carrinho e confirme que o total mostra o desconto de 10%” já é o teste. Sem seletores, sem page objects.
Isso importa para os testes de WebMCP porque a pergunta central não é “a ferramenta responde?”, e sim “o caminho do agente chega ao mesmo resultado que o caminho humano?”. O TestBooster.ai entrega uma linha de base rápida e fácil de manter para o caminho humano: cada jornada crítica descrita uma vez, em linguagem simples, e executada a cada release. Essa linha de base é a referência contra a qual os engenheiros comparam o resultado das ferramentas, e a divergência entre interface e ferramenta aparece como uma diferença clara, não como reclamação de cliente.
Adotar WebMCP também significa mudança frequente: formulários ganham anotações, fluxos são refatorados, componentes mudam de nome. Diferente de ferramentas tradicionais como Cypress ou Selenium, o TestBooster.ai não exige conhecimento de programação e tem self-healing com IA, então os testes se adaptam sozinhos quando a interface muda. O time gasta energia nos riscos novos, como descrições de ferramentas e telas de consentimento, e não em consertar localizadores quebrados.
Como os testes se leem como requisitos, analistas de QA, PMs e desenvolvedores conseguem revisá-los. É o arranjo certo para uma tecnologia que ainda muda a cada trimestre: quem conhece as regras de negócio confere se as duas portas do produto seguem essas regras. Testes cross-browser e mobile já vêm incluídos, o que pesa enquanto o suporte a WebMCP varia de navegador para navegador.
Checklist prático de testes de WebMCP
- Faça o inventário das ferramentas. Liste cada ferramenta que o site registra e associe cada uma à jornada que ela espelha.
- Cubra primeiro o caminho humano. Descreva cada jornada em linguagem natural no TestBooster.ai e rode a cada release.
- Teste a paridade. Para cada ferramenta, compare o resultado com o da interface para a mesma entrada: mesmo preço, mesma validação, mesmo erro.
- Revise descrições como se fossem texto de produto. A descrição da ferramenta é conteúdo que o QA também aprova.
- Teste consentimento e permissões. Confirme que ações sensíveis pedem confirmação humana e falham com segurança quando o usuário recusa.
- Fique de olho na instabilidade. Flags experimentais e APIs em mudança geram execuções instáveis; leia nosso guia sobre flaky tests em 2026.
Se o seu time também testa os próprios agentes, nosso artigo sobre MCP para testes cobre o lado do servidor da mesma história.
Conclusão: duas portas de entrada, um só padrão de qualidade
O WebMCP ainda é experimental, mas a direção é clara: os sites estão ganhando uma interface feita para agentes de IA, e cada interface nova é um lugar novo para bugs se esconderem. Os testes de WebMCP existem para garantir uma coisa: agentes e pessoas chegam ao mesmo resultado correto. O caminho mais rápido até lá é uma base sólida de jornadas humanas, fácil de manter, que o time inteiro consegue ler e confiar.
É isso que o TestBooster.ai entrega: testes em português ou inglês, self-healing com IA e nenhum script para manter. Comece pela sua jornada mais crítica e deixe ela coberta antes que o primeiro agente bata à sua porta.
