WebMCP PoC: Expondo Ferramentas de Navegador para Agentes de IA

WebMCP é um dos anúncios de agente da web mais importantes do Google I/O 2026 porque muda o contrato entre um site e um agente de IA baseado em navegador. Em vez de pedir a um agente que olhe para capturas de tela, inferir controles, clicar em um layout e esperar que ele não perca estados ocultos em JavaScript, o WebMCP permite que uma página exponha ferramentas estruturadas diretamente ao agente.

O resumo da palestra do desenvolvedor do Google descreve o WebMCP como um padrão aberto proposto para expor funções JavaScript e formulários HTML a agentes de IA baseados em navegador, com o teste experimental de origem começando no Chrome 149 e o suporte ao Gemini no Chrome vindo mais tarde. O post do Chrome para Desenvolvedores I/O enquadra a mesma ideia como transformar sites em "kits de ferramentas agentes". O repositório webmachinelearning/WebMCP explica a motivação central: aplicativos da web já possuem capacidades autenticadas, com estado, do lado do cliente, mas integrações de ferramentas no backend muitas vezes forçam os desenvolvedores a duplicar esse estado em outro lugar.

O Effloow Lab executou um pequeno PoC sandbox para este artigo. O laboratório não executou uma sessão de teste de origem nativa do Chrome 149. Ele validou a forma do contrato voltado para desenvolvedores: um descritor de ferramenta em nível de página com um nome, descrição, esquema de entrada estilo JSON, campos obrigatórios e um manipulador determinístico. A nota de evidência completa está em data/lab-runs/webmcp-browser-agent-open-standard-poc-2026.md.

Por que o WebMCP é importante

A maioria dos agentes de navegador ainda opera como usuários altamente automatizados. Eles inspecionam a página, identificam controles visíveis, clicam, digitam, esperam e se recuperam quando a interface do usuário muda. Isso é útil, mas também é frágil. Um modal, botão renomeado, resultado carregado de forma preguiçosa, banner de cookie ou erro de validação oculto pode quebrar um fluxo de trabalho que parecia simples em uma demonstração.

O MCP resolveu um problema relacionado para ferramentas e fontes de dados fora do navegador. A documentação oficial do Protocolo de Contexto de Modelo descreve o MCP como um padrão aberto para conectar aplicações de IA a sistemas externos, como arquivos, bancos de dados, ferramentas e fluxos de trabalho. Esse modelo funciona bem quando a ferramenta é um servidor, processo local ou API remota. É menos natural quando o estado relevante já está dentro de uma aba de navegador autenticada.

O WebMCP está mais próximo da interface do usuário. A página da web registra ferramentas chamáveis por agentes a partir da própria página. Essas ferramentas podem ser apoiadas por JavaScript existente, formulários ou estado do lado do cliente. Para os desenvolvedores, a promessa não é "agentes podem fazer qualquer coisa". A melhor formulação é mais restrita: agentes podem chamar as ações que o proprietário da página intencionalmente expõe, usando esquemas legíveis por máquina em vez de adivinhação visual.

Essa distinção é importante para equipes de produção. Um site de checkout, painel, console de suporte, CMS ou aplicativo administrativo interno não quer que um agente improvise cliques em todo o DOM. Ele quer que o agente use um contrato limitado: pesquisar pedidos, filtrar faturas, preparar um rascunho, ler uma política ou validar um formulário antes da submissão.

O que o Google realmente anunciou

A interpretação mais segura é: o WebMCP é inicial e experimental, mas real o suficiente para que os desenvolvedores comecem a aprender a forma.

O resumo da Palestra do Desenvolvedor do Google diz que o WebMCP é um padrão proposto para expor ferramentas estruturadas como funções JavaScript e formulários HTML, e que o teste de origem começa no Chrome 149. O post do Chrome I/O acrescenta que o Gemini no Chrome suportará as APIs mais tarde.

Há também atividade no ecossistema em torno do rascunho. O repositório GoogleChromeLabs/webmcp-tools inclui utilitários e demonstrações para desenvolvedores, incluindo uma extensão Model Context Tool Inspector, ferramentas de avaliação e aplicações de exemplo que expõem ações através de padrões WebMCP imperativos ou declarativos. O guia Puppeteer WebMCP documenta o WebMCP como uma API experimental e observa que requer Chrome 149+ com flags.

Essa combinação dá aos desenvolvedores o suficiente para prototipar, mas não o suficiente para tratar o WebMCP como uma dependência de produção estável. O movimento certo em maio de 2026 é construir experimentos progressivos, manter os caminhos normais da interface do usuário intactos e evitar vincular fluxos de usuários principais à disponibilidade nativa do WebMCP.

O PoC Sandbox

O PoC local usou Node.js v25.9.0 e npm 11.12.1. O Effloow Lab inspecionou os metadados do pacote de demonstração pública para @jason.today/webmcp, que retornou a versão 0.1.13, licença MIT e a URL do repositório github.com/jasonjmcghee/webmcp. Os metadados do pacote mais recente do Puppeteer retornaram 25.1.0, mas o Puppeteer não estava instalado neste repositório, então o laboratório não tentou um teste nativo do navegador.

O PoC executado criou um pequeno modelContext.registerTool() simulado e registrou uma ferramenta:

modelContext.registerTool({
  name: 'calculate_refund_window',
  description: 'Retorna o prazo e o rótulo de elegibilidade para uma data de compra.',
  inputSchema: {
    type: 'object',
    properties: {
      purchaseDate: { type: 'string', pattern: '^\\d{4}-\\d{2}-\\d{2}$' },
      returnDays: { type: 'integer', minimum: 1, maximum: 90 }
    },
    required: ['purchaseDate', 'returnDays']
  }
}, ({ purchaseDate, returnDays }) => {
  // lógica da função aqui
  }
});