Stories
Cloudflare made WebMCP easier. Website governance matters more.
7 August 2026 by Matt
I have been a web publisher and webmaster for more than 20 years. I have watched the web move through search, social media, mobile devices, apps, and increasingly automated use.
The next change is already taking shape.
People will still visit websites, but they will do less of the routine browsing themselves. We will have personal assistants that can research a subject, compare products, monitor changes, fill in forms, and carry out useful tasks for us.
Those assistants will need to use websites.
That sounds obvious, but most websites were never designed for it. They were designed for a person who can read a page, interpret a menu, understand a button, and work out which part of a form matters.
An agent arriving at the same site often has to reverse engineer all of that. It inspects the page, follows links, and tries to infer what the owner intended. That can be slow, expensive, and unreliable. It can also leave the website owner with very little control over how the site is interpreted and used.
This is why I have been following WebMCP so closely.
Cloudflare has made the direction much clearer
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.
This is a meaningful development.
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.
That lowers the barrier considerably. It also tells us something more important: major web infrastructure companies believe agent interaction is becoming part of the normal web stack.
This is not another crawler feature
The most interesting part of WebMCP is that it offers an alternative to agents scraping and guessing their way through websites.
I can already see how much website traffic is not a person sitting down to read a page.
Some of it is normal search crawling. Some appears to come from AI-related systems, automated tools, unidentified bots, and scanners. I cannot always tell whether a particular request is collecting search data, gathering material for a model, looking for an answer, or simply probing the site.
What I can see is the behaviour.
Automated traffic repeatedly requests broken links. It tries hundreds of variations of the same URL. It visits pages that have not existed for years. It adds server load, bandwidth use, log noise, and cost without behaving anything like a human visitor.
Blocking every machine is not a realistic answer. Machines have been part of the web for decades, and useful agents will become another legitimate type of visitor.
But letting every machine crawl the entire site and infer what it can do is not a good answer either.
WebMCP presents a better model.
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.
That direction makes sense to me. The human website remains. WebMCP adds a clearer interface for agents.
The switch is not the source of truth
Cloudflare's preview makes the delivery of WebMCP tools easier. It does not automatically decide which site-specific capabilities should become tools.
That distinction matters.
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?
- What evidence proves that the published tool still matches the live website?
Those are not script-injection questions. They are governance questions.
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 and governing a capability are different jobs
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.
Discovery is not approval. Technical availability is not publication. A valid tool call is not necessarily an authorized action.
This is where Open for Agents fits
When I first saw WebMCP, the direction made immediate sense to me. Websites needed a more explicit interface for agents.
But the protocol did not answer the question I cared about as a website owner:
What should an agent be allowed to know and do on my site?
That question is at the centre of Open for Agents.
Open for Agents is built around an owner-reviewed capability catalogue. On WordPress, the Core plugin discovers potential site capabilities across content, navigation, search, forms, and WooCommerce. The owner can inspect those capabilities, review what they read or change, decide which ones are suitable, and publish only the approved surface.
That reviewed catalogue can then be projected into different agent-facing formats. MCP is one projection. WebMCP is another. Discovery files and machine-readable site information are others. The optional Open for Agents Assistant gives ordinary visitors a conversational way to use the same reviewed capabilities.
The adapter is not the source of truth. The reviewed catalogue is.
That matters because protocols will continue to evolve. Browsers will change. New agent clients will arrive. Infrastructure providers will create simpler deployment paths.
The website owner should not have to recreate their safety and publication decisions separately for every new surface.
Cloudflare validates the direction
I do not see Cloudflare's announcement as making Open for Agents redundant. I see it as validation of the central idea.
Cloudflare is making basic WebMCP delivery easier. That is good for the ecosystem. Website owners should not have to build and maintain every piece of browser integration themselves.
It may also create useful future deployment options.
An Open for Agents site could produce a reviewed, bounded MCP surface. A Cloudflare customer could then choose to let Cloudflare project that approved surface into WebMCP at the edge.
In that arrangement, each product has a clear responsibility.
Open for Agents determines which capabilities are real, reviewed, and appropriate. It governs publication, approval, validation, and the relationship between different agent surfaces.
Cloudflare handles the browser delivery mechanism at the edge.
Those roles are complementary. This is not a claim of a partnership, endorsement, or tested integration.
The announcement also raises the bar for anyone building in this area. "We add WebMCP to your website" will not remain a meaningful point of difference if infrastructure providers can do that with a dashboard switch.
The lasting value will be in what sits behind the switch.
A simple interface still needs careful boundaries
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.
That is the right level of caution.
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.
None of these questions makes Cloudflare's preview a bad idea. They are examples of why easier delivery does not remove the need for deliberate governance.
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.
That is exactly the sort of distinction agent systems need to preserve.
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.
What website owners should do now
I would not suggest that every website owner rush into an experimental browser API because a switch has appeared in a dashboard.
I would start one step earlier.
Ask 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. Define bounded inputs and outputs. Decide which sources are authoritative. 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.
The delivery mechanism should follow the governance decision, not replace it.
The agent-ready web is becoming real
The most important part of Cloudflare's announcement is not the injected script or the dashboard switch. It is the signal.
Agents are becoming a real category of web user. Browsers, infrastructure providers, agent frameworks, publishers, merchants, and website platforms are beginning to work out how this new relationship should function.
Scraping and simulated clicking will not disappear. Agents will still fall back to those methods when no better interface exists.
But websites now have an opportunity to offer something clearer.
They can tell agents what is available. They can provide typed inputs and structured results. They can keep the human interface intact. Most importantly, they can decide what should and should not be exposed.
Cloudflare is making it easier to deliver that interface.
Open for Agents is focused on the layer before delivery: discovering the real capabilities, reviewing them, applying the owner's boundaries, and publishing a consistent approved surface.
The future web will not be used only by people manually clicking from page to page. Personal assistants will browse, compare, monitor, and act for us.
Website owners need to be part of deciding how that future works.
That is why WebMCP matters. It is also why a simple WebMCP switch makes governance more important, not less.