WebMCP: Como o Chrome Está Reformulando os Agentes de IA na Web
Eu estava observando um agente de IA tentar adicionar um item a um carrinho de compras. Não era qualquer carrinho — era um site de e-commerce ao vivo que eu mesmo tinha construído, então eu conhecia cada elemento, cada animação, cada caso extremo. O agente tinha capacidades de visão, um modelo sólido por trás, e eu tinha passado a maior parte de uma terça-feira acertando a configuração.
O resultado? O agente tirou uma captura de tela, identificou errado um menu hover, clicou no elemento errado três vezes, acidentalmente atualizou a página e, por fim, me enviou uma mensagem de erro educada explicando que não conseguia completar a tarefa.
47 segundos. Mais em tokens de API do que eu gostaria de admitir. Zero tarefas concluídas.
Aquele momento cristalizou algo que eu vinha sentindo há um tempo: a navegação web por IA baseada em visão é poderosa em demos controladas e genuinamente dolorosa em escala de produção. O modelo vê pixels. Ele adivinha coordenadas. Ele clica onde acha que um botão está, não onde o botão realmente está. Em uma página de marketing estática com botões grandes e coloridos, funciona bem. Em qualquer coisa com UI dinâmica, estados de hover, modais que aparecem com animação ou itens de menu que só surgem na interação — quebra, lenta e custosamente.
Então, quando ouvi que o Google Chrome estava lançando algo chamado WebMCP no Chrome Beta, classifiquei como "interessante, mas provavelmente não está pronto." Duas semanas depois, eu tinha a flag ativada e estava observando interações de agentes de IA que completavam em menos de dois segundos com confiabilidade quase perfeita.
Eu estava errado sobre a parte do "não está pronto." Aqui está tudo o que aprendi.
As Duas Abordagens Quebradas para Navegação Web com IA
Antes de o WebMCP fazer sentido, você precisa entender por que as opções atuais não são boas o suficiente para trabalho sério.
Navegação baseada em visão é a abordagem que a maioria das pessoas imagina quando pensa em agentes de IA interagindo com sites. O agente captura uma tela, envia para um modelo de visão, o modelo identifica elementos de UI e então o agente tenta clicar, rolar ou digitar com base nessa interpretação visual. Ferramentas como o Computer Use do Claude, as capacidades visuais do GPT-4o e vários frameworks de automação de navegador usam variações dessa abordagem.
Os problemas se acumulam conforme a complexidade aumenta. Menus dropdown acionados por hover exigem que o agente primeiro passe o mouse, tire outra captura de tela e depois clique — e ele frequentemente erra a posição do hover. Transições animadas confundem o timing da captura. Elementos sobrepostos causam cliques errados. Modo escuro, configurações de alto contraste ou qualquer CSS diferente dos dados de treinamento degradam o desempenho visivelmente.
A questão do custo é real e frequentemente subestimada. A inferência de modelo de visão é cara em relação à inferência de texto. Quando você está executando um fluxo de trabalho que requer 20-30 interações de UI, os custos de tokens para processamento de visão acumulam rápido. Executei uma automação de múltiplas etapas em uma UI de dashboard complexa — 24 interações discretas — e só os custos do modelo de visão superaram o que eu normalmente gastaria em um dia inteiro de trabalho com IA baseada em texto.
Servidores MCP customizados — a segunda opção — resolvem os problemas de confiabilidade e custo de forma elegante, mas introduzem um conjunto diferente de restrições. O Model Context Protocol se tornou o padrão para dar a agentes de IA acesso a ferramentas externas e APIs. Você constrói um servidor customizado que expõe a funcionalidade da sua aplicação como ferramentas invocáveis, e o agente chama essas ferramentas diretamente em vez de tentar clicar em botões na tela.
O problema: servidores MCP exigem pré-configuração manual. Antes de uma sessão do agente começar, você precisa saber quais servidores MCP o agente vai precisar, instalá-los, configurar os parâmetros de conexão e manter essas configurações atualizadas. Não há descoberta dinâmica — o agente não pode simplesmente acessar um site arbitrário e perguntar "o que posso fazer aqui?" Ele só pode usar ferramentas que foram registradas antes do início da sessão.
Essa é uma limitação arquitetural fundamental. Isso significa que servidores MCP escalam bem para integrações conhecidas e estáveis — as APIs internas da sua empresa, ferramentas padrão de desenvolvimento — mas não funcionam para a web aberta, onde você pode navegar para qualquer um de milhares de sites.
O WebMCP é a tentativa de pegar o que funciona no MCP (chamadas de função diretas, entradas tipadas, execução confiável) e trazer para o navegador com descoberta dinâmica. E a combinação é mais poderosa do que qualquer uma das abordagens sozinha.
O Que o WebMCP Realmente É — Além da Descrição de Marketing
Aqui está o panorama técnico preciso, porque os resumos de alto nível que li passam por cima do que torna isso interessante.
O WebMCP é um padrão JavaScript construído para ambientes de navegador. Um site pode registrar um conjunto de funções de ferramentas invocáveis usando a API WebMCP — cada ferramenta tem um nome, uma descrição em linguagem natural, um esquema de entrada no formato JSON Schema e uma função executora contendo a implementação real. Quando um agente de IA (em qualquer uma de suas formas: barra lateral do navegador, aplicativo desktop, extensão de IDE) navega até uma página com ferramentas WebMCP registradas, ele pode consultar a interface WebMCP para descobrir o que está disponível.
Sem pré-registro necessário. Sem arquivos de configuração. Sem etapa de instalação para o usuário final.
O modelo mental que fez sentido para mim: o WebMCP torna os sites "legíveis para agentes." Agora, os sites são projetados para olhos humanos e cliques de mouse. O WebMCP adiciona uma interface paralela projetada para agentes de IA — uma que fala em funções e esquemas em vez de pixels e coordenadas.
Considere um exemplo concreto. Você tem um aplicativo de tarefas. Normalmente, um humano interage com ele clicando em botões rotulados "Adicionar Tarefa", digitando em um campo de entrada, pressionando Enter. Um agente de IA usando navegação baseada em visão precisa simular todos esses passos. Um agente de IA usando WebMCP pode chamar addTodo({ text: "buy eggs", priority: "medium" }) e receber { success: true, id: "task_847" } em menos de 200 milissegundos.
A diferença na qualidade da interação não é incremental. É categórica.
O que me fez prestar mais atenção ao WebMCP especificamente — versus outros experimentos de automação de navegador que vi — é o suporte multi-agente embutido no design. Os mesmos registros de ferramentas WebMCP em uma página podem ser acessados por um agente na barra lateral do Chrome, Claude Desktop rodando localmente, Cursor ou VS Code com uma extensão de agente, ou uma ferramenta de IA customizada que você mesmo construiu. O site expõe a API uma vez. Qualquer agente compatível se beneficia sem que o site precise saber antecipadamente quais agentes vão se conectar.
Isso é significativamente diferente do modelo de servidor MCP customizado, que cria conexões ponto a ponto entre agentes específicos e serviços específicos. O WebMCP é broadcast: registre suas ferramentas, e qualquer agente compatível com WebMCP que navegar até lá pode usá-las.
Mas aqui está a parte que torna isso viável para aplicações reais em vez de apenas demos de brinquedo — e é a parte que a maioria da cobertura inicial pula inteiramente.
O Problema de Autenticação Que Precisava Ser Resolvido
Um aplicativo de tarefas sem contas, sem dados privados e com quatro ferramentas é uma demo limpa. Software real não funciona assim.
Aplicações reais têm contas de usuário. Contas de usuário têm dados privados que pertencem a pessoas específicas. Se você expõe ferramentas WebMCP sem autenticação, está expondo os dados de cada usuário para qualquer agente que navegue até sua página. Isso não é uma troca que você pode colocar em produção. É uma violação esperando para acontecer.
Quando olhei o WebMCP pela primeira vez, essa foi minha pergunta imediata: como funciona a autenticação? Porque "adicionamos uma API JavaScript que permite que agentes de IA chamem as funções do seu site" soa ótimo até você pensar em quais funções essas podem ser para um usuário logado. Qualquer agente pode ler meus e-mails? Enviar pedidos em meu nome? Acessar meus dados financeiros?
A resposta — quando implementada corretamente — é não. E entender por quê requer compreender a integração OAuth 2.1 que o WebMCP suporta.
O WebMCP inclui uma camada de autenticação construída sobre OAuth 2.1 — o mesmo framework de autorização padrão da indústria usado por Google, GitHub, Stripe e essencialmente todos os serviços web sérios. Quando um agente de IA tenta chamar uma ferramenta WebMCP protegida, ele é redirecionado por um fluxo de autorização OAuth. O usuário concede explicitamente ao agente permissões específicas (escopos), recebe um token limitado exatamente a essas permissões, e o agente usa esse token para chamadas subsequentes. Renovação de token, expiração e revogação funcionam de acordo com a especificação OAuth 2.1.
A implementação que testei usou a infraestrutura OAuth da Scale Kit, e aqui vou dar o devido crédito: a integração da Scale Kit é cuidadosamente projetada. Configurá-la requer três coisas — uma URL de ambiente, um client ID com secret e um resource ID. É genuinamente só isso. Todo o resto — armazenamento de tokens, ciclos de renovação, aplicação de escopos, gerenciamento de sessão do usuário — roda dentro da infraestrutura da Scale Kit.
Para qualquer pessoa que já implementou OAuth do zero e tem as cicatrizes de batalha para mostrar, ter uma integração OAuth multi-tenant funcionando que você não precisa manter sozinho não é pouca coisa.
O aspecto multi-tenant importa mais do que as pessoas enfatizam. Múltiplos usuários, cada um com sua própria sessão autenticada, cada um com seu próprio token limitado aos seus próprios dados, todos potencialmente executando agentes de IA simultaneamente contra a mesma aplicação habilitada com WebMCP. A Scale Kit lida com essa complexidade. Suas funções executoras WebMCP recebem um authContext validado que diz quem está fazendo a requisição — você simplesmente usa.
O que eu acho que isso desbloqueia, na prática: uma classe de integrações de agentes de IA que antes estavam bloqueadas por um esforço significativo de implementação. "Construa um agente que consiga gerenciar minhas tarefas de projeto" requer que o agente leia dados privados do projeto, faça chamadas de API autenticadas, lide com acesso multi-usuário — todas coisas que agora são muito mais tratáveis se você construir sobre WebMCP + Scale Kit OAuth em vez de tentar criar autenticação do zero.
Configurando Isso: O Que Realmente Funciona (e o Que Não Funciona)
Vou ser específico aqui porque a documentação ainda está alcançando a implementação, e encontrei vários problemas que não estão cobertos em lugar nenhum que encontrei.
Obtendo o Chrome Beta com WebMCP Ativado
O WebMCP é experimental desde fevereiro de 2026. Você precisa do Chrome Beta — não do Chrome Stable, não do Chrome Canary, especificamente do Beta. Baixe-o do canal de lançamento Beta do Google e instale-o separadamente da sua instalação regular do Chrome.
Uma vez instalado, navegue até chrome://flags no Chrome Beta e procure por "WebMCP." Ative a flag. Reinicie o Chrome Beta. Esse passo é fácil de esquecer porque o recurso simplesmente não existe na UI sem a flag — você não verá nenhum erro, simplesmente não vai funcionar.
A Extensão Model Context Tool Inspector
A extensão do Chrome atua como a ponte entre a API JavaScript WebMCP na página e seu agente de IA. Instale-a especificamente no Chrome Beta. As extensões não transferem automaticamente entre seu Chrome regular e o Chrome Beta — você precisa instalá-la novamente no Beta.
Um detalhe que me pegou: se você instalar a extensão enquanto o Chrome Beta está rodando sem a flag WebMCP ativada, a extensão instala mas não inicializa completamente a ponte WebMCP. Ative a flag primeiro, reinicie, depois instale a extensão.
Registrando Ferramentas na Sua Aplicação
Este é o trabalho voltado para o desenvolvedor. Adicionar WebMCP a uma aplicação existente significa registrar suas ferramentas usando a API JavaScript. Veja como um registro realista se parece:
// Call this when your app initializes
function registerWebMCPTools() {
// The optional chaining means this silently does nothing
// in browsers that don't support WebMCP — no errors,
// no broken UI for users without the extension.
window.webmcp?.registerTool({
name: "addTask",
description: "Creates a new task in the user's task list. " +
"Use this when the user wants to add, create, or save a new task. " +
"Returns the new task's ID on success.",
inputSchema: {
type: "object",
properties: {
title: {
type: "string",
description: "The task title or description"
},
dueDate: {
type: "string",
format: "date",
description: "Optional due date in YYYY-MM-DD format"
},
priority: {
type: "string",
enum: ["low", "medium", "high"],
description: "Task priority level"
}
},
required: ["title"]
},
executor: async (params) => {
const task = await taskService.create({
title: params.title,
dueDate: params.dueDate || null,
priority: params.priority || "medium"
});
return { success: true, taskId: task.id, title: task.title };
}
});
window.webmcp?.registerTool({
name: "listTasks",
description: "Retrieves the user's current task list. " +
"Use this to show, view, or check existing tasks. " +
"Can filter by status (pending, completed, or all).",
inputSchema: {
type: "object",
properties: {
status: {
type: "string",
enum: ["pending", "completed", "all"],
description: "Filter tasks by completion status"
}
}
},
executor: async (params) => {
const tasks = await taskService.list(params.status || "all");
return { tasks: tasks.map(t => ({
id: t.id,
title: t.title,
status: t.completed ? "completed" : "pending",
dueDate: t.dueDate
}))};
}
});
}
O campo description está fazendo mais trabalho do que aparenta. Essa descrição em linguagem natural é o que o modelo de IA lê para entender quando chamar cada ferramenta e como mapear a intenção do usuário para a função correta. Passei mais tempo escrevendo descrições claras de ferramentas do que em qualquer outra parte da implementação, e valeu cada minuto.
Descrições vagas como "Gerencia tarefas" levam o modelo a fazer escolhas erradas. Descrições específicas como "Cria uma nova tarefa — use quando o usuário quiser adicionar, criar ou agendar algo novo" dão ao modelo o que ele precisa para rotear as requisições corretamente.
Adicionando Autenticação para Aplicações Reais
Para qualquer coisa com dados de usuário, você vai querer ferramentas protegidas por autenticação:
window.webmcp?.registerTool({
name: "getMyProjects",
description: "Retrieves all projects belonging to the authenticated user. " +
"Requires the user to be logged in. Returns project names, statuses, " +
"and team member counts.",
requiresAuth: true,
scopes: ["projects:read"],
inputSchema: {
type: "object",
properties: {
includeArchived: {
type: "boolean",
description: "Whether to include archived projects (default: false)"
}
}
},
executor: async (params, authContext) => {
// authContext is injected by the WebMCP runtime after token validation.
// You don't need to validate the token yourself — it's already done.
const projects = await projectService.getUserProjects(
authContext.userId,
{ includeArchived: params.includeArchived || false }
);
return { projects };
}
});
O authContext.userId é populado pelo runtime do WebMCP após a validação do token OAuth. Seu código executor simplesmente usa — você não está fazendo verificação de token, parsing de token ou extração de ID de usuário por conta própria. Isso já aconteceu antes da sua função rodar.
Conectando o Claude Desktop (ou Outro Agente)
A configuração do agente depende de qual agente você está usando. Para o Claude Desktop, há uma entrada de conexão WebMCP que você adiciona ao arquivo de configuração do Claude Desktop. Para agentes baseados em navegador usando a extensão do Chrome, a descoberta é automática assim que a extensão está instalada no Chrome Beta com a flag ativada.
O problema mais comum: o Claude Desktop não mostra nenhuma ferramenta WebMCP. Primeira verificação — o Chrome Beta está rodando (não apenas instalado)? A extensão precisa de uma instância do Chrome Beta em execução para se comunicar. Segunda verificação — a página tem alguma ferramenta registrada? Abra o console do navegador e execute window.webmcp?.listTools() para verificar se as ferramentas estão realmente registradas na página.
Se as ferramentas aparecem no console mas não no Claude Desktop, a ponte entre o Chrome Beta e o Claude Desktop não está conectando. Reinicie o Claude Desktop com o Chrome Beta já aberto, não o contrário.
O Que Eu Realmente Penso — Sem Enrolação de Marketing
Certo. Hora de ser honesto sobre onde eu acho que o WebMCP realmente está, porque a cobertura da imprensa tech tem sido uniformemente positiva demais.
A ideia técnica central é sólida. Mudar de parsing de UI baseado em visão para invocação direta de funções é categoricamente melhor — mais rápido, mais barato, mais confiável. Não estou contestando isso. Minha interação fracassada de 47 segundos no carrinho de compras versus chamadas de ferramentas WebMCP em menos de 2 segundos não são números escolhidos a dedo; são representativos do que eu consistentemente observo.
Minha preocupação é a velocidade de adoção, e não é técnica — é econômica.
O WebMCP só funciona se os sites o implementarem. Todo site que não o implementa permanece no território da "navegação baseada em visão" para agentes de IA. E implementar o WebMCP requer tempo de desenvolvedor. Você precisa identificar quais ações de usuário expor como ferramentas, escrever as definições das ferramentas, escrever as funções executoras, testar o fluxo de autenticação e atualizar tudo quando suas APIs subjacentes mudarem. Para uma startup construindo um produto novo com mentalidade AI-first, isso pode ser requisito básico. Para uma empresa estabelecida com um backlog de produto cheio e recursos de engenharia limitados — isso compete com funcionalidades que os clientes estão ativamente pedindo hoje.
A analogia com o RSS continua vindo à mente. O RSS era tecnicamente superior a verificar sites manualmente para atualizações. Levou uma década para ver adoção significativa, precisou do Google Reader para se tornar dominante em seu espaço, e depois colapsou quando o Google Reader foi encerrado. A tecnologia certa vencer não é garantido, e não é rápido.
Também quero ser direto sobre a situação de estabilidade da especificação. O WebMCP é experimental. A flag do Chrome avisa você. Este artigo descreve a implementação de fevereiro de 2026 — nomes de métodos específicos, formatos de parâmetros e fluxos de autenticação podem mudar antes do WebMCP ser lançado no Chrome estável. Já observei outras APIs experimentais de navegador passarem por múltiplas revisões que quebraram compatibilidade antes de estabilizar. Construa algo com WebMCP hoje sabendo que provavelmente precisará atualizá-lo quando a especificação evoluir.
Uma admissão honesta: inicialmente descartei a abordagem declarativa em HTML mencionada em parte da documentação do WebMCP. Presumi que o registro apenas via JavaScript era a escolha obviamente certa. Depois de pensar mais, entendo por que uma opção declarativa pode ser útil para sites de conteúdo estático ou aplicações renderizadas no servidor onde o JavaScript no lado do cliente é mínimo. Ainda não estou totalmente convencido de que é necessário, mas fui rápido demais em descartá-lo.
Aqui está a parte em que quero contestar especificamente: o enquadramento do WebMCP como "substituição" dos servidores MCP tradicionais está errado e está causando confusão.
Servidores MCP tradicionais continuam sendo a ferramenta certa para qualquer coisa que não seja interação navegador-para-site. Acesso a APIs de backend, consultas a banco de dados, operações no sistema de arquivos, criação de processos — nada disso passa por um navegador. Servidores MCP customizados lidam com isso bem, e o WebMCP não toca nesses casos de uso.
O panorama real: agentes de IA usarão ambos. Servidores MCP customizados para capacidades de backend, WebMCP para interações baseadas em navegador com sites. São complementares, não competitivos.
O Que Você Pode Realisticamente Esperar
Para qualquer pessoa avaliando se vale a pena integrar o WebMCP agora, aqui está a versão honesta do que esperar.
Os ganhos de velocidade são reais e significativos. Chamadas de ferramentas em menos de 2 segundos versus interações baseadas em visão de 35-50 segundos é uma melhoria genuína de produtividade para qualquer fluxo de trabalho onde um humano está esperando pelo resultado. Se você está construindo recursos de agentes de IA voltados para o usuário, essa diferença importa para seus usuários.
As melhorias de custo são significativas em escala. Inferência de modelo de visão custa mais por operação do que inferência baseada em chamada de função. Para fluxos de trabalho com muitas interações, a diferença se acumula. Não executei benchmarks formais em cenários suficientes para dar uma proporção de custo confiável, mas nos meus testes, mudar de interações baseadas em visão para interações baseadas em WebMCP reduziu os custos do modelo em aproximadamente 60-75% para tarefas equivalentes.
A confiabilidade melhora dramaticamente. Meu rastreamento informal de taxa de sucesso mostrou 97-98% de sucesso em chamadas de ferramentas WebMCP corretamente formadas versus aproximadamente 68-72% em interações equivalentes baseadas em visão. As falhas no modo baseado em visão eram variadas — elemento errado identificado, problemas de timing de animação, estado inesperado da UI. As falhas do WebMCP eram quase exclusivamente entradas malformadas (que podem ser corrigidas melhorando os esquemas das ferramentas) ou erros no executor (que são apenas bugs comuns no seu código, facilmente depuráveis).
A autenticação funciona se você configurá-la corretamente. Uma vez que o OAuth da Scale Kit estava devidamente configurado no meu ambiente de teste, tive zero falhas de autenticação durante testes extensos. A renovação de token acontecia de forma transparente. Alternar entre múltiplas contas de teste funcionou corretamente todas as vezes.
O que você está trocando: tempo de implementação antecipado. Adicionar WebMCP a uma aplicação existente leva algumas horas para conjuntos de ferramentas simples, potencialmente um ou dois dias se você também estiver configurando OAuth e suporte multi-usuário. Você também está aceitando o risco de instabilidade da especificação até o WebMCP ser lançado no Chrome estável.
O conselho realista: se você está construindo um novo produto voltado para IA do zero, implemente WebMCP desde o primeiro dia. O overhead é baixo quando você está construindo do zero. Se está avaliando se deve adicionar WebMCP a uma aplicação de produção existente, comece com suas ações de usuário de maior valor — aquelas que um agente de IA mais se beneficiaria — e implemente essas primeiro. Veja a diferença de qualidade antes de se comprometer com uma integração completa.
Para Onde Isso Está Indo
No dia em que consegui fazer a integração OAuth funcionar, passei alguns minutos pensando em uma hipótese específica: o que significaria se todo site expusesse sua funcionalidade principal como ferramentas WebMCP?
Não tudo — isso é irreal e provavelmente indesejável. Mas as interações de alto valor. As ações que os usuários realizam repetidamente. Os fluxos de trabalho que importam.
Você navega até sua ferramenta de gerenciamento de projetos e seu assistente de IA pode ler sua lista de tarefas, marcar itens como concluídos, adicionar novas tarefas e atualizar prioridades — tudo sem nunca tirar uma captura de tela.
Você navega até seu banco e seu assistente de IA pode verificar seu saldo, revisar transações recentes ou iniciar uma transferência — autenticado, com escopo definido, revogável a qualquer momento.
Você navega até seu site de reservas de viagem e seu assistente de IA pode pesquisar voos, comparar preços e reservar — diretamente, sem lutar contra uma UI dinâmica.
Esses não são cenários de um futuro distante. São o que o WebMCP foi projetado para viabilizar, e são tecnicamente alcançáveis hoje para desenvolvedores dispostos a implementar a integração.
A distância entre "tecnicamente alcançável" e "amplamente disponível" é adoção. Estamos no início dessa curva de adoção agora — Chrome Beta, flags experimentais, documentação inicial para desenvolvedores. Se o WebMCP atinge massa crítica ou permanece um padrão de nicho depende de coisas que não são puramente técnicas: ferramentas para desenvolvedores, expansão do suporte de navegadores, crescimento do ecossistema de agentes de IA e se sites de alto valor suficientes consideram a integração como valendo o esforço.
Minha aposta é que ele atinge massa crítica, mas mais devagar do que o hype inicial sugere. O problema subjacente — agentes de IA precisando interagir com sites de forma eficiente — é real e persistente. A solução técnica que o WebMCP oferece é claramente melhor do que as alternativas. Esses dois fatos eventualmente se encontram.
A pergunta que vale a pena refletir: se alguém com um agente compatível com WebMCP navegar até sua aplicação hoje — essa pessoa consegue realizar algo útil? Ou ainda está presa assistindo um modelo de visão identificar errado seu menu hover por 47 segundos?
Essa é a lacuna que o WebMCP foi projetado para fechar. Construir algo para fechá-la para seus usuários vale o fim de semana.
Vamos Trabalhar Juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnologica? Adoraria ajudar.
- Fiverr (builds customizados e integrações): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
