为任意网站接入 WebMCP 接口
今天，我们在 Cloudflare 上发布了 WebMCP 的开发者预览版。一键开启，浏览器代理就能直接和你的网站协作，不需要写代码，源站也无需任何改动。Cloudflare 会在你的页面里嵌入一条轻量桥接，为访问者的代理注册一组可用工具。
互联网当初的设计前提是：屏幕对面坐着一个人——有人读页面、点按钮、填表单。但如今，越来越多访问来自 AI 代理，它们闯进这个为人类打造的互联网。传统的做法是爬虫：把内容抓回服务器，结果往往是原网站既没拿到流量，也几乎得不到署名。
更好的做法是有的，而且不必靠爬取。WebMCP 是一项新的浏览器标准，正在 Chrome 146 中实验性上线，在页面中以 document.modelContext 的形式呈现。网站可以主动选择向浏览器中的代理暴露一组工具，这样一来，代理就不必再对着为人类设计的页面瞎猜乱试。代理可以拥有和人类用户完全不同的浏览体验，把算力花在真正的任务上，而不是花在页面导航上。
问题在于：需要网站自己来实现这套标准。Cloudflare 一直在同时建设两端。我们的远程浏览器 BrowserRun 已经支持 WebMCP，代理可以在其中发现并调用网站暴露的工具。Cloudflare Radar 很快也会提供自己的 WebMCP 工具。本次预览针对的是另一端：让 Cloudflare 上的任何网站都能一键获得这些工具，零代码。
Cloudflare 上的 WebMCP 开发者预览版
手工实现 WebMCP 本身是个不小的工程：要设计要暴露哪些工具，把它们接入你的界面，还要随着标准演进持续维护。我们希望这能更简单：拨一下开关，工具就有了。
这些工具按「工具包」组织——一组相关的工具可以一起开启。这套机制是为扩展而设计的：随着我们不断新增工具包，网站只需打开开关就能接入更多能力，无需重新部署。
本次开发者预览版包含两个工具包，完全在浏览器内运行。
它的作用与工作原理
我们的实现由两部分组成，都位于你的源站之前。两者都不会触碰你网站的代码，而且无论你的网站是静态站点还是单页应用，它们的工作方式都完全一样。
首先是边缘注入。当你的网站在 Cloudflare Dashboard 中开启 WebMCP 后，我们会用 HTMLRewriter 在每个 HTML 响应中加一行：一个指向桥接脚本的简短引用，这个脚本同样由我们在边缘提供。标签和它加载的脚本都来自边缘、同源，因此页面的其他内容不会有任何变化：data-packs 属性就是要激活的工具包列表。如果你已经有现成的模型上下文协议（MCP）服务器，data-mcp-url 会指向你自己的 MCP 服务器（默认是同一来源的 /mcp）。
其次是桥接。它在页面中运行并寻找 WebMCP 接口。如果浏览器没有这个接口，它就直接返回、不做任何事，页面行为与之前完全相同。接下来，桥接把 data-packs 中列出的工具包组合成一个工具列表，并通过 .registerTool 逐个注册。工具包就是一组 MCP 工具描述符及其处理函数。静态工具包（比如内容凭证）会预先声明自己的工具；动态工具包（比如 Site MCP Server 工具包）则在启动时先发现工具，再注册任何东西。
在这个预览版中，每个工具都完全运行在访客的浏览器里，不会往返于我们的任何服务器。内容凭证工具包会获取一张图片，在本地解析其前几 KB 的内容来源元数据；Site MCP Server 工具包则从页面直接与你的 MCP 服务器端点通信，走访客的来源域名和现有会话。
桥接代码由运行在边缘的 Worker 提供，这为未来的扩展留出了空间——以后的工具包可以调用这个 Worker 来完成页面独自做不了的事情，比如用 Workers AI 总结站点地图，或者查询 AI Search 索引。
对智能体而言，这些全都是普通的 MCP 工具。我们用的是模型上下文协议自带的 Tool 和 CallToolResult 类型，所以一个已经能跟 MCP 服务器对话的智能体，不需要任何额外东西就能驱动网页。浏览器只是 MCP 运行的又一个地方。
下面这个例子展示了这座“桥”如何把你自己的一个 MCP 工具，变成访客 agent 也能调用的工具。
查看内容元数据
我们还在开发各种 pack，用来读取不同类型的元数据。例如，可以通过 Content Credentials pack 获取 C2PA（内容来源与真实性联盟）计划参与者的凭证。
scan_images_c2pa 会扫描每张图片，并返回每张图片的简短摘要：
如果想看得更仔细，inspect_image_c2pa 可以解码单张图片的完整 manifest：包括编辑历史、声明作者和签名证书。它只是一个简单的 TypeScript 读取器，只读取图片开头几 KB 的元数据，不会触碰图片本身。
目前，它只是读取并报告凭证，而不是做密码学验证：每个结果都会带有 signatureVerified: false，这样 agent 就不会把“已解码的声明”误认为是“已验证的声明”。
试试看
要开始使用 WebMCP，可以进入 Cloudflare 控制台的 Agent Readiness > Labs。在这里，你可以为某个域名开启 WebMCP，并选择要添加哪些 pack：Content Credentials 和 Site MCP Server 默认都已开启，后续我们还会持续发布更多 pack，它们也会出现在这里。
配置就这么多。你不需要部署任何东西，也不需要改动源站，你的网站下一次返回的 HTML 就会自动包含这座“桥”。要确认它已生效，只需向你的网站请求任意一个 HTML 页面，然后找到 Cloudflare 注入的那一行代码：
你不需要自己拥有 agent 就能看到这些工具在起作用。把 Cloudflare 的远程浏览器 BrowserRun 指向你的 URL，它就会像访客的 agent 一样，发现并调用你的 packs 注册的工具。整个闭环就是这样：BrowserRun 给 agent 提供一个可以操作的浏览器，WebMCP 为你的网站提供可被操作的工具，双方通过开放标准互相连接。无论浏览器是在某人的笔记本上，还是在云端以无头模式运行，这些工具的行为都是一样的。
为什么我们要做这个
我们的职责是帮助互联网变得更好。随着互联网本身在变化，我们需要为域名所有者提供工具，让他们能够在不推倒重建的情况下，与新的访客——也就是 AI agent——交互。这是迈向这样一个网络的一步：即使访客不总是人类，它依然能够蓬勃发展。