WebMCP: o que é, como funciona e por que ele muda a web

Em 10 de fevereiro de 2026, André Cipriani Bandarra, do Google, publicou um breve post no blog Chrome for Developers apresentando uma prévia inicial do WebMCP, o Web Model Context Protocol. A premissa era simples só na aparência: e se os sites pudessem dizer aos agentes de IA exatamente o que eles podem fazer, em vez de obrigar os agentes a adivinhar?

Essa ideia (trocar a adivinhação por um contrato estruturado entre sites e IA) agora está a caminho de se tornar um padrão web formal. Ela tem o apoio do Google e da Microsoft, está sendo incubada no W3C e sua primeira implementação em navegador já está disponível no Chrome Canary.

Para entender por que isso importa, pense no que acontece hoje quando você pede a um assistente de IA para reservar um voo. O agente tira uma captura de tela do site da companhia aérea, envia para um modelo de visão, tenta descobrir qual elemento na tela é o campo de partida, digita nele, tira outra captura de tela, procura o botão de busca, clica nele, tira outra captura, e assim por diante: dezenas de chamadas de inferência caras só para preencher um formulário. Se a companhia aérea redesenhar a página na semana seguinte, todo o processo quebra.

O WebMCP substitui todo esse ciclo por uma única chamada de função: searchFlights("AMS", "JFK", "2026-06-15"). O site publica a função. O agente a chama. Pronto.

A comunidade de SEO reagiu na hora. O especialista em SEO técnico Dan Petrovic chamou o WebMCP de a maior mudança no SEO técnico desde os dados estruturados, e a WordLift resumiu bem a analogia: se o Schema.org forneceu os substantivos padronizados da web, o WebMCP fornece os verbos padronizados.

O que é o WebMCP?

WebMCP significa Web Model Context Protocol. É um padrão web proposto que permite aos sites expor suas funcionalidades como "ferramentas" estruturadas, que os agentes de IA podem chamar diretamente pelo navegador.

A especificação foi escrita em conjunto por engenheiros do Google e da Microsoft: Brandon Walderman, Leo Lee e Andrew Nolan, da Microsoft, e David Bokan, Khushal Sagar e Hannah Van Opstal, do Google. Ela está sendo desenvolvida no W3C Web Machine Learning Community Group, o mesmo espaço do W3C que incuba outros padrões de aprendizado de máquina no nível do navegador, com o objetivo de se tornar um padrão web amplamente adotado.

Em fevereiro de 2026, o WebMCP ficou disponível por meio de uma flag experimental no Chrome 146 Canary. Os desenvolvedores podem acessar a documentação e as demos entrando no Early Preview Program do Google. Como a Microsoft é coautora ativa da especificação, a expectativa geral é que o Edge ganhe suporte em seguida.

A própria especificação descreve o WebMCP como "uma interface JavaScript que permite aos desenvolvedores web expor as funcionalidades de seus aplicativos web como 'ferramentas': funções JavaScript com descrições em linguagem natural e esquemas estruturados que podem ser acionadas por agentes de IA, assistentes de navegador e tecnologias assistivas."

Esse último trecho (tecnologias assistivas) passa fácil despercebido, mas é importante. Muito do que torna a web difícil para os agentes de IA também a torna difícil para leitores de tela e outras ferramentas de acessibilidade. A abordagem de ferramentas estruturadas do WebMCP pode melhorar bastante as duas coisas.

O problema que o WebMCP resolve

Hoje, os agentes de IA interagem com os sites por meio de duas abordagens principais, e ambas são fundamentalmente limitadas.

Agentes visuais tiram capturas de tela das páginas, as enviam para modelos de visão e tentam localizar botões e campos de formulário analisando pixels. Cada interação exige uma nova captura de tela e uma nova chamada de inferência. Uma simples busca de produto pode levar uma dúzia de idas e vindas. Se o layout do site mudar só um pouco (um redesign, um teste A/B, um tamanho de tela diferente), o agente pode falhar.

Agentes baseados no DOM analisam o HTML bruto da página e a árvore de acessibilidade para extrair dados e disparar eventos. Isso é mais confiável que a análise de pixels, mas ainda obriga o agente a consumir uma grande parte da janela de contexto lendo a estrutura da página, e exige que ele faça engenharia reversa do que cada elemento realmente faz. Um <button> com o rótulo "Ir" pode significar buscar, enviar, navegar ou excluir: o agente precisa deduzir pelo contexto ao redor.

As duas abordagens têm a mesma falha fundamental: a IA está tentando usar uma interface humana que nunca foi pensada para máquinas. Como diz a especificação do WebMCP, "mesmo quando os agentes têm sucesso, operações simples muitas vezes exigem várias etapas e podem ser lentas ou pouco confiáveis."

O WebMCP oferece um terceiro caminho. Em vez de o agente descobrir o que um site pode fazer, o site declara explicitamente suas capacidades, e o agente as chama diretamente.

Como o WebMCP funciona

O WebMCP introduz uma nova API do navegador: navigator.modelContext. Por meio dela, um site registra "ferramentas": funções JavaScript com descrições em linguagem natural e esquemas de parâmetros tipados. Juntas, essas definições de ferramentas formam o que vem sendo chamado de Tool Contract (contrato de ferramentas) do site: um menu legível por máquinas com todas as ações que um agente de IA pode executar naquela página.

A especificação oferece duas formas complementares de definir essas ferramentas.

A API declarativa (baseada em HTML)

Este é o caminho com menos atrito. Os desenvolvedores adicionam novos atributos aos formulários HTML que já existem, e o navegador os converte automaticamente em ferramentas que os agentes podem chamar. Não é preciso JavaScript.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

Os atributos toolname e tooldescription são os únicos acréscimos. O navegador lê a estrutura existente do formulário (nomes dos campos, tipos, padrões de validação, campos obrigatórios) e gera um esquema que um agente de IA consegue entender e acionar. Para sites que já têm formulários bem estruturados, é algo muito próximo de uma atualização plug-and-play.

Quando um agente aciona uma ferramenta declarativa, o navegador dispara um SubmitEvent com a propriedade agentInvoked definida como true. Isso permite que o backend diferencie envios feitos por pessoas e por agentes, o que é útil para análises, limitação de requisições (rate limiting) ou para devolver dados em um formato otimizado para máquinas em vez de HTML renderizado.

A API imperativa (baseada em JavaScript)

Para interações que vão além do envio de formulários (fluxos dinâmicos de várias etapas, processamento de dados em tempo real, lógica condicional), os desenvolvedores registram as ferramentas de forma programática:

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

Isso dá controle programático total. Os desenvolvedores podem adicionar e remover ferramentas dinamicamente conforme o estado do aplicativo, exibindo capacidades diferentes dependendo de o usuário estar logado, da página em que está ou da etapa em que chegou em um fluxo. E o mais importante: as funções handler podem reaproveitar a mesma lógica de frontend que já faz a interface do site funcionar. Você não está construindo uma camada de integração separada; está expondo o que já construiu.

O navegador como intermediário

Uma das decisões de design mais importantes do WebMCP é que o navegador faz a mediação de toda a comunicação entre o site e o agente. O site registra as ferramentas por meio de navigator.modelContext. O navegador apresenta essas ferramentas ao agente no formato que ele precisar. O site e o agente nunca conversam diretamente.

Como explicou Patrick Brosset, da equipe do Microsoft Edge: "É o navegador que conversa com o agente. A especificação usa o termo 'Model context provider'. Por meio de navigator.modelContext, a sua página fornece contexto (as ferramentas que um agente de IA vai usar), mas é o navegador que faz o trabalho de protocolo para você."

Essa arquitetura resolve três problemas de uma vez.

A autenticação é herdada. As ferramentas são executadas dentro da aba do navegador, no contexto da sessão que o usuário já tem. Se você está logado em um site de e-commerce, o agente tem acesso à mesma sessão: nada de fluxos OAuth separados, chaves de API ou gerenciamento de tokens.

O usuário continua no controle. Tudo acontece dentro da aba visível do navegador, então o usuário pode ver o que o agente está fazendo. Para ações sensíveis (compras, envio de dados pessoais, exclusões), a especificação inclui agent.requestUserInteraction(), que pausa a execução e pede ao navegador uma confirmação explícita do usuário antes de continuar.

Independência de plataforma. Seja o agente visitante executado no ChatGPT, no Claude, no Gemini ou em um modelo corporativo personalizado, o Tool Contract do site continua o mesmo. O navegador padroniza a interação.

De onde veio o WebMCP

O WebMCP não começou no Google nem na Microsoft. Começou com um engenheiro frustrado na Amazon.

No início de 2025, Alex Nahas estava criando agentes de IA internos na Amazon usando o Model Context Protocol (MCP) da Anthropic. A Amazon tinha montado o que, na prática, era um enorme servidor MCP expondo milhares de ferramentas dos seus serviços internos. "Você tinha que desativá-las com comandos de processo na string de conexão", contou Nahas à Arcade.dev. Era difícil de gerenciar, mas o verdadeiro obstáculo era a autenticação. A especificação do MCP havia adotado o OAuth 2.1, que praticamente nenhum serviço interno da Amazon tinha implementado. Cada serviço tinha sua própria forma de autenticação, e nenhum deles falava OAuth.

Então Nahas teve um insight: o navegador já tinha resolvido esse problema. Os funcionários da Amazon entravam em todos os serviços internos por meio de uma autenticação federada baseada no navegador. Se fosse possível rodar ferramentas no estilo MCP dentro da aba do navegador, toda essa autenticação viria de graça.

Ele criou o MCP-B (Model Context Protocol for Browser) como prova de conceito. Funcionou. Ele abriu o código.

Enquanto isso, engenheiros do Google e da Microsoft trabalhavam de forma independente em problemas parecidos. As equipes se conectaram por meio do W3C, convergiram para uma especificação unificada em agosto de 2025 e a publicaram no GitHub. O W3C Web Machine Learning Community Group a aceitou como entregável formal em setembro de 2025. Em fevereiro de 2026, o Google lançou a primeira implementação em navegador.

Uma nuance importante: apesar do nome, o WebMCP não é tecnicamente MCP. Como Nahas explicou, ele inicialmente defendeu portar o protocolo MCP completo (com JSON-RPC e tudo) para o navegador, mas o grupo de trabalho optou por não se acoplar demais à especificação da Anthropic. O WebMCP compartilha o modelo conceitual do MCP (ferramentas com esquemas que os agentes chamam), mas é um padrão distinto e nativo do navegador.

WebMCP vs. MCP vs. NLWeb

Os nomes geram confusão, então vale esclarecer como o WebMCP se encaixa ao lado dos outros protocolos do ecossistema de agentes de IA.

O MCP (Model Context Protocol) da Anthropic é um protocolo de backend. Ele conecta plataformas de IA a serviços externos por meio de integrações no servidor usando JSON-RPC. Se você quer que o Claude ou o ChatGPT consultem o banco de dados da sua empresa, o MCP é a forma de criar essa conexão. Ele exige uma infraestrutura de servidor dedicada.

O NLWeb da Microsoft, anunciado em maio de 2025, dá aos sites uma interface de consulta em linguagem natural e faz cada site funcionar como um servidor MCP para os agentes do ecossistema mais amplo. Ele opera no nível da API: os agentes conversam diretamente com o backend do site.

O WebMCP roda inteiramente no lado do cliente, no navegador. O site registra as ferramentas quando a página carrega. O navegador as expõe aos agentes visitantes. Nenhuma infraestrutura de backend é necessária. A autenticação é herdada da sessão do usuário.

Os três são complementares, não concorrentes. Uma empresa pode usar o MCP para integrações profundas de backend, o NLWeb para acesso em linguagem natural no nível da API e o WebMCP para interações no nível do navegador em que o usuário está presente. A diferença principal: o WebMCP é o único que permite aos desenvolvedores reaproveitar o código de frontend existente e não exige nenhuma nova infraestrutura no servidor.

Por que isso importa

O que torna o WebMCP relevante não é tanto um recurso isolado, mas a combinação de várias propriedades.

Custo por interação muito menor. Uma única chamada de ferramenta estruturada substitui o que antes exigia dezenas de interações de ida e volta envolvendo capturas de tela, inferência de modelos de visão e análise do DOM. Relatos iniciais sugerem uma redução de aproximadamente 67% na sobrecarga computacional em comparação com as abordagens de agentes visuais. Para sites de alto tráfego que lidam com milhares de interações de agentes por dia, a economia é considerável.

Confiabilidade desvinculada do design. Chamadas de função estruturadas não quebram quando um designer muda um botão de lugar, renomeia uma classe CSS ou roda um teste A/B. O Tool Contract oferece uma interface estável, independente do layout visual, o que significa que agentes e web designers podem evoluir de forma independente.

Esforço mínimo para os desenvolvedores. A API declarativa exige adicionar dois atributos HTML aos formulários existentes. Nada de JavaScript, novos endpoints ou documentação de API para manter. Para a maioria dos sites, o caminho para ficar "pronto para agentes" é mais curto do que a maioria das otimizações de SEO.

Acessibilidade como efeito colateral. As mesmas definições estruturadas de ferramentas que ajudam os agentes de IA também ajudam as tecnologias assistivas. Leitores de tela e outras ferramentas de acessibilidade enfrentam muitos dos mesmos desafios que os agentes de IA ao tentar entender o que uma página faz, e não só o que ela diz. O WebMCP pode melhorar significativamente as duas coisas.

Setores e casos de uso

A documentação da prévia inicial do Google destaca vários casos de uso principais, todos envolvendo fluxos de usuário estruturados e com várias etapas.

O e-commerce é o beneficiário mais óbvio. Em vez de um agente de IA se atrapalhar com filtros de produtos, seletores de tamanho e fluxos de checkout, uma loja expõe ferramentas como searchProducts(query, priceRange, category), addToCart(productId, quantity, size) e checkout(paymentMethod). Toda a jornada, da descoberta à compra, vira uma série de chamadas de função limpas. Para as empresas, isso pode significar taxas de conversão via agentes bem maiores.

Viagens e hotelaria se encaixam naturalmente. Busca de voos, reserva de hotéis e aluguel de carros são transações estruturadas, com vários parâmetros, que se traduzem diretamente em definições de ferramentas. O Google citou especificamente a reserva de viagens como um dos principais casos de uso verificados.

Produtos SaaS podem expor seus fluxos principais aos agentes. Imagine dizer a um assistente de IA "crie um novo quadro de projeto com três colunas e convide a minha equipe" e vê-lo executar isso por meio de chamadas de ferramentas estruturadas, em vez de cliques e digitação simulados.

Portais de atendimento ao cliente podem definir ferramentas para abrir chamados, verificar status e categorizar problemas. Um agente que consegue chamar createTicket(category, urgency, description) diretamente é muito mais confiável do que um que precisa navegar visualmente por um formulário de suporte com várias etapas.

As implicações para o SEO

A forte reação da comunidade de SEO ao WebMCP não é exagero: ela reflete uma mudança estrutural na forma como os sites são descobertos e usados.

A analogia com o Schema.org é útil. Quando os dados estruturados surgiram, eles deram aos buscadores uma forma padronizada de entender o que o conteúdo significa. Os sites que os adotaram cedo ganharam rich snippets, espaço em painéis de conhecimento e mais visibilidade nas buscas. Os que não adotaram ficaram em uma desvantagem que levou anos para ser superada.

O WebMCP faz algo paralelo, mas para uma era diferente. Ele dá aos agentes de IA uma forma padronizada de entender quais ações um site oferece. À medida que os agentes se tornam um canal principal pelo qual as pessoas interagem com a web (reservando viagens, fazendo compras, gerenciando serviços), os sites com Tool Contracts claros e confiáveis serão aqueles com os quais os agentes conseguem trabalhar com segurança.

Isso cria um novo tipo de dinâmica competitiva. Se um agente de IA consegue chamar bookFlight() diretamente em um site de viagens, mas precisa abrir caminho à força com raspagem de pixels em outro, a opção estruturada será mais rápida, mais barata e menos sujeita a erros. Com o tempo, essa vantagem de confiabilidade se acumula: os agentes (e as plataformas que os hospedam) vão naturalmente direcionar os usuários para os sites mais fáceis e baratos de usar.

Para as empresas, estar pronto para o WebMCP pode se tornar tão importante quanto ter um site responsivo para celular foi há uma década. Não da noite para o dia, mas aos poucos, à medida que o suporte dos navegadores se amplia e as interações mediadas por agentes crescem.

Como começar

O WebMCP está em prévia inicial, o que significa que a janela para quem quer sair na frente está aberta agora.

Faça uma auditoria dos principais fluxos do seu site. Identifique as ações centrais dos usuários (busca, reserva, checkout, envio de formulários, gerenciamento de conta) que se beneficiariam de ser expostas como ferramentas. Comece pelas transações de maior valor.

Comece pela API declarativa. Se você tem formulários HTML limpos e bem estruturados, adicionar os atributos toolname e tooldescription é o caminho mais rápido. Isso não exige JavaScript e pede mudanças mínimas no código.

Entre no Early Preview Program. O EPP do Google dá acesso à documentação completa, demos e ferramentas de teste. Inscreva-se pelo site do Chrome for Developers.

Teste no Chrome Canary. Ative a flag "WebMCP for testing" no Chrome 146 Canary. O Model Context Tool Inspector do Google oferece ferramentas de depuração para validar as suas definições de ferramentas.

Explore a API imperativa para fluxos complexos que exigem registro dinâmico de ferramentas ou lógica de várias etapas.

Para os desenvolvedores que querem começar a construir antes que o suporte nativo dos navegadores esteja amplamente disponível, o polyfill MCP-B de Alex Nahas (@mcp-b/global) permite registrar ferramentas com navigator.modelContext.registerTool() hoje mesmo. Ele funciona com frameworks de chamada de ferramentas no frontend já existentes, como CopilotKit, AGUI e SystintUI. A documentação completa está em docs.mcp-b.ai.

A especificação do W3C está disponível no GitHub.

O que vem por aí

A especificação ainda está em rascunho, mas a trajetória é clara.

O lançamento formal nos navegadores é esperado entre meados e o fim de 2026. O Google I/O e o Google Cloud Next são os palcos mais prováveis para anúncios mais amplos. Considerando a coautoria da Microsoft na especificação, o suporte no Edge deve acompanhar o cronograma do Chrome. Patrick Brosset, da equipe do Edge, sinalizou explicitamente a continuidade do investimento: "Na equipe do Edge, nos importamos em manter no circuito não só as pessoas, mas também os desenvolvedores. É por isso que nos importamos com o WebMCP."

A API continua evoluindo. A interface já passou do antigo window.agent para window.navigator.modelContext, e recursos como agent.requestUserInteraction() foram adicionados desde a proposta inicial de agosto de 2025. A comunidade do W3C está refinando ativamente a especificação com base em testes no mundo real.

O suporte multimodal está no roteiro mais amplo do ecossistema MCP. Espera-se que versões futuras do protocolo lidem com imagens, vídeo e áudio, o que significa que os agentes não vão só ler e escrever, mas também interpretar conteúdo visual e de áudio dentro da mesma estrutura.

A comunicação entre agentes é a próxima fronteira. A especificação atual se concentra na interação entre usuário e agente pelo navegador, mas o roteiro inclui cenários em que agentes delegam tarefas a outros agentes em vários serviços e páginas.

Perguntas frequentes

O WebMCP é a mesma coisa que o MCP da Anthropic? Não. Eles compartilham um modelo conceitual (ferramentas com esquemas que os agentes podem chamar), mas o WebMCP é um padrão distinto. Ele não usa JSON-RPC, roda inteiramente no navegador (não em servidores de backend) e foi projetado especificamente para a plataforma web. Os dois são complementares: uma empresa pode adotar ambos para casos de uso diferentes.

Quais navegadores já têm suporte ao WebMCP? Em fevereiro de 2026, o WebMCP ficou disponível no Chrome 146 Canary com a flag "WebMCP for testing". O suporte no Edge é amplamente esperado, dado o papel da Microsoft como coautora da especificação. O lançamento formal é esperado entre meados e o fim de 2026.

Preciso reescrever o meu site? Não. A API declarativa permite adicionar suporte ao WebMCP incluindo dois atributos HTML nos formulários existentes. Para sites com HTML limpo e bem estruturado, as mudanças são mínimas. A API imperativa exige JavaScript, mas pode reaproveitar a lógica de frontend existente.

Os agentes de IA podem executar ações sem a permissão do usuário? Não por design. O WebMCP inclui agent.requestUserInteraction(), que pausa a execução para que o usuário confirme ações sensíveis. A especificação foi construída sobre o princípio de que nenhuma ação relevante deve acontecer sem o conhecimento e o consentimento do usuário.

O WebMCP melhora a acessibilidade? Potencialmente, sim. As definições estruturadas de ferramentas que ajudam os agentes de IA a entender o que uma página faz também podem ajudar leitores de tela e outras tecnologias assistivas. A especificação do W3C lista explicitamente as tecnologias assistivas como um caso de uso-alvo ao lado dos agentes de IA.

Como o WebMCP afeta o SEO? O quadro completo ainda está se formando, mas os paralelos estruturais com o Schema.org são claros. À medida que os agentes de IA se tornam um canal de transações e descoberta, os sites com Tool Contracts bem definidos serão mais fáceis e baratos para os agentes usarem, criando uma vantagem natural parecida com a que os primeiros a adotar dados estruturados tiveram nas buscas.

Conclusão

Durante trinta anos, a web foi um lugar projetado para olhos e mãos humanos. Cada página, cada botão, cada formulário pressupõe que há uma pessoa do outro lado. O WebMCP é o primeiro esforço sério, com respaldo de um padrão oficial, para tornar a web nativamente compreensível e acionável por agentes de IA, sem tirar as pessoas do circuito.

Ainda é cedo. A especificação está em rascunho. O suporte dos navegadores é experimental. Mas a base é sólida: duas das maiores fabricantes de navegadores do mundo colaborando por meio do W3C, uma implementação funcional já disponível para testes e uma experiência para desenvolvedores simples o bastante para que a maioria dos sites possa começar com dois atributos HTML.

As empresas que perceberam cedo a importância dos dados estruturados ganharam anos de vantagem competitiva nas buscas. A mesma janela está se abrindo agora com o WebMCP, e ela não vai ficar aberta para sempre.