WebMCP em outubro de 2026: como tornar um site utilizável por agentes de IA e o que o origin trial significa na realidade

O WebMCP permite a uma página web entregar a um agente de IA uma lista curta de coisas que ele pode fazer, cada uma com um nome, uma descrição e um esquema de entrada, em vez de deixar o agente descobrir a página a partir de capturas de ecrã e do DOM. Um agente que encontre uma ferramenta check_order_status pode chamá-la com um número de encomenda. Sem ela, o agente tem de encontrar o campo certo e clicar no botão certo.

Essa é a promessa. A situação a 22 de outubro de 2026 é mais limitada do que a maioria dos textos sugere. O WebMCP é uma proposta de um Community Group do W3C, não uma norma. O Chrome disponibiliza-o como origin trial, sem decisão ainda de o lançar. Há um único agente de consumo a chamar as ferramentas (o navegador integrado na app do ChatGPT para computador), e esse agente ignora a versão declarativa, baseada em formulários, que foi retirada da especificação a 8 de outubro. A equipa do motor do Safari opõe-se à proposta; a Mozilla é neutra.

Este artigo destina-se a programadores e responsáveis de produto que estão a decidir se devem acrescentar o WebMCP agora. Explica o que é a API, quem a chama, como ativá-la para visitantes reais, como escrever ferramentas que não entreguem a um agente uma arma carregada e o que corrigir primeiro se quiser que os agentes usem de todo o seu site.

O que é o WebMCP

A especificação define uma API JavaScript em document.modelContext, através da qual uma página regista ferramentas: «A API WebMCP permite que as aplicações web ofereçam aos agentes de IA ferramentas baseadas em JavaScript.» Uma ferramenta tem um name, uma description e uma função de retorno execute e, opcionalmente, um title, um inputSchema (JSON Schema) e annotations. O código da própria página é executado quando o agente chama a ferramenta, com a sessão do utilizador.

Há três coisas fáceis de interpretar mal:

• Não é uma norma. O documento é um Draft Community Group Report do Web Machine Learning Community Group e di-lo: «Não é uma Norma do W3C, nem se encontra na Standards Track do W3C.» A própria documentação do Chrome chama-lhe «uma proposta de norma web». A data do relatório tem mudado de poucos em poucos dias em outubro; os seus editores são da Microsoft e da Google.
• Não há MCP lá dentro. A especificação diz que as páginas que a usam «podem ser vistas como servidores Model Context Protocol que implementam ferramentas em script do lado do cliente» e, a seguir, que «não prescreve o formato em que as ferramentas são expostas ao agente do navegador». A análise da Mozilla foi direta: «O nome induz em erro ... Aqui não há MCP nenhum.» Uma ferramenta WebMCP não se liga ao seu servidor MCP de backend e não o substitui.
• Não o torna descobrível. A documentação do Chrome indica a limitação: «Os clientes e os navegadores têm de visitar diretamente um site para saber se tem ferramentas que possam ser chamadas.» O WebMCP ajuda um agente que já está na sua página. Não faz nada para que o encontrem.

A API está limitada a contextos seguros e controlada por uma Permissions Policy tools cuja lista de origens permitidas por omissão é 'self', pelo que uma iframe de outra origem não consegue registar ferramentas, a menos que a página que a incorpora o permita.

Onde está a situação a 22 de outubro de 2026

O Chrome 156, a última versão da janela original do ensaio, chegou ao canal estável a 20 de outubro de 2026. O Chrome 162, o fim da extensão pedida, tem o canal estável previsto para 2 de fevereiro de 2027. Não foi possível confirmar na consola do ensaio se a extensão está ativa, por isso planeie como se fosse provável, mas não certa.

O pedido de extensão explica por que razão o Chrome quer mais tempo: «O feedback do OT sugeriu melhorias à API, que estamos a implementar.» No mesmo fio de discussão, Dominic Farolino, da Google, escreveu que a equipa está «a contar passar para o I2S dentro da janela da extensão», ou seja, pedir autorização para lançar, e que «A API imperativa é muito mais popular do que a declarativa, por isso estamos a investir mais nela em resposta às necessidades dos utilizadores.» Mencionou também uma API de continuação, uma API de estabilidade das ferramentas e limites ao tamanho das ferramentas, em fase de protótipo. A API em que escreve hoje vai mudar.

Quem chama realmente as ferramentas

Registar ferramentas não exige nada. Usá-las exige um agente, e a lista de agentes é curta.

As extensões de teste do próprio Chrome. A documentação do Chrome oferece duas extensões, entre as quais o Model Context Tool Inspector, para experimentar ferramentas em demonstrações e nas suas próprias páginas. Precisam de uma chave de API de um modelo seu, e o Chrome faz notar: «Estas extensões são independentes do Gemini no Chrome.» São ferramentas de programador, não clientes.

O navegador integrado no ChatGPT. Uma publicação de um membro da equipa da OpenAI no seu fórum de programadores disse, a 25 de agosto de 2026, que «As site tools são a implementação do ChatGPT da proposta de norma WebMCP.» A sua documentação impõe condições: modelos específicos, a versão mais recente da app para computador, um administrador que o permita nos espaços de trabalho Enterprise, nenhum suporte para espaços de trabalho Edu e «A disponibilidade depende também da implementação gradual». Indica ainda o que não suporta: «API declarativa: as ferramentas definidas através de atributos de formulários HTML não estão disponíveis como site tools», e as ferramentas registadas dentro de iframes, mesmo da mesma origem. A instrução da OpenAI é clara: «Use JavaScript para registar ferramentas na página de nível superior». A documentação não diz se uma página precisa de um token do origin trial do Chrome para que o ChatGPT veja as suas ferramentas.

O Gemini no Chrome. A Google disse em maio que «em breve suportará as APIs WebMCP». Não encontrámos nenhuma fonte primária posterior a dizer que suporta. Não construa já um plano sobre isso.

Todos os outros recorrem ao método antigo. Todos os agentes de todos os navegadores continuam a ler as páginas da forma antiga. O Chrome di-lo na sua própria avaliação de riscos: «Os agentes de navegador no Chrome podem continuar a atuar sobre os sites como antes, simulando comportamentos do utilizador.» A OpenAI: «Se não houver nenhuma ferramenta adequada, o agente pode ainda assim recorrer às suas capacidades normais de navegação.» Um site sem WebMCP não é invisível para os agentes. Um site com botões avariados e campos sem etiqueta é difícil para todos eles.

A API imperativa

Esta é a versão que a especificação define, a que o ChatGPT suporta e a que o Chrome diz que os programadores preferem. Uma ferramenta envolve lógica que a página já tem. Eis uma consulta só de leitura para um cliente com sessão iniciada, seguindo a estrutura da documentação do Chrome e a deteção de funcionalidades da OpenAI:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

O que importa nele:

• O nome, a descrição e o esquema são o que o modelo lê. O Chrome recomenda no máximo 500 carateres por descrição de ferramenta, 150 por descrição de parâmetro, 30 por nome de ferramenta e de parâmetro e 1,5 mil carateres por resultado de ferramenta, e faz notar que «Estas recomendações estão sujeitas a alteração». O documento explicativo da especificação avisa que «Expor demasiadas ferramentas (por exemplo, dezenas ou centenas) pode degradar gravemente o desempenho do agente»: registe o que o estado atual da página exige e retire o resto com o sinal do AbortController.
• O segundo argumento de execute traz um AbortSignal, para que uma chamada cancelada possa interromper um pedido em curso.
• As anotações são indicações. readOnlyHint marca uma consulta. consequentialHint marca tudo o que reserva, compra, envia, apaga ou transfere, e a documentação do Chrome diz que «permite que os agentes e os navegadores imponham pedidos de confirmação obrigatória ao utilizador». untrustedContentHint marca resultados que contêm avaliações, conteúdo de utilizadores ou dados de terceiros. Existe uma anotação debugging desde o Chrome 156.
• O código da página também pode listar e executar ferramentas, com document.modelContext.getTools() e executeTool(), e um evento toolchange é disparado quando a lista muda. Os argumentos convertidos em cadeia JSON para executeTool() estão obsoletos desde o Chrome 155.

O React, o Angular e o Vue têm cada um auxiliares experimentais, e o pacote npm webmcp-types fornece tipagens TypeScript. Os tutoriais mais antigos que chamam navigator.modelContext estão desatualizados: a especificação passou a API para document a 27 de maio de 2026.

A API declarativa: no ensaio do Chrome, fora da especificação

A versão declarativa transforma um formulário HTML existente numa ferramenta com dois atributos. É atraente para sites antigos e cheios de formulários, porque não é preciso mudar mais nada:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

No ensaio do Chrome, «Quando um agente chama toolname, o navegador coloca o formulário em foco e preenche os respetivos campos. O formulário continua visível para o utilizador.» O navegador constrói os parâmetros a partir dos controlos: os seus nomes, as suas <label>, required e as opções de um <select>. A menos que o formulário tenha toolautosubmit, «O utilizador tem de clicar manualmente em Submeter para concluir a tarefa», que é o que se quer em tudo o que registe uma encomenda ou envie um contacto comercial. SubmitEvent.agentInvoked diz ao seu tratador que um agente preencheu o formulário, e respondWith(), depois de preventDefault(), devolve o resultado ao agente. Escute os eventos toolactivated e toolcancel em document.modelContext com addEventListener: window.ontoolactivated e window.ontoolcancel deixam de ser suportados a partir do Chrome 156.

O problema é o seu estado. A alteração mais recente do documento explicativo, a 8 de outubro de 2026, intitula-se «Remove declarative API from the spec for now» e diz agora que uma contrapartida declarativa «está a ser explorada em separado ... mas não faz parte da especificação neste momento.» O ChatGPT não a suporta. O Chrome continua a documentá-la no ensaio, e Farolino, da Google, defendeu no fio da Mozilla que «vemos valor na proposta declarativa simplesmente pelos sites antigos, sobretudo os baseados em formulários». Trate-a como uma experiência do Chrome dentro de uma experiência: pode experimentar, mas não é sensato que seja o seu único caminho.

Ativá-lo para visitantes reais

Uma flag (chrome://flags/#enable-webmcp-testing) ativa o WebMCP no seu próprio navegador para testes. Não faz nada pelos visitantes. Para eles, a página precisa de um token de origin trial.

1. Registe a origem na página do ensaio WebMCP do Chrome. Os origin trials «são públicos e estão abertos a todos os programadores», e um token «ativa uma funcionalidade para todos os utilizadores da sua origem».
2. Sirva o token em todas as páginas que devam expor ferramentas, como <meta http-equiv="origin-trial" content="..."> no <head> ou como cabeçalho de resposta Origin-Trial:. Um token também pode ser injetado a partir de um script. Um token cobre uma origem; uma página pode ter vários.
3. Renove-o. Quando um ensaio é prolongado, o Chrome pede aos registados que «forneçam um novo token para cada origem inscrita no ensaio», e «o Chrome ignora tokens inválidos ou expirados». Um token expirado falha em silêncio: as ferramentas simplesmente deixam de aparecer.
4. Para o Edge, registe-se em separado na página do ensaio do Edge. Os seus termos pedem que «Sempre que possível, concorde em aplicar a deteção de funcionalidades / degradação graciosa».

As auditorias WebMCP do Lighthouse também precisam do registo no ensaio, pelo que um site que as teste sem token as verá falhar.

Escrever ferramentas seguras de chamar

A secção de segurança da especificação é não normativa e é franca sobre onde está o encargo: impedir que um agente seja manipulado «é sobretudo da responsabilidade do próprio modelo de segurança do agente e não algo que esta especificação possa impor de forma normativa.» As suas ferramentas decidem, ainda assim, quanto dano um agente manipulado pode fazer.

• As indicações podem mentir, por isso os agentes não confiarão nelas. A especificação: «um site malicioso pode omitir ou deturpar essas indicações.» A OpenAI: «O nome de uma ferramenta, ou a alegação de que só lê dados, não é prova do que ela faz», e cada chamada no seu navegador passa por uma revisão de segurança, continuando a exigir-se confirmação para compras e ações semelhantes. Anote com honestidade, de qualquer modo. É o que um agente cuidadoso usa para decidir quando perguntar ao utilizador.
• Descreva os efeitos com exatidão. O mau exemplo da própria especificação é uma ferramenta descrita como «Finaliza o carrinho de compras atual» que «na verdade desencadeia uma compra. O utilizador não tinha a intenção de comprar nada.» Se uma ferramenta debita um cartão, a descrição di-lo e consequentialHint é true.
• Autorize no servidor, sempre. A ferramenta corre com a sessão do utilizador: a especificação nota que «Os agentes conseguem herdar a identidade do utilizador e o contexto de autenticação do navegador.» Uma chamada de ferramenta é um pedido desse utilizador e sofre as mesmas verificações. O conselho do documento explicativo mantém-se: «Valide de forma estrita no código, de forma permissiva no esquema», porque falhas estritas do esquema podem fazer os agentes bloquear.
• Conte com a injeção de prompts. A especificação põe-na em primeiro lugar, em três formas: instruções escondidas nos metadados da ferramenta, no resultado da ferramenta e ataques que usam as ferramentas como alvos. O resultado que contém texto escrito por outras pessoas (avaliações, mensagens, perguntas sobre produtos) deve ficar sob untrustedContentHint e ser devolvido como dados, não como prosa que um agente possa tomar por instruções.
• Exclua páginas de forma deliberada. Um cabeçalho Permissions-Policy: tools=() torna a API indisponível para um documento e para tudo o que ele incorpora. As definições da conta, as páginas de pagamento e os ecrãs de administração são candidatos.

Uma ressalva sobre a documentação do Chrome: a sua página de segurança diz que o draft inclui um método requestUserInteraction() para pedir algo ao utilizador a meio de uma ferramenta. O draft da especificação de 20 de outubro de 2026 não tem esse método, e o documento explicativo continua a listar a confirmação do utilizador como questão em aberto. Não desenhe nada em torno dele.

A que se opõem os engenheiros do Safari e do Firefox

Vale a pena ler as objeções mesmo que só desenvolva para o Chrome, porque descrevem como o WebMCP pode correr mal na prática.

A posição do WebKit, publicada a 3 de junho de 2026, defende que as páginas difíceis de usar devem ser corrigidas em HTML e ARIA, «onde o utilizador, a tecnologia de apoio e os agentes beneficiam todos», e que, com ferramentas, «a fragilidade limita-se a passar do DOM para as descrições das ferramentas.» Trata um agente como tecnologia de apoio que não deve ser singularizada: «O WebMCP faz o contrário, tornando “um agente está ao volante” um facto observável.» E nota que a proposta «não tem nenhum modelo de consentimento ou de reversibilidade para ações com consequências».

A Mozilla fixou-se na neutralidade em agosto: o WebMCP «introduz uma abstração potencialmente valiosa», mas «abre uma superfície cuja dinâmica no mundo real deixa demasiadas questões em aberto para um apoio sem reservas». Avisa que os sites poderiam «oferecer ferramentas que não correspondem à experiência de um utilizador na página», por exemplo para «fornecer injeção de prompts que é invisível para os utilizadores típicos». Alguns engenheiros da Mozilla a título individual mostraram interesse numa primitiva imperativa de chamada de funções; isso não é um apoio da Mozilla.

O próprio Chrome avalia como baixo, para os utilizadores, o risco de outros motores não adotarem o WebMCP. O reverso disso é que um site não ganha nada no Safari nem no Firefox por acrescentar hoje ferramentas.

O que funciona hoje para todos os agentes

Todos os agentes de navegador leem capturas de ecrã, HTML e a árvore de acessibilidade. A orientação da web.dev da Google sobre sites amigos dos agentes diz que os agentes «usam o DOM e a árvore de acessibilidade para obter uma lista limpa e estruturada de elementos interativos e, depois, cruzam-na com uma representação visual». A sua lista prática é curta:

• Use elementos <button> e <a> a sério, não <div> e <span> clicáveis.
• Ligue cada <label> ao respetivo campo com for.
• Sem sobreposições transparentes por cima de elementos interativos e nada de interativo com menos de 8 píxeis quadrados.
• Uma disposição estável, que não se desloque quando o agente está prestes a clicar.

A sua conclusão: «Tudo o que sugerimos para tornar um site “preparado para agentes” também torna os sites melhores para as pessoas.» É também, quase palavra por palavra, o que o WebKit pede em vez do WebMCP. Se o seu checkout falha numa auditoria de acessibilidade, corrija isso antes de escrever uma única ferramenta.

O Lighthouse tem uma categoria Agentic Browsing desde a versão 13.2.0 (1 de maio de 2026), disponível no Chrome a partir da versão 150, e ativada para a API do PageSpeed Insights no Lighthouse 13.4.1 (20 de julho de 2026). Verifica o subconjunto de auditorias de acessibilidade que importam às máquinas, a estabilidade da disposição, as ferramentas WebMCP registadas e os formulários sem elas, a validade do esquema e a presença de um ficheiro llms.txt. O Chrome descreve-a como «informativa e sem referências de comparação»: não há pontuação de 0 a 100. Quanto ao llms.txt, a orientação da própria Pesquisa Google é que ignora esses ficheiros: acrescentar um «não prejudicará nem ajudará a visibilidade ou a classificação do seu site na Pesquisa Google». O facto de o Lighthouse verificar o ficheiro não muda isso.

Deve acrescentar o WebMCP agora?

No Shopify com um tema Liquid: não há trabalho nenhum. As ferramentas de loja, de carrinho e de checkout da Shopify já estão ativas, «Não há nada para instalar ou configurar», com a ressalva da própria Shopify de que «o suporte para agentes está atualmente limitado a navegadores baseados em Chromium através de um origin trial». As lojas headless só estão abrangidas na pré-visualização para programadores do Hydrogen. Não encontrámos nenhuma outra plataforma de comércio, fornecedor de pagamentos ou CDN que ative o WebMCP para os seus clientes.

Num site à medida, headless ou legado: depende de quem são os seus utilizadores.

• Se os seus clientes ou colaboradores usam o navegador da app do ChatGPT para computador, as ferramentas imperativas na página de nível superior são o único tipo que chega até eles. Comece por duas ou três ferramentas só de leitura em torno da tarefa mais comum (estado de uma encomenda, disponibilidade, um orçamento), atrás de deteção de funcionalidades, com um token de origin trial, e meça se alguém as chama.
• Se quer experimentar a baixo custo no Chrome, os atributos declarativos em formulários existentes são questão de umas horas de trabalho. Não fique por aí: o ChatGPT não os verá e a especificação já não os contém.
• Se não tem provas de que os agentes o visitam, corrija primeiro a semântica, as etiquetas e a disposição. Esse trabalho ajuda todos os agentes e todas as pessoas que usam tecnologias de apoio, e nada nele será deitado fora quando a API mudar.

Em qualquer caso, mantenha a interface normal completa. O conselho da OpenAI: «Preserve a interface normal para as pessoas e para os navegadores que não suportam o WebMCP.»

O que pode mudar

• Um Intent to Ship. A equipa do Chrome espera pedi-lo dentro da janela da extensão, que termina com o Chrome 162 (2 de fevereiro de 2027), se a extensão se mantiver. Um lançamento dispensaria os tokens no Chrome.
• A forma da API. Estão em protótipo uma API de continuação (resultados que chegam à página seguinte após uma navegação), uma API de estabilidade das ferramentas e limites de tamanho. As versões recentes já removeram window.ontoolactivated e os argumentos convertidos em cadeia.
• O destino da API declarativa. Fora da especificação «por agora», ainda no ensaio do Chrome.
• Quem chama. O suporte do Gemini no Chrome foi anunciado, mas não lançado. A página de estado de implementação da especificação indica o WebMCP para aplicações web nos óculos Ray-Ban Display da Meta como «em breve» e o suporte experimental no assistente Leo do Brave.

Se acrescentar ferramentas agora, mantenha-as num só módulo, atrás de deteção de funcionalidades, para que a mudança seguinte seja uma única edição.

Onde obter ajuda

Desenvolvemos as partes de um site e do seu backend em que os agentes tocam: ferramentas que envolvem a lógica existente de encomendas, reservas e contas, uma autorização que trata a chamada de um agente como qualquer outro pedido desse utilizador e as correções de semântica e de acessibilidade que tornam um site utilizável antes de existir qualquer ferramenta. O nosso serviço de desenvolvimento de agentes de IA e integração de servidores MCP abrange tanto ferramentas WebMCP como servidores MCP de backend, que são coisas diferentes, apesar do nome.

Se quer saber o que um agente vê hoje no seu site e se as ferramentas fariam diferença para os seus clientes, escreva para office@c9group.dev.