O Trial de Origem do WebMCP: provideContext Já Foi Removido

Diga que uma página carrega dois scripts. Um é o helper de checkout que você escreveu; o outro é um terceiro que seu tag de anúncio puxou. Sob a API de rascunho de fevereiro, no momento em que o segundo script executa uma linha, sua ferramenta desaparece silenciosamente.

// API de rascunho antiga — agora removida
navigator.modelContext.provideContext({ tools: [ /* este array substitui tudo */ ] });

provideContext declarava toda a lista de ferramentas de uma vez: "as ferramentas nesta página agora são estas." Conveniente no papel. Mas na web real, onde vários scripts compartilham um documento, substituir tudo é apenas uma tomada de controle. O método não durou seis meses na especificação. Agora que o WebMCP foi lançado como um teste de origem do Chrome 149, a interface que as pessoas foram apresentadas em fevereiro já mudou duas vezes. Este post percorre o que mudou, por que e como escrever o código hoje, tudo de acordo com a documentação oficial.

O que é o WebMCP e por que olhar novamente agora

WebMCP (Protocolo de Contexto de Modelo da Web) é um padrão de navegador que permite que uma página da web exponha suas próprias funcionalidades para agentes de IA como ferramentas chamáveis. O MCP do lado do servidor conectava aplicativos locais e servidores remotos a um agente; o WebMCP move esse ponto de conexão para o navegador, para o próprio documento. Uma página registra ações como "filtrar produtos" ou "adicionar ao carrinho" como ferramentas estruturadas, e um agente conectado ao navegador as invoca por seu esquema. O botão que um humano costumava clicar se torna uma função que o agente invoca.

A ideia não é nova. O Grupo de Trabalho de Aprendizado de Máquina da W3C publicou isso pela primeira vez em 10 de fevereiro de 2026, liderado por engenheiros do Google e da Microsoft, e por volta dessa época eu cobri como o navegador se torna um servidor de ferramentas para o agente em nível conceitual. Isso era um rascunho. Isso não é. A documentação do Chrome agora diz "Participe do teste de origem do WebMCP a partir do Chrome 149" — você pode puxar um token de teste de origem e ativá-lo para um domínio de produção. Sempre que um conceito se torna uma coisa real, o projeto e o resultado construído se afastam em algum lugar. Esse afastamento é o ponto deste post.

Uma pergunta persiste: por que isso tem que estar dentro do navegador? O MCP do lado do servidor já pode entregar ferramentas a um agente. A resposta é estado. Uma sessão de login, um carrinho, as condições de filtro atualmente na tela — essas só existem plenamente dentro da aba do navegador. Para uma ferramenta do servidor alcançar esse estado, você teria que reconstruir autenticação e sincronização separadas. Mas quando a página expõe suas próprias ferramentas, o agente invoca ações na exata sessão em que o usuário já está logado. Nenhum aplicativo local para instalar, nenhuma troca de chave de API separada. Essa propriedade "use o contexto que já está aberto" é a razão de existir do WebMCP — e, como a próxima seção mostra, a raiz de sua tensão de segurança também.

Deixe-me baixar as expectativas desde o início. Um teste de origem não é um padrão finalizado. Ele pode mudar a qualquer momento, e já mudou, duas vezes. Portanto, não memorize o código abaixo como uma API estabelecida. Trate-o como a forma neste momento, uma que pode mudar novamente no próximo trimestre.

Os dois lugares onde o rascunho de fevereiro e a versão lançada divergem

Duas coisas mudaram. Uma é onde a API está; a outra é como você registra uma ferramenta.

Comece com o ponto de entrada. A especificação diz "cada objeto Document tem um ModelContext associado," o que torna document.modelContext canônico. Mas o Chrome de teste de origem inicial o enviou em navigator.modelContext. Os exemplos da API imperativa atual do Chrome usam document.modelContext, e navigator.modelContext está marcado como obsoleto no Chrome 150. Portanto, a especificação e a implementação apontaram para lugares diferentes por um tempo, então a implementação alcançou a especificação. Copie um exemplo de fevereiro literalmente e ele quebra no ponto de entrada.

A mudança de registro é mais importante. provideContext era um modelo de substituição total; registerTool é um modelo de adição única. Essa diferença não é sobre conveniência. É uma consequência do design de segurança.

Como o registerTool realmente se parece

Aqui está a ferramenta que você deve registrar hoje, de acordo com a documentação da API imperativa do Chrome.

const controller = new AbortController();

await document.modelContext.registerTool(
  {
    name: "filter_products",
    description: "Filtrar a lista de produtos por categoria e preço máximo.",
    inputSchema: {
      type: "object",
      properties: {
        category: { type: "string", description: "Categoria do produto" },
        maxPrice: { type: "number", minimum: 0, description: "Limite superior de preço" }
      },
      required: ["category"]
    },
    annotations: {