Cloudflare 在边缘将 WebMCP 工具注入到网站中

该预览在 Cloudflare 的边缘注入了一个 WebMCP 桥,使浏览器代理无需在源端部署即可获得结构化访问。

By · Published

Primary source: Cloudflare Developers on X

Why it matters

Cloudflare can place structured agent interfaces in front of existing sites at network scale, accelerating WebMCP adoption while making tool permissions and authenticated actions a core infrastructure concern.

Cloudflare injects WebMCP tools into websites at the edge — The preview injects a WebMCP bridge at Cloudflare's edge, giving browser agents structured access without origin-side deployment.

Cloudflare 在 8月6日 推出了一个开发者预览版,允许客户通过启用仪表板设置将网站功能暴露给基于浏览器的 AI 代理。在 X 上的公告 和随附的 技术文章 描述了一个边缘注入的桥接,它在不要求客户重新部署站点或更改源站代码的情况下注册结构化的 WebMCP 工具。

Will Rowe,Cloudflare 的一名 staff software engineer 兼该技术文章的作者,正在解决新兴代理式网络面临的分发问题:WebMCP 为网站定义 AI 代理可执行操作提供了标准方式,但按常规每个网站都需要自行设计、实现并维护这些工具。Cloudflare 将这项工作移动到其网络层,客户可以在网络层启用一组预构建的工具包。

源站代码与交付给访问者的页面之间的区别很重要。Cloudflare 保留客户存储的应用代码不变,然后使用其 HTMLRewriter 系统在边缘向 HTML 响应添加一个模块脚本。该脚本从站点自身的源站提供,检测浏览器是否支持 WebMCP 并注册所选工具。不支持该接口的浏览器会忽略该桥接。

将页面转换为可调用接口

WebMCP 是围绕 document.modelContext 构建的一个草案浏览器 API。网站将 JavaScript 函数注册为带有自然语言描述和结构化输入 schema 的具名工具。代理可以发现并调用这些函数,而无需解释屏幕截图、搜索 DOM 或反复猜测应按哪个按钮。

该标准仍处于试验阶段。Chrome 的 WebMCP 文档,于 7月1日 更新,称该 API 仍在积极讨论中,可能会发生变化。Cloudflare 表示浏览器实现正在 Chrome 146 中以实验方式发布。

Cloudflare 的预览最初包含两个工具包。Site MCP Server pack 将页面连接到现有的同源 MCP 端点,发现该服务器公布的工具并为其注册浏览器端代理。调用直接从页面传到客户的端点,使用访问者现有的会话。

这种方法允许网站重用其已经构建的 MCP 服务器。它还使代理的操作具有与使用浏览器的用户相同的已验证上下文。例如,一个购物网站可以将产品搜索或账户操作作为类型化函数暴露,而不是要求代理通过面向人的界面进行导航。

第二个工具包处理根据 C2PA 标准产生的 Content Credentials 元数据。一个工具扫描页面上的图像以查找溯源元数据,另一个工具读取所选图像的清单,包括其声明的作者、编辑历史和签名证书。Cloudflare 表示预览在浏览器本地解码这些声明。它不对签名进行密码学验证,结果被标记为 signatureVerified: false

根据 Cloudflare 的说法,这两个工具包在预览期间都在访问者的浏览器中运行。桥接本身由边缘的一个 Worker 交付,这为 Cloudflare 提供了一条添加使用其自身服务的工具包的路径。Rowe 提到未来可能的工具包括使用 Workers AI 总结站点地图或查询 AI Search 索引。

Cloudflare 正在构建交易双方

此次发布扩展了 Cloudflare 今年早些时候开始的 WebMCP 推进。4月15日,Cloudflare 向其托管浏览器基础设施 Browser Run 添加了实验性 WebMCP 支持。Browser Run 为代理提供了一个可以发现并执行 WebMCP 工具的环境。新的预览向通过 Cloudflare 运行的站点提供这些工具。

这种配对使 Cloudflare 控制了代理的浏览器运行时和网站端桥接。开发者可以在一个域上启用工具并通过 Browser Run 测试它们,而无需组装单独的浏览器堆栈。Cloudflare 更广泛的 Browser Run 平台 已经通过 Playwright、Puppeteer 和 Chrome DevTools Protocol 支持浏览器自动化。

客户可以在 Cloudflare 仪表板的 Agent Readiness and Labs 下激活该预览。Cloudflare 表示,一旦打开 WebMCP,Content Credentials 和 Site MCP Server packs 默认启用,客户可以选择其域要公开哪些工具包。

现有会话设计也提高了工具权限的重要性。WebMCP 草案明确将继承认证、跨站上下文和提示注入视为安全问题。Cloudflare 的实现将调用保留在访问者的源站上,但站点所有者仍决定发布哪些能力,而浏览器和代理提供者决定用户如何查看并授权这些调用。

Cloudflare 目前的押注是,网站运营者会更愿意采用受控的、类型化的接口,而不是让代理去抓取并点击为人类构建的页面。通过将该接口作为一个边缘设置,Cloudflare 可以推动 WebMCP 的采用,而无需等待每个客户为代理重建其前端。

Reader comments

Conversation for this story loads after sign-in.