A InfoQ publicou em 10 de agosto sua matéria sobre a prévia do WebMCP da Cloudflare. O anúncio canônico da Cloudflare tem data de 6 de agosto e aparece como atualizado em 10 de agosto. A fonte primária descreve um único botão em Agent Readiness > WebMCP. Depois da ativação, a Cloudflare usa o HTMLRewriter na borda para injetar em cada resposta HTML uma referência de mesma origem a /.webmcp/bridge.js. A ponte encontra a interface de navegador proposta document.modelContext, reúne os pacotes habilitados e registra ferramentas nomeadas com esquemas de entrada. Se o navegador não tiver a interface, a Cloudflare diz que a ponte para sem mudar o comportamento da página. Nenhum código da aplicação no servidor de origem precisa ser alterado.
A prévia começa com 2 pacotes. Segundo a Cloudflare, o Content Credentials lê os primeiros quilobytes de metadados de proveniência C2PA das imagens, mas não verifica criptograficamente as assinaturas e informa signatureVerified: false. O pacote Site MCP Server descobre as ferramentas de um servidor existente por tools/list. Seu proxy envia tools/call ao endpoint de mesma origem /mcp com as credenciais definidas como same-origin, portanto usa a sessão existente do visitante. A Cloudflare afirma que cada ferramenta atual roda no navegador do visitante sem uma viagem de ida e volta a um servidor da empresa. Isso evita entregar ao agente uma chave de API do backend. Também transforma o navegador autenticado em uma fronteira ativa de autoridade: uma interface mais limpa não torna segura, por si só, uma ação com consequências.
Para quem constrói agentes, a mudança substantiva é o contrato. Cloudflare e InfoQ descrevem com clareza o ciclo atual: a automação visual do navegador gasta tokens interpretando layouts, pode entender um controle de forma errada e costuma quebrar quando um site muda sua interface. Uma ferramenta nomeada com um esquema de entrada JSON restringe a ação e o resultado esperado. Tão importante quanto isso, uma chamada estruturada consegue distinguir uma ferramenta ausente, um erro de execução e um resultado vazio válido. Um cliente que volta silenciosamente ao scraping recria a ambiguidade e pode apresentar uma chamada com falha como se não houvesse novidade. O WebMCP reduz uma classe de fragilidade somente quando os clientes mantêm esses estados separados.
Para os publicadores, a mesma estrutura é uma superfície de controle. A Cloudflare permite que o proprietário do site selecione pacotes e ative outros depois sem reimplantar o servidor de origem. A documentação do Chrome diz que o WebMCP exige um documento isolado por origem e que a política de permissões tools usa self por padrão, bloqueando o acesso por um iframe de outra origem sem autorização explícita. São limites reais. Mas o menu do site é curado: um publicador pode expor uma ação útil, omitir outra e moldar como um agente percebe o serviço. Legível por máquina não significa completo nem neutro. Significa uma superfície negociada e controlada pela origem.
Isto não deve ser lido como um padrão de navegador disponível em toda parte. As fontes se contradizem sobre as versões. A Cloudflare chama o WebMCP de experimental no Chrome 146. A InfoQ diz Chrome 145+. A documentação do Chrome, atualizada em 7 de agosto, diz que seu teste de origem começa no Chrome 149 e que os testes locais exigem uma flag. Esses números não podem descrever todos a mesma disponibilidade. Em conjunto, as fontes sustentam apenas que o WebMCP continua sendo uma proposta, restrita ao Chrome e sujeita a mudanças. A web legível por máquinas chega aqui como um contrato opcional entre site, navegador e agente, não como substituto universal do HTML.