Quando um agente de IA visita um site, é essencialmente um turista que não fala o idioma local. Seja construído em LangChain, Claude Code ou na cada vez mais popular estrutura OpenClaw, o agente fica reduzido a adivinhar quais botões pressionar: raspando HTML bruto, disparando capturas de tela para modelos multimodais e queimando milhares de tokens apenas para descobrir onde está uma barra de pesquisa.
Essa era pode estar terminando. No início desta semana, a equipe do Google Chrome lançou WebMCP — Web Model Context Protocol — como uma prévia no Chrome 146 Canary. WebMCP, que foi desenvolvido em conjunto por engenheiros do Google e da Microsoft e incubado através do W3C Grupo da comunidade Web Machine Learningé um padrão da web proposto que permite que qualquer site exponha ferramentas estruturadas e que podem ser chamadas diretamente aos agentes de IA por meio de uma nova API do navegador: navigator.modelContext.
As implicações para a TI corporativa são significativas. Em vez de construir e manter servidores MCP back-end separados em Python ou Node.js para conectar suas aplicações web a plataformas de IA, as equipes de desenvolvimento agora podem agrupar sua lógica JavaScript existente do lado do cliente em ferramentas legíveis pelo agente – sem re-arquitetar uma única página.
Agentes de IA são turistas caros e frágeis na web
Os problemas de custo e confiabilidade das abordagens atuais de interação entre agentes web (agentes de navegador) são bem compreendidos por qualquer pessoa que os tenha implantado em escala. Os dois métodos dominantes — captura visual de tela e análise de DOM — sofrem de ineficiências fundamentais que afetam diretamente os orçamentos empresariais.
Com abordagens baseadas em capturas de tela, os agentes passam imagens para modelos multimodais (como Claude e Gemini) e esperam que o modelo possa identificar não apenas o que está na tela, mas onde estão localizados botões, campos de formulário e elementos interativos. Cada imagem consome milhares de tokens e pode ter uma longa latência. Com abordagens baseadas em DOM, os agentes ingerem HTML e JavaScript brutos — uma linguagem estrangeira cheia de várias tags, regras CSS e marcação estrutural que é irrelevante para a tarefa em questão, mas ainda consome espaço de janela de contexto e custo de inferência.
Em ambos os casos, o agente está traduzindo entre aquilo para que o site foi desenhado (olhos humanos) e o que o modelo necessita (dados estruturados sobre as ações disponíveis). Uma única pesquisa de produto que um ser humano conclui em segundos pode exigir dezenas de interações sequenciais do agente – clicar em filtros, rolar páginas, analisar resultados – cada uma delas uma chamada de inferência que adiciona latência e custo.
Como funciona o WebMCP: Duas APIs, um padrão
O WebMCP propõe duas APIs complementares que servem como ponte entre sites e agentes de IA.
O API declarativa lida com ações padrão que podem ser definidas diretamente em formulários HTML existentes. Para organizações com formulários bem estruturados já em produção, este caminho requer um trabalho adicional mínimo; adicionando nomes e descrições de ferramentas à marcação de formulário existente, os desenvolvedores podem tornar esses formulários acessíveis aos agentes. Se seus formulários HTML já estão limpos e bem estruturados, provavelmente você já percorreu 80% do caminho.
O API imperativa lida com interações mais complexas e dinâmicas que exigem execução de JavaScript. É aqui que os desenvolvedores definem esquemas de ferramentas mais ricos – conceitualmente semelhantes às definições de ferramentas enviadas para os endpoints OpenAI ou API Anthropic, mas rodando inteiramente no lado do cliente no navegador. Através de RegisterTool(), um site pode expor funções como searchProducts(query, filtros) ou orderPrints(copies, page_size) com esquemas de parâmetros completos e descrições em linguagem natural.
O principal insight é que uma única chamada de ferramenta por meio do WebMCP pode substituir o que poderiam ter sido dezenas de interações de uso do navegador. Um site de comércio eletrônico que registra uma ferramenta searchProducts permite que o agente faça uma chamada de função estruturada e receba resultados JSON estruturados, em vez de fazer com que o agente clique nos menus suspensos do filtro, role pelos resultados paginados e capture imagens de cada página.
O caso empresarial: custo, confiabilidade e o fim da sucata frágil
Para os tomadores de decisão de TI que avaliam implantações de IA de agentes, o WebMCP aborda três pontos problemáticos persistentes simultaneamente.
Redução de custos é o benefício mais imediatamente quantificável. Ao substituir sequências de capturas de tela, chamadas de inferência multimodais e análise iterativa de DOM por chamadas de ferramentas estruturadas únicas, as organizações podem esperar reduções significativas no consumo de tokens.
Confiabilidade melhora porque os agentes não ficam mais adivinhando a estrutura da página. Quando um site publica explicitamente um contrato de ferramenta — "aqui estão as funções que eu apoio, aqui estão seus parâmetros, aqui está o que elas retornam" — o agente opera com certeza e não com inferência. Interações com falha devido a alterações na interface do usuário, carregamento dinâmico de conteúdo ou identificação ambígua de elementos são amplamente eliminadas para qualquer interação coberta por uma ferramenta registrada.
Velocidade de desenvolvimento acelera porque as equipes da web podem aproveitar seu JavaScript de front-end existente, em vez de criar uma infraestrutura de back-end separada. A especificação enfatiza que qualquer tarefa que um usuário possa realizar por meio da UI de uma página pode ser transformada em uma ferramenta, reutilizando grande parte do código JavaScript existente da página. As equipes não precisam aprender novas estruturas de servidor ou manter superfícies de API separadas para consumidores de agentes.
Humano no circuito por design, não uma reflexão tardia
Uma decisão arquitetônica crítica separa o WebMCP do paradigma de agente totalmente autônomo que dominou as manchetes recentes. O padrão é explicitamente projetado em torno de fluxos de trabalho cooperativos e humanos, e não de automação não supervisionada.
De acordo com Khushal Sagar, engenheiro de software do Chrome, a especificação WebMCP identifica três pilares que sustentam essa filosofia.
-
Contexto: todos os agentes de dados precisam entender o que o usuário está fazendo, incluindo conteúdo que muitas vezes não está visível na tela.
-
Capacidades: ações que o agente pode realizar em nome do usuário, desde responder perguntas até preencher formulários.
-
Coordenação: Controlar a transferência entre usuário e agente quando o agente encontra situações que não consegue resolver de forma autônoma.
Os autores da especificação no Google e na Microsoft ilustram isso com um cenário de compras: uma usuária chamada Maya pede ao seu assistente de IA para ajudá-lo a encontrar um vestido ecológico para um casamento. O agente sugere fornecedores, abre um navegador em um site de vestidos e descobre que a página expõe ferramentas WebMCP como getDresses() e showDresses(). Quando os critérios do Maya vão além dos filtros básicos do site, o agente chama essas ferramentas para buscar dados do produto, usa seu próprio raciocínio para filtrar "traje de coquetel apropriado," e então chama showDresses() para atualizar a página apenas com os resultados relevantes. É um ciclo fluido de gosto humano e capacidade do agente, exatamente o tipo de navegação colaborativa que o WebMCP foi projetado para permitir.
Este não é um padrão de navegação sem cabeça. O especificação afirma explicitamente que cenários sem cabeça e totalmente autônomos não são objetivos. Para esses casos de uso, os autores apontam para protocolos existentes, como o protocolo Agente para Agente (A2A) do Google. WebMCP é sobre o navegador – onde o usuário está presente, observando e colaborando.
Não é um substituto do MCP, mas um complemento
O WebMCP não substitui o Model Context Protocol da Anthropic, apesar de compartilhar uma linhagem conceitual e uma parte de seu nome. Ele não segue a especificação JSON-RPC que o MCP usa para comunicação cliente-servidor. Enquanto o MCP opera como um protocolo back-end conectando plataformas de IA a provedores de serviços por meio de servidores hospedados, o WebMCP opera inteiramente no lado do cliente dentro do navegador.
A relação é complementar. Uma empresa de viagens pode manter um servidor MCP back-end para integrações diretas de API com plataformas de IA como ChatGPT ou Claude, ao mesmo tempo em que implementa ferramentas WebMCP em seu site voltado para o consumidor, para que os agentes baseados em navegador possam interagir com seu fluxo de reservas no contexto da sessão ativa de um usuário. Os dois padrões atendem a diferentes padrões de interação sem conflito.
A distinção é importante para arquitetos corporativos. As integrações de back-end do MCP são apropriadas para automação de serviço a serviço, onde nenhuma interface de usuário do navegador é necessária. O WebMCP é apropriado quando o usuário está presente e a interação se beneficia do contexto visual compartilhado – que descreve a maioria das interações na Web voltadas para o consumidor e com as quais as empresas se preocupam.
O que vem a seguir: Da bandeira ao padrão
WebMCP está atualmente disponível no Chrome 146 Canary atrás do "WebMCP para teste" sinalizar em chrome://flags. Os desenvolvedores podem participar do Programa de visualização antecipada do Chrome para acesso à documentação e demonstrações. Outros navegadores ainda não anunciaram cronogramas de implementação, embora a coautoria ativa da especificação pela Microsoft sugira que o suporte do Edge é provável.
Os observadores da indústria esperam anúncios formais de navegadores até meados de 2026, com o Google Cloud Next e o Google I/O como locais prováveis para anúncios de lançamento mais amplos. A especificação está em transição da incubação comunitária dentro do W3C para um rascunho formal – um processo que historicamente leva meses, mas sinaliza um sério compromisso institucional.
A comparação que Sagar fez é instrutiva: o WebMCP pretende se tornar o USB-C das interações dos agentes de IA com a web. Uma interface única e padronizada à qual qualquer agente pode se conectar, substituindo o atual emaranhado de estratégias de scraping personalizadas e scripts de automação frágeis.
A concretização dessa visão depende da adoção – tanto por parte dos fornecedores de navegadores quanto dos desenvolvedores da web. Mas com o Google e a Microsoft enviando o código em conjunto, o W3C fornecendo a estrutura institucional e o Chrome 146 já executando a implementação atrás de uma bandeira, o WebMCP superou o obstáculo mais difícil que qualquer padrão da web enfrenta: passar da proposta ao software funcional.
