Este guia mostra o que a especificação diz, o problema que ela tenta resolver, em que estágio de padronização ela realmente está (com posições públicas divergentes entre fabricantes de navegador), a diferença entre isso e o protocolo que já existe do lado do servidor, e o que muda para quem publica conteúdo.
O que é WebMCP?
É uma proposta de interface do navegador para que uma página declare ferramentas: funções nomeadas, com descrição e parâmetros, que um agente de IA pode chamar.
Hoje, quando um assistente precisa fazer algo num site, ele opera a tela: encontra o campo, digita, acha o botão, clica. É lento, quebra quando o layout muda e depende de o agente interpretar a interface corretamente.
Com WebMCP, o site diz o que sabe fazer. Em vez de o agente adivinhar que aquele formulário é uma busca de voo, a página declara uma função de buscar voo, com os parâmetros que ela aceita. O agente chama.
A proposta foi publicada em 13 de agosto de 2025, por engenheiros da Microsoft e do Google.
Que problema ele resolve?
O documento original nomeia três, e os três valem para quem opera um site:
1. Desintermediação da interface. Quando a integração acontece direto entre o agente e o backend do serviço, a sua página é contornada: o agente resolve a tarefa sem passar pela experiência que você construiu no navegador.
2. Replicar estado e autenticação num servidor separado. A alternativa que existe hoje para expor funções a agentes é construir um serviço à parte, que precisa saber quem é o usuário e em que ponto da navegação ele está. Isso é duplicar o que a página já tem.
3. Custo de escrever um backend para expor função que já existe no navegador. A lógica de "adicionar ao carrinho" já roda no seu site. Reescrevê-la num serviço externo só para um agente poder chamá-la é trabalho repetido.
Os três são problemas de quem já tem um site funcionando e quer que um agente consiga usá-lo sem reconstruir tudo.
Em que estágio de padronização está?
Aqui está o ponto que as fontes secundárias erram com mais frequência, e ele muda o quanto você precisa se mexer.
Não é um padrão do W3C. O documento é um "Draft Community Group Report" de um grupo comunitário, e o próprio texto da especificação diz, literalmente, que não é um padrão do W3C nem está na trilha de padronização do W3C.
Grupo comunitário não integra a trilha de Recomendação do W3C: qualquer pessoa pode criar um, e o que sai dali não tem status normativo. Quem escreve "novo padrão do W3C para agentes" está descrevendo algo que não existe.
E as posições públicas dos fabricantes de navegador divergem:
Fabricante | Posição formal | Implementação |
|---|---|---|
Chrome | propôs a API | teste de origem, no Chrome 149 |
Edge | propôs a API | teste de origem, no Edge 150 |
Mozilla | neutra | não implementa |
Apple (WebKit) | contra, por escrito | não implementa |
Fonte: registros públicos de posição de fabricante (Mozilla, posição neutra registrada em 28/05/2026; WebKit, posição contrária registrada em 03/06/2026) e o arquivo de status de implementação do repositório da proposta, que lista versões e não traz prazos. Consultados em 15/09/2026.
A posição da Apple merece atenção porque o argumento é bom: para eles, um agente que opera um site é tecnologia assistiva, e o lugar certo de resolver isso é o próprio HTML e as marcações de acessibilidade, que já existem para descrever o que um elemento faz. Em junho de 2026 eles chegaram a sugerir tirar a proposta do foro em que ela está.
Se o argumento da Apple prevalecer, o investimento em acessibilidade vira o investimento em legibilidade por agente, e não haverá uma camada separada para manter.
Não há cronograma. Não há data prevista para padronização, e o próprio teste de origem no Chrome está sem prazo de encerramento declarado.
Qual a diferença para o protocolo do lado do servidor?
A especificação resolve essa confusão numa frase.
Já existe um protocolo anterior a este, o Model Context Protocol (MCP), criado pela Anthropic, para um programa expor ferramentas a modelos de IA. É dele que vem o "MCP" do nome da proposta. Ele roda no servidor: você sobe um serviço que declara funções, e o assistente se conecta a ele.
Sobre a relação entre os dois, a especificação diz que páginas com WebMCP "podem ser pensadas como servidores desse protocolo que implementam ferramentas em script do lado do cliente, em vez de no backend". E o documento de justificativa lista, como não-objetivo explícito, substituir o MCP.
Traduzindo a fronteira:
Onde roda | Para quê | |
|---|---|---|
MCP, no servidor | num serviço seu, separado | expor dados e funções a um assistente, independentemente de alguém estar navegando |
WebMCP | na própria página, no navegador | deixar o agente usar o site enquanto a pessoa está nele, com a sessão e o login que já existem |
A diferença prática é a sessão. O de servidor precisa saber quem é o usuário; o WebMCP herda isso da aba aberta.
Como isso se parece na prática?
A forma da declaração, sem entrar em código, explica os limites.
A página registra uma ferramenta: um nome, uma descrição em texto do que ela faz, e a lista de parâmetros que aceita, com o tipo de cada um. Quando o agente decide usar aquela função, ele chama com os valores, e a própria página executa o que já executaria se a pessoa tivesse clicado.
Três consequências que saem dessa forma:
A descrição em texto é a interface. O agente escolhe a ferramenta lendo a descrição, então ela cumpre um papel parecido com o do texto-âncora de um link: precisa dizer o que acontece, não o que o botão se chama internamente. É trabalho de redação, não de programação.
A ferramenta herda o que a aba tem. Login, carrinho, idioma, etapa do formulário. É justamente isso que diferencia a proposta de um serviço externo, e é também o que torna a questão de segurança séria: uma função declarada é uma função que um agente pode chamar em nome de alguém que está logado.
O que não estiver declarado continua invisível como função. O agente não infere: ou a página declara, ou ele volta a operar a tela.
O que muda para SEO?
Aqui é preciso separar com rigor o que está documentado do que é especulação de mercado, porque neste tema a segunda categoria aparece muito mais.
O que está documentado
Não existe índice de ferramentas. A documentação do Chrome afirma que clientes e navegadores precisam visitar o site diretamente para saber se ele tem ferramentas chamáveis.
Essa frase carrega a consequência que mais afeta o seu trabalho: ser encontrado continua sendo o pré-requisito. Não há um diretório onde um agente descubra que o seu site expõe uma função. Ele precisa chegar até você primeiro, e como ele chega é o mesmo problema de sempre.
Não adotar não bloqueia nada. Se o site não declara ferramentas, o agente cai de volta na automação genérica: opera a tela como já operava. O explainer descreve esse retorno à automação genérica sem qualificar desempenho; a perda de velocidade e de estabilidade é leitura nossa, e não do documento.
O que é especulação
Tudo que liga WebMCP a posição em resultado de busca. Não há documentação de nenhum buscador dizendo que declarar ferramentas influencia ranqueamento, e a proposta sequer é padrão. Quem já vende "otimização para WebMCP" está vendendo otimização para algo cuja especificação a Apple pediu para mudar de foro.
O guia de generative engine optimization trata do que tem evidência hoje sobre aparecer em respostas de IA, e o de llms.txt trata de outra proposta recente da mesma família, que também vale acompanhar sem correr.
Vale fazer alguma coisa agora?
Para um site comum, acompanhar, não implementar. Três razões concretas:
- A proposta não é padrão: os dois navegadores que a testam são os das empresas que a escreveram, e dos outros dois um é neutro e um é contra, por escrito.
- Não existe cronograma.
- Não adotar não bloqueia nada.
O que vale fazer, e vale de qualquer forma:
Investir em acessibilidade e em HTML semântico. É a aposta que ganha nos dois cenários: se a proposta avançar, o seu site está mais fácil de descrever; se o argumento da Apple prevalecer, era exatamente ali que estava a resposta.
Garantir que o conteúdo é rastreável e que as funções principais têm URL própria. Como não há índice de ferramentas, o agente precisa chegar ao site, e isso é SEO técnico comum.
Não reescrever nada. Se alguém propuser um projeto de adoção agora, a pergunta que resolve é: qual usuário deixa de conseguir fazer o quê, hoje, sem isso? A resposta documentada é nenhum.
Conclusão
WebMCP é uma proposta para que a página declare funções chamáveis por agentes, publicada em agosto de 2025 por engenheiros de duas grandes empresas. Ela não é padrão, tem oposição escrita de um fabricante de navegador, não tem cronograma, e não adotar não impede nada.
O próximo passo não é implementar. É olhar o seu site e responder uma pergunta que vale independentemente do futuro desta proposta: as ações principais que uma pessoa faz ali têm HTML que diz o que elas são, ou só parecem clicáveis porque o CSS diz que parecem? Essa resposta melhora acessibilidade, melhora rastreamento e, se a proposta vingar, encurta o caminho.
