Agentes que operam sites pela interface visual precisam perceber a página, localizar controles e inferir qual ação produz o resultado desejado. Esse caminho é necessário quando o site só oferece uma interface humana. Ele também é caro: cada etapa pode envolver imagem, estrutura extensa do DOM, tentativa de clique e nova verificação.
O WebMCP propõe outra camada. O rascunho publicado pelo Web Machine Learning Community Group permite que aplicações web registrem ferramentas JavaScript que agentes podem descobrir e executar. Em vez de interpretar um botão e seu entorno, o agente recebe uma capacidade com nome, descrição, parâmetros e resultado.
A mudança parece pequena na API e grande na arquitetura. O site deixa de ser apenas uma superfície para automação e passa a declarar como quer ser operado.
Contratos vencem percepção em tarefas estruturadas
Uma interface visual carrega informação útil para pessoas: posição, hierarquia, cor, texto e feedback. Para um agente que já sabe a intenção, parte disso é ruído. Se a tarefa é adicionar um item ao carrinho, consultar um pedido ou preencher uma preferência, uma função bem definida pode representar a operação com muito menos contexto.
Essa redução não deve ser transformada em promessa universal de economia. O custo depende do modelo, do site, da ferramenta e da tarefa. O próprio padrão define a forma de expor capacidades; ele não garante um percentual fixo de tokens em qualquer fluxo.
O argumento sólido é estrutural. Um esquema compacto tende a exigir menos interpretação do que uma página inteira. Também resiste melhor a mudanças cosméticas. Alterar classes CSS ou mover um botão pode quebrar uma automação visual, enquanto uma ferramenta com contrato estável continua funcionando.
A interface humana continua necessária
WebMCP atende ações que podem ser descritas como operações. Ele não substitui a observação visual quando a decisão depende de composição, legibilidade, confiança ou comparação subjetiva. Um agente pode usar uma ferramenta para enviar dados e ainda precisar olhar a página para confirmar como o resultado foi apresentado.
Também há tarefas exploratórias em que o usuário não sabe qual operação quer. Navegar, ler e formar uma intenção faz parte do trabalho. Expor centenas de funções para cobrir qualquer possibilidade recriaria no catálogo de ferramentas o excesso de contexto que o padrão tenta reduzir.
A divisão mais útil é manter percepção para descobrir e verificar, usando capacidades explícitas para executar operações conhecidas.
O contrato vira uma nova superfície de segurança
Uma ferramenta acessível a agentes precisa dos mesmos controles de qualquer API sensível. Autenticação, autorização, validação de entrada, confirmação de ações irreversíveis e limites de uso continuam obrigatórios. O fato de a chamada acontecer no navegador não torna a operação segura.
Há ainda um problema específico de agência. Uma pessoa pode autorizar um agente a trabalhar no site, mas isso não significa que toda ação deve ocorrer sem revisão. Operações de leitura têm risco diferente de compras, exclusões, mensagens ou alterações de conta. O site precisa expor essa diferença de forma compreensível e preservar confirmação onde o custo do erro é alto.
Descrições de ferramentas também são parte do limite de confiança. Um nome ambíguo ou um parâmetro permissivo pode induzir uso indevido mesmo sem ataque. Contratos menores ajudam a revisar, desde que sejam específicos.
O padrão ainda é trabalho em andamento
Em setembro de 2026, a especificação se apresenta como Draft Community Group Report. Ela declara explicitamente que não é um padrão W3C nem está no Standards Track. Isso muda a decisão de adoção.
Uma equipe pode experimentar em um fluxo isolado, medir custo e aprender sobre o desenho das capacidades. Não deveria transformar o rascunho em dependência central sem considerar mudanças de API, suporte dos navegadores e interoperabilidade entre agentes.
O melhor piloto tem uma ação reversível, um contrato estreito e uma alternativa funcional pela interface existente. Assim, o experimento produz dados sem criar um bloqueio para usuários ou automações atuais.
Como avaliar o ganho real
Compare dois percursos para a mesma tarefa. No primeiro, o agente navega visualmente. No segundo, descobre e chama uma ferramenta WebMCP. Registre tokens, latência, falhas, confirmações e qualidade da verificação final.
O resultado pode revelar que a execução ficou barata, mas a descoberta continuou cara. Pode mostrar que o contrato reduziu erros ou que a ferramenta expôs permissões demais. Esses dados orientam o desenho melhor do que um número de benchmark retirado de outro site.
WebMCP aponta uma mudança plausível: sites terão uma interface para pessoas e outra camada operacional para agentes. O valor não vem de esconder a web visual. Vem de reservar percepção para onde ela informa uma decisão e usar contratos explícitos onde já existe uma operação clara.
Antes de adotar, vale registrar também o custo de manter esses contratos. Uma ferramenta abandonada ou divergente da interface pública cria outra forma de quebra. O experimento só vence quando a capacidade explícita permanece tão bem cuidada quanto a ação visível que ela representa.
