Cloudflare shipped a WebMCP feature in August 2026. It is a toggle in the dashboard. No code, no build step, no change to your origin.
Most of the coverage stops at that sentence. I wanted to know what it actually puts on the page, so I took a byte-level snapshot of my site, turned the toggle on, and measured the same things again.
Here is what changed, and the part nobody mentions: the toggle gives you a bridge, not tools.
- It adds 115 bytes. One script tag, injected at the edge. My homepage went from 144,290 to 144,405 bytes.
- You get two tools, and they are about images. Both come from the Content Credentials pack. Neither has anything to do with what my site is for.
- The interesting pack registered nothing. Site MCP server looks for an MCP endpoint at
/mcpon your own origin. Mine returned HTTP 405, so it registered zero tools and said so in the console. - It does not move your Lighthouse score. 0.94 before, 0.94 after. Exactly what the weights predict. The visibility number that does move is whether AI answers name you, and ContextBolt SEO is how I check mine.
- Nothing happens on a normal browser. The bridge does not polyfill. No API, no tools, one console note.
What the toggle actually does
The setting lives under Agent Readiness in the Cloudflare dashboard. Flipping it changes nothing in your repository. Cloudflare rewrites your HTML on the way out, at the edge, and injects a single element into the head:
<script type="module" src="https://yoursite.com/.webmcp/bridge.js" data-packs="c2pa,mcp-server-client"></script>That is the whole injection. It is 115 bytes, and I can be precise about that because I measured the same page before and after: 144,290 bytes to 144,405 bytes. The difference is exactly the tag.
Two things about it are worth noticing.
The script is served from your domain, not Cloudflare’s. It sits at /.webmcp/bridge.js on your own origin, which means no third-party domain shows up in your page, and your Content Security Policy does not need a new entry.
The data-packs attribute is your configuration. The tool packs you tick in the dashboard become a comma-separated list on the tag. Mine reads c2pa,mcp-server-client because I enabled both.
The bridge itself is 47,616 bytes of JavaScript. It came back with cf-cache-status: HIT, so it is served from Cloudflare’s edge cache rather than from your origin on every page view.
What your site offers an agent afterwards
This is the part I expected to be more interesting than it was.
WebMCP works by a page registering tools that a browser-based agent can call, instead of the agent reading your DOM and guessing which button to press. The full picture of how that differs from a server-side MCP server is in WebMCP vs MCP.
So: after turning the toggle on, what tools does my site register?
I ran the live site in Chrome 151 with experimental web platform features enabled and asked the API directly. Two tools:
| Tool | What it does |
|---|---|
scan_images_c2pa | Scans every <img> on the page for C2PA Content Credentials and returns a per-image summary |
inspect_image_c2pa | Fetches one image and returns its fully decoded C2PA manifest store |
Both come from the Content Credentials pack. They read content-provenance metadata out of images: who made a picture, whether it was edited, whether it was AI generated.
That is a genuinely useful capability if you run a news site or a stock library. On a software company’s marketing site it is close to meaningless. Nothing about my pricing, my docs, my search or my product is exposed to an agent, because none of that is what the pack does.
The toggle did not make my site agent-operable. It made my images inspectable.
The pack that registered nothing
The other pack is the one that sounds like it matters. Cloudflare describes Site MCP server as proxying “your site’s own MCP server tools to the in-browser agent”. If your site already has an MCP server, this pack hands its tools to the agent in the page.
Mine registered zero tools. The bridge said so plainly in the console:
[webmcp-interceptor] Registered 2 static tool(s); resolving dynamic packs…
[webmcp-interceptor] mcp-server-client: tools/list failed for "/mcp";
registering no site tools. Error: MCP endpoint returned HTTP 405
[webmcp-interceptor] Registered 0 dynamic tool(s) from 1 dynamic pack(s).The pack looks for an MCP endpoint at /mcp on the same origin and calls tools/list against it. On my domain, /mcp is a marketing page. It answers GET with a redirect and POST with a 405, because it is HTML and not a JSON-RPC endpoint.
We do run an MCP server. It lives on a different subdomain, behind authentication, because it is a paid product with per-call costs. The pack cannot reach it and should not be able to.
That is the honest shape of this feature. The pack that could expose what your site is actually for requires you to build and host an MCP server at a specific path on the same origin. The toggle does not build it. It only connects to one if it is already there.
Worth saying out loud, since I checked before writing this: a pack that finds nothing fails safe. It logs a warning and registers nothing. It does not go hunting on other origins, and enabling it did not expose anything that was not already public.
Nothing happens on a normal browser
The bridge does not polyfill the API. I loaded the same live page in Chromium 146, which is below the origin trial floor, and the tag was there, the script loaded, and no modelContext object existed. What you get instead is a console message telling you to turn on an experimental features flag.
So the state of things today is that the tag ships to every visitor, and for almost all of them it does nothing at all. WebMCP is in a Chrome origin trial that runs through Chrome 156.
One detail I can correct while I am here, because I measured it and the guides disagree. On Chrome 151, document.modelContext and navigator.modelContext are the same object. Strict equality returns true, modelContext is present on both Document.prototype and Navigator.prototype, and both report a ModelContext constructor. The W3C draft defines the interface on Document, so that is the one to write, but a navigator example will not silently fail on you the way several write-ups claim.
The methods on it are registerTool, getTools, executeTool and ontoolchange.
It does not move your Lighthouse score
Lighthouse 13 has an Agentic Browsing category, and the loudest claim in the SEO coverage of WebMCP is that implementing it lifts your agentic score.
I have written about why that is wrong: all three WebMCP audits in that category carry a weight of zero. This was the cleanest possible test of that finding, because I had a before number.
My homepage scored 0.94 before WebMCP was on. It scored 0.94 after.
The three WebMCP audits are still notApplicable, because default Chrome does not have the API on. The three audits that carry weight are the accessibility tree, Cumulative Layout Shift and llms.txt, and none of them care whether you registered a tool.
If you are turning WebMCP on for a score, do not. There is no score in it.
What it costs you
Two things worth watching, neither of them alarming.
Page weight. 115 bytes in the HTML, plus a 47 KB module fetched once and cached at the edge. On a site where the homepage is already 144 KB, the tag is a rounding error.
Requests. Every page view now also fetches the bridge file. It came back as an edge cache hit rather than an origin request, so it should not add origin invocations, and the injection happens on responses you were already serving. I could not detect a change in my 30-day request counter, but a 30-day rolling window cannot resolve ninety minutes, so that is a measurement I do not yet have. If you are near a request limit, watch your own counter across a full day rather than trusting anyone’s blog post, including this one.
Check yours in two minutes
Every number above is reproducible, and you should reproduce it rather than take my word for it. Four commands.
See the injection. This prints the tag Cloudflare added, and nothing at all if the toggle is off:
curl -s https://yoursite.com/ | grep -o '<script[^>]*webmcp[^>]*>'Measure the cost. Run this before you flip the toggle and again after. The difference is what it cost you:
curl -s https://yoursite.com/ | wc -cCheck where the bridge is served from. A cf-cache-status: HIT means the edge is answering rather than your origin:
curl -sI https://yoursite.com/.webmcp/bridge.js | grep -i cf-cache-statusAsk the page what it registered. Open your site in Chrome with experimental web platform features enabled, then in the console:
await document.modelContext.getTools()That last one is the only check that matters, and it is the one nobody runs. It returns the actual array of tools an agent would see. If it comes back with two image tools and you were expecting your product’s functionality, now you know before a customer does.
While you are in the console, read the messages the bridge logged. It tells you exactly which packs resolved and which found nothing, and it is far more direct about failure than the dashboard is.
What to do if you want real tools
The gap between “WebMCP is on” and “an agent can use my site” is an MCP server at /mcp on the same origin, answering JSON-RPC. That is a build, not a toggle.
If you already run an MCP server somewhere else, as we do, you have a decision rather than a task. Ours is authenticated and metered because each call costs us money at a data provider, so proxying it to anonymous in-browser agents on the marketing site is not something we want. A same-origin endpoint would need to be a deliberately separate, cheap, read-only surface.
That is the real question this toggle asks you, and it is a better question than the one the coverage is asking. Not “should I enable WebMCP” but “what would I actually want an agent to be able to do here, and am I willing to serve that anonymously”.
For most marketing sites the honest answer is a small set of read-only things: search the docs, look up a price, check availability. None of that needs the toggle to be decided, and all of it needs building either way.
Should you turn it on?
Yes, if you accept what it is.
It is a two-minute change that puts your site on the right side of a standard that Chrome, Microsoft and a list of large retailers are actively testing. It costs almost nothing, it breaks nothing, and it fails quietly on browsers that cannot use it.
But be clear about what you have done. You have installed a socket, not an appliance. The tools that would make your site genuinely useful to an agent, the ones specific to what your product does, come from an MCP server you have to build and expose yourself. Until then, an agent that visits your site can inspect your images and nothing else.
That is still worth doing. Just do not write a launch post about it.