WebMCP: Tornando Seu Site Usável por Agentes de IA

Há algum tempo, escrevi sobre configurar este site para descoberta por IA: espelhos de Markdown bruto, llms.txt, uma postura de IA em robots.txt. Tudo isso é sobre tornar um site legível. Um agente busca sua prosa de forma barata, resume e segue em frente. O agente lê, mas não pode fazer nada na sua página.

WebMCP é a outra metade. Em vez de entregar ao agente seu texto para ler, você entrega um conjunto de funções tipadas para chamar: pesquisar suas postagens, filtrar uma lista de produtos, enviar um formulário. A página declara o que pode fazer, e um agente de IA rodando no navegador invoca essas ações diretamente.

É cedo e experimental, apenas para Chromium, atrás de uma flag, e a especificação muda quase semanalmente. Mas é a primeira tentativa séria de responder "como faço para que meu site seja utilizável por agentes, não apenas legível para eles", então vale a pena entender agora.

O que é WebMCP?

WebMCP é uma API web proposta que permite que uma página exponha ferramentas estruturadas a um agente de IA: funções JavaScript, cada uma com uma descrição em linguagem natural e um JSON Schema para seus parâmetros, que um agente no navegador pode descobrir e chamar. Nas palavras do próprio Chrome, é "um padrão web proposto para ajudá-lo a construir e expor ferramentas estruturadas para agentes de IA."

O nome é a pista. É o Protocolo de Contexto de Modelo adaptado para o navegador. Um servidor MCP normal é um processo de backend separado que anuncia ferramentas a um modelo por meio de um protocolo. O WebMCP pega esse mesmo modelo de ferramenta, nome, descrição, esquema de entrada e um payload de resultado, e o move para a própria página. Sua página se torna, na verdade, um servidor MCP do lado do cliente. As ferramentas são definidas e executadas no seu próprio contexto JavaScript, reutilizando a sessão na qual o usuário já está logado. Sem backend extra, sem handshake de autenticação separado.

Por que não apenas deixar o agente ler a página?

Porque ler uma página para agir sobre ela é caro e frágil. Hoje, um agente que deseja clicar em um botão baixa seu DOM, talvez tira uma captura de tela da página, infere qual elemento é o controle "adicionar ao carrinho" e calcula onde clicar. Isso consome tokens, adiciona latência e quebra no momento em que um layout muda ou um anúncio carrega tarde. Você está pedindo a um modelo para reverter a engenharia de uma interface que foi construída para olhos e um mouse.

WebMCP substitui essa suposição por um contrato explícito. A página diz "aqui está uma ferramenta search_posts, ela leva um tag, aqui está o que ela retorna," e o agente a chama como uma função. É a diferença entre raspar um formulário e receber sua API.

Ele também preenche uma lacuna que as ferramentas de descoberta não fazem:

llms.txt informa a um agente o que você escreveu. Um servidor MCP remoto expõe ações, mas vive em sua própria infraestrutura com sua própria história de OAuth. O WebMCP é a opção na página: ações que rodam na aba que o usuário já tem aberta, com a autenticação que ele já possui.

Como é a API?

Você registra ferramentas em document.modelContext. Cada chamada define uma ferramenta com quatro chaves: um name, uma description que o agente lê para decidir quando usá-la, um inputSchema (JSON Schema) para os argumentos e uma função execute assíncrona que faz o trabalho.

await document.modelContext.registerTool({
  name: "search_posts",
  description: "Pesquisar postagens de blog por tag. Retorna títulos e URLs correspondentes.",
  inputSchema: {
    type: "object",
    properties: {
      tag: { type: "string", description: "Uma única tag em minúsculas, por exemplo, 'webdev'" },
    },
    required: ["tag"],
  },
  execute: async ({ tag }) => {
    const posts = await findPostsByTag(tag);
    return `Encontrados ${posts.length} posts marcados como ${tag}.`;
  },
});

Esse exemplo retorna uma string simples, que a documentação da API imperativa aceita. A especificação na verdade tipa o retorno como any, então uma string está bem, mas se você quiser corresponder ao que uma ferramenta MCP regular retorna, você retornaria um { content: [{ type: "text", text: "…" }] } object. O WebMCP reflete essa convenção sem impor. As ferramentas são registradas uma a uma, e um evento toolchange é acionado sempre que o conjunto muda, para que outros frames possam reagir quando você adicionar ou remover uma ferramenta.

Uma armadilha se você seguir tutoriais mais antigos: o ponto de entrada costumava ser navigator.modelContext. Isso está descontinuado a partir do Chrome 150 em favor de document.modelContext. Escreva o novo; muitos dos primeiros textos ainda mostram a superfície antiga.

Há também um sabor declarativo onde você anota elementos <form> existentes e o Chrome os expõe automaticamente como ferramentas. O Chrome documenta isso, mas a especificação em si ainda não a definiu, sua seção está literalmente marcada como um TODO.