Stories
Cloudflare made WebMCP easier. Website owners still choose the tools.
by Matt Gibbs · Updated
Cloudflare's new WebMCP developer preview makes the browser connection easier to deliver. Website owners still have to decide which site capabilities should become tools and what an agent may do with them.
Cloudflare can now add a WebMCP bridge at the edge
On 6 August 2026, Cloudflare announced a developer preview that can give websites a WebMCP interface.
For websites using Cloudflare, the preview can inject a small bridge script into HTML responses at the edge. The website owner can enable tool packs through the Cloudflare dashboard without changing the code at the origin. The bridge then registers tools that a compatible browser agent can discover and use.
Cloudflare is starting with two packs. One reads C2PA Content Credentials attached to images. The other can connect to an existing MCP server and expose its tools through WebMCP inside the page.
Until now, adding WebMCP to a website generally meant implementing the browser interface yourself, defining tools, connecting them to the site, handling their lifecycle, and keeping everything aligned as the emerging standard changed.
Cloudflare can now take care of part of that delivery. A website already using Cloudflare could enable the bridge without rebuilding its origin application. If it already has a suitable MCP server, Cloudflare can discover those tools and register browser-facing versions of them.
For sites already using Cloudflare, that removes some implementation work. It also moves WebMCP closer to infrastructure that publishers already use.
WebMCP delivery is different from crawler access
WebMCP offers an alternative to making agents infer every action from pages. Automated systems still crawl public pages for many reasons, and owners cannot always tell what each request intends to do.
Blocking every machine is not realistic, but letting every agent infer its way through the site is not a good answer either.
Instead of forcing an agent to interpret every button, form, and visual layout, the website can expose explicit tools. Those tools have names, descriptions, typed inputs, and structured results.
An ecommerce site could provide a product-search tool rather than making an agent crawl category pages. A travel site could expose a hotel-search tool rather than making an agent manipulate filters. A publisher could provide an approved content-search interface rather than leaving every agent to scrape and reconstruct the site independently.
The current WebMCP proposal describes a way for websites to give agents more reliable access to site functionality while retaining the human interface and shared browser context.
The human website remains in place. WebMCP adds a clearer interface for agents.
The Cloudflare switch does not define what the site should expose
Cloudflare's preview makes the delivery of WebMCP tools easier. It does not automatically decide which site-specific capabilities should become tools.
Cloudflare can inject the bridge. It can register generic packs. It can connect an existing MCP server to the page.
But for site-specific functionality, somebody still has to decide:
- Which capabilities are real?
- Which information is public?
- Which inputs should an agent be allowed to provide?
- Which results are safe to return?
- Which actions are read-only?
- Which actions change something?
- Which actions require approval?
- Which actions should never be available to an agent?
- How should authorization work when the visitor is already signed in?
- How will the owner confirm that the published tool still matches the live website?
Those are not script-injection questions. The website owner still has to answer them.
Registering a tool in the browser is the final delivery step. Before that can happen safely, the website needs a trustworthy definition of the capability being delivered.
Adding a tool is not the same as approving it
Imagine a WooCommerce store.
It could expose a tool that searches products. That is relatively straightforward. The tool can accept a search query and return a bounded list of matching products.
Now imagine a tool that changes the visitor's cart.
The technical function might be simple, but the surrounding questions are not.
Which product is being added? Which variation? How many? What price and availability did the visitor see? Is the request valid for the current session? Does the visitor understand that the cart will change? Can the operation be safely retried? Can it be undone? Does approval apply to this exact action, or has it been reused for a different one?
Simply forwarding an MCP tool into the page does not answer those questions.
The same applies to forms.
A website might contain ten forms, but that does not mean all ten should become agent tools. One may be a public enquiry form. Another may trigger a support workflow. Another may expose fields that should never be available through an automated interface.
Finding a capability does not publish or authorize it. The site must still decide whether an agent may call it and under what conditions.
Owners still decide which capabilities to publish
Open for Agents starts with that decision. On WordPress, the Core plugin finds potential capabilities in content, navigation, search, forms, and WooCommerce. The owner reviews what each one reads or changes and publishes only the ones they approve.
Those approved definitions can then be delivered through MCP, WebMCP, discovery documents or the optional Assistant. If a protocol changes, the owner should not have to review the same capability again from scratch.
Cloudflare can handle delivery while the website keeps control
Cloudflare and Open for Agents address different parts of the process. Cloudflare's preview delivers WebMCP tools at the edge. Open for Agents lets the website owner choose and publish the capabilities first. This does not indicate a partnership or endorsement, and the integration has not been tested.
A possible future setup would let an Open for Agents site publish an MCP tool with defined output limits, then let a Cloudflare customer expose that tool through WebMCP at the edge. The site owner would keep the approval rules; Cloudflare would handle browser delivery. This arrangement has not been tested.
Adding WebMCP through a dashboard still does not answer which tools a site should publish or what each tool may do.
Browser-delivered tools still need authorization
Cloudflare is clear that this is a developer preview. Its Browser Run WebMCP documentation describes the relevant browser sessions as experimental lab sessions that should not be used for production workloads.
WebMCP itself is emerging and subject to change. Browser support is not universal. Registration APIs, permissions, agent access, navigation behaviour, and human-confirmation models are still developing.
There are also practical questions that website owners will need to test carefully.
Cloudflare's MCP pack can communicate with a same-origin MCP endpoint using the visitor's existing session. That is convenient, but an authenticated browser session is a sensitive boundary. A site still needs proper authorization for every operation. Being logged in does not mean an agent should inherit unlimited authority.
There is also the possibility of duplicate tools. A website that already publishes WebMCP tools could end up registering another set through an injected bridge. Tool names, lifecycles, navigation cleanup, and ownership need to be clear.
Edge injection also becomes part of the website's browser supply chain. Content Security Policy, caching, rollback, and provider configuration all need to be understood.
These are practical issues to resolve even when delivery is easy.
Content Credentials are especially interesting for publishers
Cloudflare's C2PA pack also caught my attention.
Publishers increasingly need to understand where media came from, how it was produced, and whether provenance claims can be trusted.
Cloudflare's preview can inspect Content Credentials attached to images and expose that information through tools. Importantly, the announcement distinguishes between reading a credential and cryptographically verifying it. Results that have only been decoded carry a signatureVerified: false value.
Agent systems need to preserve that distinction.
An observed claim should not silently become a verified fact. A website might report that an image contains a stated author or editing history. That does not necessarily mean the claim has been independently verified. Agents should receive the difference clearly rather than turning uncertain source material into confident prose.
For publishers, that separation between observed, claimed, and verified information may become as important as the tools themselves.
Start by deciding what agents may do
I would not suggest that every website owner rush into an experimental browser API because a switch has appeared in a dashboard.
Start by asking what agents should actually be able to do on your website.
Begin with read-only capabilities. Identify the information that is already public and useful. Set clear limits on inputs and results. Decide which sources the tool should use. Check that the result agrees with the live site.
Then examine actions.
Separate harmless reads from consequential changes. Require visible, specific approval where an action changes state. Keep checkout, payment, account access, authentication, and other sensitive operations under human control unless there is a genuinely reviewed reason to do otherwise.
Finally, decide how those approved capabilities should be delivered.
For some sites, that may eventually include Cloudflare's WebMCP bridge. For others it may be native WebMCP, a direct MCP endpoint, an embedded Assistant, or a combination of these.
Choose what to publish before choosing how to deliver it.
Website owners still decide what agents may use
Cloudflare's preview shows that WebMCP delivery is moving into ordinary web infrastructure. Agents will still scrape or click when no explicit interface exists, but websites can now offer tools with named inputs and structured results.
Cloudflare can make those tools easier to deliver. Open for Agents helps the owner decide which tools to publish and which actions require approval. A dashboard switch does not make those decisions for the site.