O que um proxy web precisa mudar antes de registrar uma ferramenta WebMCP

Eu construí o TrickyBird, um proxy da web, então não sou neutro aqui. Esta é uma nota de construção sobre a parte que veio antes da ferramenta: o que tivemos que desligar primeiro.

O WebMCP permite que uma página dê ao agente do navegador uma função real em vez de um DOM para adivinhar. Você chama document.modelContext.registerTool({ name, description, inputSchema, execute }), e o agente pode listar a ferramenta e chamá-la. O recurso está por trás de uma Política de Permissões cujo padrão é self. Em um site normal, esse padrão faz a isolação por você: um frame de anúncio é uma origem diferente, então não pode registrar nada na sua página.

Um proxy quebra esse padrão. Cada frame em uma página proxy vem da nossa origem (a página e seus anúncios igualmente), então self cobre todos eles. Um frame que pertence a qualquer site que o leitor abriu poderia registrar uma ferramenta, e o agente a chamaria dentro da sessão daquele leitor. Portanto, a primeira mudança do WebMCP que fizemos foi uma recusa. O gateway envia tools=() no cabeçalho Permissions-Policy de cada documento que serve. Com o WebMCP ativado por uma flag, registerTool em uma página proxy rejeita com NotAllowedError, e assim faz uma chamada de um novo frame about:blank que a página constrói, que é exatamente o frame que a origem colapsada deixaria entrar. Ambos medidos no Chrome 152. Além do cabeçalho, nosso shim injetado deleta document.modelContext de páginas proxy, então na produção hoje um site que verifica a API não encontra nada, em vez de uma API que responde a cada chamada com uma recusa. O cabeçalho permanece a verdadeira aplicação; um reino que o shim nunca alcança ainda herda isso.

Então a ferramenta. Ela vive na nossa própria página inicial, que não serve o HTML de ninguém além do nosso. Há uma, open_site. Ela recebe um endereço, executa a mesma verificação que o próprio formulário da página executa, e a aba navega para a página proxy. Dê a ela uma frase que não seja um site e ela recusa. Ela nunca pesquisa.

Uma coisa que eu errei no primeiro dia, caso você envie a mesma forma. O rascunho diz que registerTool retorna uma promessa, e nosso hook foi escrito para isso: registerTool(...).catch(() => {}), então retorna a limpeza. Nem toda implementação concorda. Em algumas versões do Chrome OS e Edge, a chamada retornou undefined, .catch lançou dentro do efeito antes que a limpeza existisse, e a próxima montagem da página levantou InvalidStateError: Duplicate tool name. A correção é uma linha de forma: Promise.resolve(registerTool(...)).catch(() => {}) dentro de um try. Uma rejeição, um lançamento síncrono e um undefined nu agora se resolvem da mesma maneira, e a limpeza é sempre retornada.

Duas coisas que você pode verificar por conta própria. O Lighthouse 13.4.1 tem uma categoria de navegação agente. Nossa página inicial pontua 1 lá, o mesmo que antes da ferramenta, e as duas auditorias que a ferramenta adiciona mostram o que deveriam: a tabela de registro lista open_site, e a validade do esquema pontua 1. E o Chrome 152 lista open_site em trickybird.com.

O que eu espero disso? Quase nada, por enquanto. O único consumidor hoje é o navegador desktop do ChatGPT, e nenhum de seus agentes de usuário apareceu em nosso próprio tráfego. Ele não precisa se identificar, então isso pode significar menos do que parece.