InfoQ a publié son article sur la préversion WebMCP de Cloudflare le 10 août. L'annonce canonique de Cloudflare porte la date du 6 août et indique une mise à jour le 10 août. La source primaire décrit un seul interrupteur dans Agent Readiness > WebMCP. Une fois l'option activée, Cloudflare utilise HTMLRewriter à la périphérie pour injecter dans chaque réponse HTML une référence de même origine vers /.webmcp/bridge.js. Le pont repère l'interface de navigateur proposée document.modelContext, assemble les packs activés et enregistre des outils nommés avec leurs schémas d'entrée. Si le navigateur ne possède pas cette interface, Cloudflare dit que le pont s'arrête sans modifier le comportement de la page. Aucun code applicatif du serveur d'origine ne doit changer.

La préversion commence avec 2 packs. Selon Cloudflare, Content Credentials lit les premiers kilo-octets des métadonnées de provenance C2PA des images, mais ne vérifie pas les signatures de façon cryptographique et renvoie signatureVerified: false. Le pack Site MCP Server découvre les outils d'un serveur existant par tools/list. Son relais envoie tools/call au point d'accès de même origine /mcp avec les identifiants réglés sur same-origin, il utilise donc la session existante du visiteur. Cloudflare affirme que chaque outil actuel s'exécute dans le navigateur du visiteur, sans aller-retour vers un serveur Cloudflare. Cela évite de remettre une clé d'API du backend à l'agent. Cela fait aussi du navigateur authentifié une frontière d'autorité active : une interface plus propre ne sécurise pas à elle seule une action lourde de conséquences.

Pour les concepteurs d'agents, le changement de fond est le contrat. Cloudflare et InfoQ décrivent simplement le cycle actuel : l'automatisation visuelle du navigateur dépense des jetons à interpréter les mises en page, peut mal comprendre une commande et casse souvent quand un site modifie son interface. Un outil nommé avec un schéma d'entrée JSON resserre l'action et le résultat attendu. Tout aussi important, un appel structuré peut distinguer un outil absent, une erreur d'exécution et un résultat vide valide. Un client qui revient silencieusement au scraping recrée l'ambiguïté et peut présenter un appel en échec comme une absence de nouveauté. WebMCP ne réduit cette forme de fragilité que si les clients gardent ces états séparés.

Pour les éditeurs, le même mécanisme est une surface de contrôle. Cloudflare laisse le propriétaire du site sélectionner les packs et en activer d'autres plus tard sans redéployer le serveur d'origine. La documentation de Chrome précise que WebMCP exige un document isolé par origine et que la politique d'autorisations de la fonctionnalité tools prend la valeur self par défaut, ce qui bloque l'accès depuis une iframe d'une autre origine sauf autorisation explicite. Ce sont de vraies limites. Mais le menu du site reste éditorialisé : un éditeur peut exposer une action utile, en omettre une autre et orienter la manière dont un agent perçoit le service. Lisible par une machine ne veut pas dire complet ou neutre. Cela désigne une surface négociée que l'origine contrôle.

Il ne faut pas y voir une norme de navigateur déjà disponible partout. Les sources se contredisent sur les versions. Cloudflare dit que WebMCP est expérimental dans Chrome 146. InfoQ dit Chrome 145+. La documentation de Chrome, mise à jour le 7 août, place le début de son essai d'origine dans Chrome 149 et exige un indicateur pour les tests locaux. Ces nombres ne peuvent pas tous décrire la même disponibilité. Ensemble, les sources permettent seulement d'affirmer que WebMCP reste proposé, réservé à Chrome et susceptible de changer. Le web lisible par les machines arrive ici comme un contrat facultatif entre le site, le navigateur et l'agent, pas comme un remplacement universel de HTML.