Navegadores como Chrome e Edge começaram a testar uma tecnologia chamada WebMCP, que permite que assistentes de inteligência artificial preencham formulários, façam buscas e completem ações em sites sem precisar simular o comportamento de um usuário humano. A novidade ainda está em fase de testes, mas já muda a forma como sites podem se preparar para visitantes que usam agentes de IA no navegador.
O que é o WebMCP?
O WebMCP é um recurso que permite a um site informar, diretamente ao agente de IA presente no navegador do visitante, quais ações podem ser realizadas na página e como executá-las. Hoje, quando um usuário pede para sua IA enviar uma mensagem por um formulário de contato, o agente precisa identificar os campos da página como se fosse uma pessoa, o que costuma falhar.
Com o WebMCP, o próprio site oferece ao agente uma lista de ações possíveis, como “enviar mensagem” ou “buscar produtos”, cada uma com uma descrição clara do que faz e quais informações precisa. Essas ações são chamadas de “ferramentas” pelo WebMCP. O agente escolhe a ferramenta necessária, preenche os dados e o código do próprio site executa a tarefa.
A tecnologia já funciona em versões de teste do Chrome e do Edge. O Chrome abriu um período de testes a partir da versão 149, e o Edge também está rodando sua própria avaliação. Isso significa que o recurso já funciona para visitantes reais, mas apenas em sites que se cadastram no teste e adicionam um token específico às suas páginas, enquanto a fase de testes durar.
Mesmo nesse estágio inicial, o Google já trata o WebMCP como parte de um site saudável: a ferramenta Lighthouse, usada para avaliar a qualidade técnica de páginas, passou a verificar se elas têm ferramentas WebMCP configuradas e se os formulários estão preparados para isso.
Por que o WebMCP representa uma vantagem?
A principal vantagem do WebMCP é unir, dentro do próprio navegador, a capacidade de “agir” que faltava aos agentes de IA. Como todo mundo já sabe usar um navegador, a adoção tende a ser mais simples. O recurso funciona na aba em que o usuário já está logado, sem exigir servidor separado, processo de autenticação adicional ou instalação de qualquer programa extra.
Essa simplicidade coloca o WebMCP à frente do MCP tradicional, que depende da conexão de um servidor externo ao assistente de IA, uma exigência que afasta boa parte dos usuários comuns.
Além disso, o WebMCP aproveita estruturas que os sites já possuem. É possível transformar buscas, carrinhos de compra e formulários existentes em ferramentas com poucas linhas de código JavaScript, ou simplesmente adicionando dois atributos ao HTML de um formulário. Em plataformas como o WordPress, onde a maioria dos formulários vem de um número limitado de plugins, uma única atualização de plugin pode converter milhões de formulários em ferramentas compatíveis.
WordPress já tem base pronta para o recurso
O WordPress conta com parte da estrutura necessária para adotar o WebMCP. A Abilities API, incluída na versão 6.9 da plataforma, permite que o próprio WordPress, plugins e temas declarem, em um só lugar, o que são capazes de fazer. Cada “habilidade” tem nome, descrição, um esquema de entradas e saídas, além de uma verificação de permissão vinculada aos papéis de usuário do WordPress.
Essas habilidades ficam privadas por padrão, e cabe a cada plugin decidir quais delas disponibilizar para agentes de IA. A mesma habilidade pode ser oferecida pela API REST ou usada em recursos de IA dentro do painel administrativo.
Atualmente, o plugin WordPress MCP Adapter já transforma essas habilidades em ferramentas MCP direto do site, sem exigir um servidor separado, o que facilita a vida de proprietários de sites que queiram conectar seus próprios assistentes. Como uma habilidade já reúne nome, descrição e esquema de entrada, os mesmos elementos exigidos por uma ferramenta WebMCP, adaptá-la para visitantes externos exige um trabalho relativamente pequeno, já que aproveita uma funcionalidade que o site já possui.
Quais são os desafios ainda não resolvidos?
Apesar do potencial, o WebMCP segue sendo um experimento, e há questões em aberto. A própria API ainda está em mudança: os testes do Chrome e do Edge devem rodar até 30 de março de 2027, e a estrutura técnica já foi alterada uma vez, passando de “navigator.modelContext” para “document.modelContext”. Isso significa que qualquer implementação feita agora pode precisar de ajustes antes que o recurso vire um padrão definitivo.
Nem todos os navegadores aderiram à proposta. A WebKit, motor por trás do Safari, se opõe ao WebMCP, citando preocupações com privacidade, segurança, design da API e sobreposição com outras tecnologias. A Mozilla, por sua vez, adotou posição classificada como neutra. Como praticamente todos os navegadores do iPhone, incluindo o Chrome, rodam sobre o WebKit, uma parcela expressiva dos usuários de celular pode ficar de fora do recurso enquanto essa posição não mudar.
Outro ponto é que os agentes de IA precisam, de fato, passar a usar essas ferramentas. Um site pode registrar suas ações disponíveis, mas isso não garante que um assistente vá chamá-las.
A segurança é apontada como o desafio mais complexo. Como uma ferramenta roda com o login do visitante, ela pode executar qualquer ação que o próprio usuário executaria. Isso abre espaço para que uma página maliciosa, ou até um comentário publicado em um site, tente induzir o agente a acionar uma ferramenta indevidamente, prática conhecida como “prompt injection”. Esse tipo de ataque ainda não tem solução definitiva para nenhum tipo de agente de IA. A especificação do WebMCP permite marcar uma ferramenta como “somente leitura” ou como tendo consequências significativas ou irreversíveis, mas essas marcações funcionam apenas como indicação, cabendo ao navegador e ao próprio agente decidir se vão respeitá-las.
Como um site pode testar o recurso?
Existem duas formas de adicionar ferramentas WebMCP a uma página. A mais simples consiste em incluir os atributos “toolname” e “tooldescription” a um formulário já existente, fazendo com que o Chrome o transforme automaticamente em uma ferramenta, usando os campos do formulário como entradas.
Para elementos que não são formulários, é possível registrar uma ferramenta via JavaScript, chamando a função “document.modelContext.registerTool()” com nome, descrição, um esquema de entradas no formato JSON Schema e uma função que será executada quando o agente acionar a ferramenta.
A recomendação é começar por um único formulário, como o de busca ou de contato do site, antes de expandir o recurso para outras áreas da página.
Com informações de elementor.com.
