InfoQ 于 8 月 10 日发布了关于 Cloudflare WebMCP 预览的报道。Cloudflare 的官方公告日期为 8 月 6 日，并标注于 8 月 10 日更新。这份主要来源描述了 Agent Readiness > WebMCP 下的 1 个控制台开关。启用后，Cloudflare 在边缘使用 HTMLRewriter，向每个 HTML 响应注入同源的 /.webmcp/bridge.js 引用。桥接脚本查找拟议的 document.modelContext 浏览器接口，组合已启用的工具包，并注册带输入架构的具名工具。Cloudflare 表示，如果浏览器没有该接口，桥接脚本会直接停止，不改变页面行为。源站的应用代码无需修改。
这项预览从 2 个工具包开始。Cloudflare 表示，Content Credentials 会读取图像开头几千字节中的 C2PA 溯源元数据，但不会以密码学方式验证签名，并返回 signatureVerified: false。Site MCP Server 工具包通过 tools/list 发现现有服务器的工具。它的代理把 tools/call 发送到同源 /mcp 端点，credentials 设为 same-origin，因此会使用访客现有的会话。Cloudflare 表示，目前每个工具都在访客的浏览器中执行，不会往返 Cloudflare 服务器。这样无需把后端 API 密钥交给代理，但也让已经认证的浏览器成为实际的权限边界：更整洁的接口本身并不能让有后果的操作变得安全。
对代理开发者而言，实质变化是接口契约。Cloudflare 和 InfoQ 对现有循环的描述很直白：视觉式浏览器自动化需要消耗 token 来解读布局，可能误判控件，并且经常会在网站修改界面后失效。带 JSON 输入架构的具名工具缩小了操作范围，也明确了预期输出。同样重要的是，结构化调用可以区分工具缺失、执行错误和有效的空结果。客户端如果悄悄退回抓取，就会重新制造歧义，并可能把调用失败报告成没有新内容。只有客户端把这些状态分开，WebMCP 才能减少这一类脆弱性。
对发布者而言，同一套机制也是控制界面。Cloudflare 允许网站所有者选择工具包，并在日后无需重新部署源站的情况下启用更多工具包。Chrome 文档称，WebMCP 要求使用 origin-isolated 文档，并且 tools Permissions Policy 默认为 self，除非明确允许，否则会阻止跨源 iframe 访问。这些是真实的边界。但网站的菜单经过策划：发布者可以公开一项有用操作，省略另一项，并塑造代理如何理解这项服务。机器可读不等于完整或中立，而是由源站控制的协商界面。
不要把它理解为已经在所有浏览器中发布的标准。各来源对版本里程碑互相矛盾。Cloudflare 称 WebMCP 在 Chrome 146 中处于实验阶段。InfoQ 称 Chrome 145+。Chrome 文档于 8 月 7 日更新，其中称源试用从 Chrome 149 开始，本地测试还需要开启 flag。这些数字不可能都在描述同一种可用性。它们共同支持的结论只有一个：WebMCP 仍处于提案阶段，仅限 Chrome，并且可能变化。机器可读的 Web 在这里是网站、浏览器和代理之间的一份选择加入契约，不是 HTML 的通用替代品。