Cloudflare Launches WebMCP Developer Preview to Enable Browser Agents Without Origin Code Changes

Cloudflare Launches WebMCP Developer Preview to Enable Browser Agents Without Origin Code Changes Cloudflare has introduced a developer preview of WebMCP, allowing site owners to expose structured tools to browser-based AI agents via a dashboard toggle without modifying their origin codebase. WebMCP is an experimental browser standard shipping in Chrome 146 that presents as document.modelContext to let agents interact via dedicated tools instead of scraping. Cloudflare implements the standard at the edge using HTMLRewriter to inject a bridge script reference that executes entirely in the client browser. The initial preview includes two tool packs: Content Credentials for reading C2PA metadata locally and Site MCP Server for connecting to an existing Model Context Protocol endpoint. Tools use native Model Context Protocol types, and sites can be tested using Cloudflare's BrowserRun remote browser. Edge-Based Architecture Cloudflare deploys WebMCP without touching origin application code. When activated in the dashboard, Cloudflare's edge uses HTMLRewriter to inject a script tag referencing a bridge script served from the same origin. The in-page bridge checks for the browser's WebMCP surface and exits silently if unsupported. If present, the bridge registers configured tool packs using the standard registerTool method. Initial Tool Packs and Execution The preview features two client-side tool packs. The Content Credentials pack extracts and parses the opening metadata kilobytes of images for C2PA provenance manifests, explicitly marking outputs with signatureVerified false because it does not cryptographically verify signatures. The Site MCP Server pack connects directly to a site's own MCP server endpoint (defaulting to /mcp) within the visitor's existing session. Standard Compatibility and Testing Tools conform directly to Model Context Protocol's Tool and CallToolResult formats, allowing existing MCP agents to control pages natively. Cloudflare's BrowserRun remote browser already supports WebMCP discovery and invocation, enabling developers to test registered tools headless in the cloud or across desktop browsers without deploying an independent agent.

Cloudflare 推出 WebMCP 开发者预览版：无需修改源站代码即可为网站接入 AI 浏览器 Agent 工具 Cloudflare 宣布推出 WebMCP 开发者预览版。网站无需修改源站代码，只需在控制台开启开关，即可通过边缘注入桥接脚本，为访问网站的 AI 浏览器 Agent 注册并提供原生可调用的结构化工具。 WebMCP 是 Chrome 146 实验性推出的浏览器新标准（挂载在 document.modelContext），允许站点直接为 Agent 暴露工具以降低导航消耗。 Cloudflare 利用边缘 HTMLRewriter 注入轻量桥接脚本，无需改动源站代码或重新部署即可完成适配。 预览版内置纯在访客浏览器本地运行的工具包，包括解析 C2PA 元数据的内容凭证包和连接自建端点的 Site MCP Server 包。 Cloudflare 的远程浏览器 BrowserRun 已集成 WebMCP 支持，可直接用于发现和测试网站注册的工具。 WebMCP 标准与边缘注入机制 面对 AI Agent 访问激增的现状，传统网页抓取存在 token 浪费和交互低效的问题。WebMCP 是一项在 Chrome 146 中实验性支持的新浏览器标准，页面可通过 document.modelContext 暴露工具。Cloudflare 在边缘节点通过 HTMLRewriter 向 HTML 响应注入单行桥接脚本引用。该脚本在浏览器端执行，一旦检测到 WebMCP 接口便通过 registerTool 注册工具包，不改动源站任何代码，且同时兼容静态网页与单页应用。 首发工具包与本地执行特性 在本次预览版中，所有工具均完全在访客浏览器本地执行，不产生额外的服务端往返。目前默认启用的两个工具包中，“内容凭证”包仅读取图片开头数千字节的 C2PA 元数据来解析编辑历史和签名证书（目前 signatureVerified 统一标记为 false，仅提取不作加密验证）；“Site MCP Server”包则允许 Agent 直接与站点既有的 MCP 端点交互。未来官方还计划引入边缘 Worker 提供站点地图总结等扩展能力。 配置生效与测试验证 站长可在 Cloudflare 控制台的 Agent Readiness 路径下一键启用 WebMCP 并选择工具包组合。验证部署时，除了检查 HTML 中的注入标签外，开发者还可以直接使用 Cloudflare 的远程浏览器 BrowserRun 访问目标 URL，以实际观察 Agent 自动发现并调用各工具包的完整交互过程。

Today we are launching a developer preview of WebMCP on Cloudflare. Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin. Cloudflare adds a small bridge to your pages, which registers a set of tools for a visitor’s agent to use. The web was built on the assumption that there is a person on the other end: someone to read the page, click buttons, and fill in the forms. But now more and more visits come from AI agents instead, to an Internet made for humans. The usual approach has been crawlers, which copy content back to a server and, too often, give the original site none of the traffic and little of the credit. There is a better way, and it does not involve scraping. WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as `document.modelContext`. A site can choose to expose a set of tools for agents running in the browser, meaning agents no longer have to guess their way through a page built for humans. This enables agents to have a different browsing experience from the user and use tokens on tasks, not navigation. The catch: the site has to implement it. Cloudflare has been building both ends of this. [BrowserRun](https://developers.cloudflare.com/browser-run/), our remote browser, already added WebMCP support, so an agent can discover and call the tools a site exposes. [Cloudflare Radar](https://radar.cloudflare.com/) will soon offer WebMCP tools of its own. This preview is about the other side: a way to give any site on Cloudflare those tools with a single switch, and no code. Implementing WebMCP by hand is a small project: design the tools to expose, wire them into your interface, and keep them working as the standard evolves. We wanted it to be simpler than that: just toggle a setting to enable tools. These tools come in packs — groups of related tools that can be turned on together. These are built to grow: as we add packs, a site can opt in to more just by turning them on, no redeploy needed. We are including two tool packs in this developer preview, which both run entirely in the browser. Our implementation comprises two parts, both in front of your origin. Neither touches your site’s code and both work the same way whether your site is static or a single-page app. First, an injection at the edge. When your site has WebMCP switched on in your Cloudflare Dashboard, we use HTMLRewriter to add one line to each HTML response: a small reference to a bridge script that we also serve. Both the tag and script it loads come from the edge, same origin, so nothing else about the page changes: The `data-packs` attribute is the list of packs to activate. If you have an existing Model Context Protocol (MCP) server, the `data-mcp-url` points at your own MCP server (defaulting to the same origin `/mcp`). Second, the bridge. This runs in the page and finds the WebMCP surface. If the browser does not have one, it returns and does nothing, so the page behaves exactly as before. From there, the bridge composes the packs named in `data-packs` into one tool list and registers each with `.registerTool`. A pack is just a set of MCP tool descriptors and their handlers. Static packs, such as Content Credentials, declare their tools up front. A dynamic pack, such as the Site MCP Server pack, discovers its tools at boot before registering anything. In this preview, every tool runs entirely in the visitor’s browser. There is no round trip to a server of ours. The Content Credentials pack fetches an image and parses its first few kilobytes of content provenance metadata locally. The Site MCP Server pack talks straight to your MCP server endpoint from the page, on the visitor's origin and with their existing session. The bridge code is served by a worker running at the edge. This leaves us room to grow the offering — future packs will be able to call this worker for tasks the page cannot do alone, like summarizing a sitemap with Workers AI or querying an AI Search index. To an agent, all of these are ordinary MCP tools. We use Model Context Protocol’s own `Tool` and `CallToolResult` types, so an agent that already talks to MCP servers can drive a page with nothing special added. The browser is just another place MCP runs. The example below shows how the bridge turns one of your own MCP tools into a tool the visitor’s agent can call. We are also developing packs to read different types of metadata. For example, credentials for participants of the [C2PA](https://c2pa.org/) program can be retrieved using the Content Credentials pack. `scan_images_c2pa` sweeps every image and returns a short summary of each: For a closer look, `inspect_image_c2pa` decodes one image’s full manifest: its edit history, the stated author, and the signing certificate. It is a plain TypeScript reader that touches only a few kilobytes of the metadata at the front of the image, not the image itself. For now, it reads and reports the credential, rather than cryptographically verifying it: every result carries `signatureVerified: false`, so an agent won’t mistake a decoded claim for a checked one. Get started with WebMCP by going to [Agent Readiness > WebMCP](https://dash.cloudflare.com/?to=/:account/:zone/agent-readiness/webmcp) in the Cloudflare Dashboard. Here you can toggle on WebMCP for a domain, and pick which packs to add: both Content Credentials and Site MCP Server are on by default, and more packs will show up here as we ship them. That's the whole setup. There's nothing to deploy and nothing to change at your origin, and the next HTML your site sends will include the bridge. To confirm it’s live, ask your site for any HTML page and look for the line Cloudflare injected: You do not need your own agent to see the tools work. Point [BrowserRun](https://developers.cloudflare.com/browser-run/features/webmcp/), Cloudflare’s remote browser, at your URL, and it will discover and call the tools your packs registered, exactly as a visitor’s agent would. That is the whole loop: BrowserRun gives agents a browser to act on, this preview gives your site the tools to be acted on, and they meet using the open standard. The tools behave in the same way whether the browser is on someone’s laptop or running headless in the cloud. Our job is to help make the Internet better, and as the Internet changes we need to provide domain owners with tools that allow new visitors, AI agents, to interact without a full rebuild. It is one step towards a web that can still thrive when visitors are not always human. This is a developer preview, and we want your feedback. Turn it on, try it against your own site, and tell us how it goes in the [Cloudflare Developers Discord](https://discord.cloudflare.com/) or on the [Community forum](https://community.cloudflare.com).