Commerce.com e Cloudflare levam o WebMCP às vitrines de quase 100 mil lojas para agentes de IA

O problema que o WebMCP ataca é prático. Hoje, a maioria dos agentes de compra lê o HTML da página, tenta adivinhar qual botão faz o quê, clica e repete quando erra. Custa tokens, demora e quebra com uma simples troca de tema. Banners de cookies, menus de variantes e desafios anti-bot pioram o quadro. Com o WebMCP, a loja expõe ferramentas estruturadas em document.modelContext, como search_products e add_to_cart, e o agente chama a função certa direto.

O desenho técnico da integração chama atenção. As ferramentas rodam na sessão ativa do navegador, no domínio da loja, então o agente vê os mesmos preços e o mesmo carrinho, sem credenciais indo para terceiros. A Cloudflare entrega a camada de edge e faz proxy das definições e ações do servidor MCP da Commerce.com sem alterá-las, e a lógica continua com o lojista. O checkout fica na mão do comprador. Para escalar a quase 100 mil domínios, a Cloudflare usou Configuration Rules e metadados de custom hostname, permitindo opt-out por lojista sem latência extra nem script injetado. Também criou uma configuração de URL do MCP por zona, porque o servidor da Commerce.com fica em /api/mcp e não em /mcp, e o script sai de cena se o servidor estiver offline ou o navegador não suportar o padrão.

Em 10 de agosto de 2026, o CEVIU cobriu a prévia para desenvolvedores do WebMCP na Cloudflare, ainda como recurso a ser ligado por site. Agora há um caso de escala real: uma plataforma inteira habilitando o padrão de uma vez, com controle por lojista. O ajuste mais concreto é o URL de MCP configurável por zona, descoberto no uso com parceiro.

Isso conecta o WebMCP ao que o CEVIU vinha mostrando sobre comércio agentic, como o padrão UCP de maio de 2026, em que o varejista mantém o controle do checkout. Para devs de e-commerce, a lição é que expor ferramentas estáveis tende a ser mais confiável do que depender de seletores de HTML.