Análise Stickybit · Junho 2026

Seu agente clica em telas. Logo ele vai chamar funções. WebMCP muda a economia da atuação na web — e quebra quem só sabe raspar DOM.

Hoje, automatizar a web com agente significa tirar screenshot, ler o DOM e simular clique: frágil, caro em tokens e que quebra a cada mudança de layout. O WebMCP, já em origin trial no Chrome 149 (anunciado no Google I/O 2026), inverte o jogo: o próprio site expõe ferramentas que o agente chama direto. Quem depende de scraping de UI vai ver a robustez e a economia mudarem de patamar — e os buracos de segurança aparecerem em lugares novos. Monitorar e se preparar agora é barato; refazer tudo depois, não.

O Problema

O Problema: Atuar pela UI É Caro e Frágil

O modo atual de o agente agir na web — enxergar a tela e simular um humano — é uma gambiarra cara que toda automação paga em token e em manutenção.

Screenshot → DOM → clique queima tokens

Cada ação obriga o agente a capturar a tela, interpretar uma árvore DOM enorme e decidir onde clicar. São milhares de tokens por passo, multiplicados por cada interação. É exatamente o tipo de consumo de baixo valor que estoura orçamento — e que o WebMCP elimina ao expor a ação como uma chamada de função direta.

Quebra a cada mudança de layout

Automação baseada em seletores e posição de elemento é refém do front-end: o time muda um botão de lugar e seu agente para. Manutenção vira um imposto permanente. Já vivemos essa parede em casos de transcrição de vídeo, onde só DOM-scraping após ação manual + cache distribuído resolvia.

Autorização de UI não é autorização de negócio

O risco que o próprio padrão admite: o agente executa qualquer ação que a página permita, mesmo sem ter permissão para a regra de negócio por trás. Quem confunde 'consegui clicar' com 'estou autorizado' abre uma brecha — a mesma classe de problema que derrubou agentes corporativos em 2026.

Prompt injection indireto entra pela tela

Conteúdo de terceiros na página pode instruir o agente a agir contra você. O WebMCP cria hints (untrustedContentHint, readOnlyHint) para mitigar, mas eles são paliativos: a camada de atuação está chegando antes da camada de governança. Sem fronteiras de confiança, atuação direta vira vetor de ataque.

Nossa Abordagem

A Abordagem Stickybit: Preparar os Dois Lados do Fork

A web está bifurcando entre o que ainda exige scraping e o que já fala WebMCP. Não apostamos tudo em um lado — desenhamos para os dois e migramos sem refação.

1

Expor suas ferramentas para agentes (lado servidor)

Anotamos seus formulários e fluxos com a API declarativa (toolname, tooldescription) ou registramos tools com a API imperativa (modelContext). Seu site passa a ser cliente de primeira classe para agentes — sem refazer o front-end, aproveitando o HTML que já existe. Você decide exatamente quais ações um agente pode disparar.

2

Consumir WebMCP onde existe, com fallback (lado cliente)

Para automações que você opera, usamos WebMCP quando o site oferece e caímos para DOM-scraping com cache distribuído quando não. Uma camada de abstração isola seu agente do método — quando o alvo adotar WebMCP, você ganha robustez sem reescrever a automação.

3

Fronteira de confiança entre tela e negócio

Toda tool exposta passa por uma checagem de autorização de domínio, não só de UI: o agente pode clicar, mas a regra de negócio decide se a ação acontece. Marcamos conteúdo externo como não-confiável e tratamos toda entrada de página como hostil — zero-trust ligado ao seu control plane.

4

Medir o ganho de tokens da migração

Comparamos custo por ação no modelo screenshot→DOM→clique contra a chamada direta via WebMCP. O delta de tokens entra na mesma conta do seu routing e dos seus caps — atuação eficiente é FinOps de agente, não só engenharia.

Resultados

O que entregamos

Chrome 149

Padrão real, não slide

WebMCP está em origin trial no Chrome 149 e foi apresentado no Google I/O 2026 como parte do trabalho de IA no navegador. Não é especulação de roadmap: é algo que dá para testar agora e que vai redefinir como agentes agem na web.

Chamada direta

Token por ação despenca

Trocar 'interpretar a tela inteira' por 'chamar uma função' corta drasticamente o consumo por interação. Em automações de alto volume, é a diferença entre um workload que sangra e um que cabe no orçamento.

0 quebra por layout

Acaba o imposto de manutenção

Ferramentas declaradas pelo site não quebram quando o layout muda. A automação para de ser refém do front-end alheio — e seu time deixa de gastar sprints consertando seletores.

2 lados do fork

Quem se prepara hoje migra de graça

Construir com a camada de abstração agora torna a adoção do WebMCP um upgrade, não uma reescrita. A web já serve agentes em escala crescente; estar dos dois lados do fork é vantagem competitiva, não custo afundado.

Sua automação está pronta para quando o site virar uma API de agente?

Mapeamos onde seu produto deveria expor tools para agentes, onde suas automações ainda dependem de DOM frágil, e desenhamos a camada que migra para WebMCP sem refação — com fronteira de confiança entre clicar e executar. Antes que o Chrome torne isso o padrão.