Today's AI web browsing: scraping content, or guessing buttons from screenshots

Web pages were designed from day one for "a person looking at a screen"—someone who reads text, clicks buttons, and fills out forms.

Now, more and more visitors are AI agents. How do they use these human-oriented pages? Right now, there are only two paths, and neither is great.

Path one is scraping. The agent copies the entire page back to its server for parsing. This is the worst outcome for site owners: your content is taken, traffic disappears, and attribution is lost.

The common practice is a crawler that copies content back to a server, often without sending a single visit to the original site or giving proper attribution. There's a better way, and it doesn't require scraping.

Cloudflare Blog · Give any website a WebMCP interface

Path two is screenshot-analyze-click. The agent mimics a human: takes a screenshot, uses a model to parse the layout and find the search box, clicks, screenshots again, analyzes again. It's slow, brittle, and burns most of its tokens on "navigation" rather than getting things done. A single redesign breaks the entire flow.

WebMCP proposes a third path: the website proactively tells the agent, "Here are the tools you can call," e.g., "search flights," "book tickets," with clear parameter specs. No guessing—just direct calls.

WebMCP lets sites list capabilities as tools for AI to call

First, its identity: WebMCP is a browser standard proposal, currently incubating in a W3C community group. It's not a final standard yet. Chrome's status page still lists it as "Proposed."

On a page, it manifests as an interface called document.modelContext. Websites attach tools to this interface, which agents in the browser can then discover and invoke.

There are two ways to attach tools, and they differ significantly in effort:

One is to write JavaScript, calling registerTool() with the tool's name, description, parameter schema, and execution logic. Complex interactions require this approach.

The other is far simpler—just add a few attributes to the HTML forms you already have. Add toolname (what the tool is called) and tooldescription (what it does) to a booking form, plus toolparamdescription (what each field is for) on each input. The browser automatically turns it into a callable tool for agents, complete with a generated parameter spec.

Tools Change with the Page; Payment Pauses for Human Confirmation

Reading the spec is one thing. Seeing it work is another. Cloudflare's own remote browser docs include a walkthrough using Google's official hotel booking demo, and two details surprised me.

First, the tool list is not static. When the page first loads, only three tools exist: view hotel details, search by location, and lookup amenities. After you call "search by location" for Paris and the page jumps to search results, a new tool—"filter search results"—appears. Tools follow the page's state.

Second, sensitive operations halt the agent. Calling the "complete booking" tool doesn't finalize anything. It stops, waiting for you to click the "Confirm Reservation" button in the browser. This is a built-in human confirmation mechanism.

Cloudflare's Approach: Inject a Script While Your Page is in Transit

Now that we've covered the standard, let's look at what Cloudflare actually did. Its implementation has two parts, both operating in front of your origin. Your code doesn't change. Static sites and SPAs work the same way.

Part 1: Inject a script at the edge

Flip the toggle in your dashboard, and before each HTML page is delivered from Cloudflare's servers, it gets this line appended:

<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

The tool that does this is HTMLRewriter, Cloudflare's HTML rewriting engine that runs while pages are in transit. Your origin server is completely unaware and needs no cooperation.

Part 2: The bridge.js shim

It runs inside the page. Its first job is to check if the browser has the WebMCP interface. If not, it returns immediately and does nothing—the page is indistinguishable from before. If yes, it merges the packs listed in data-packs into a single tool manifest and registers them one by one.

Two Built-In Packs: Check Image Provenance, Proxy Your MCP Server

Tools are grouped into "packs"—related sets that toggle together. The preview ships with two packs, both running entirely in the visitor's browser without routing through Cloudflare's servers. When new packs arrive, sites just check a box in the dashboard—no redeploy needed.

Pack 1: Find out who made the images on a page

This pack reads C2PA data embedded in images—an industry standard for "birth certificates" for pictures: who generated it, whether it's AI-made, and who's edited it since, all stored in the image file's metadata header.

The pack includes two tools. scan_images_c2pa scans all images on the page and returns a summary. Cloudflare's example output: 12 images scanned, 8 with C2PA data; each lists its source, e.g., hero.jpg was generated by Adobe Firefly, signed by Adobe Inc. The other tool, inspect_image_c2pa, digs deep into a single image to extract the full record: edit history, claimed author, and signing certificate.

Technically, it's a pure TypeScript reader that touches only the first few KB of metadata—no full image downloads.

Pack 2: Bring your MCP server into the page

If your site already has an MCP server—and many companies have built one over the past couple of years—this pack starts by asking /mcp, "What tools do you have?" After getting the list, it proxies each existing tool as-is onto the page: name, description, and input schema all pass through unchanged.

This marks the key difference between the two packs. The image tool's definitions are pre-declared; the MCP pack's tools are discovered dynamically.

document.modelContext.registerTool({
  name: tool.name,                 // e.g. "search_products"
  description: tool.description,
  inputSchema: tool.inputSchema,   // your schema, passed through
  execute: async (args) => {
    const res = await fetch(mcpUrl, {   // same-origin /mcp
      method: "POST",
      credentials: "same-origin",       // ← carries the visitor's current session
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0", id: 1, method: "tools/call",
        params: { name: tool.name, arguments: args },
      }),
    });
    const { result } = await res.json();
    return result;   // return the result untouched
  },
});

From the agent's perspective, these are all standard MCP tools. Cloudflare uses MCP's native data types, so any agent that already speaks MCP can operate the page without any additional setup.

There's also a hint about the roadmap: bridge's code is served by a Cloudflare Worker. This leaves room for future packs where the Worker handles things the page can't do alone, like summarizing an entire sitemap with Workers AI or querying the AI Search index.

Where to Find the Toggle and How to Verify It Works

Dashboard path: Cloudflare Dashboard → Agent Readiness → Labs (still carrying a Beta tag). That Labs page describes itself as "experimental features you can opt into, for making your site work better with AI agents."

The dashboard looks like this: a master toggle on top, two pack checkboxes below it, both checked by default. Unchecking all of them equals the default set. Image from the Cloudflare blog.

To confirm it's live, one command: request any page from your site and check for the injected line:

curl -s https://your-site.example | grep webmcp

To see tools actually being called, you don't need to build an agent yourself. Point Browser Run—Cloudflare's cloud-hosted remote browser—at your URL. It will discover and invoke the tools just like a visitor's agent would. One caveat: WebMCP is only in Chrome Beta for now, so you'll need to spin up a dedicated experimental session.

Tested: Today's Stable Chrome Does Not Support WebMCP

So, you can turn it on—but does the visitor's side currently recognize it? Let's clear up the messaging.

The Cloudflare blog says WebMCP is "experimentally available in Chrome 146." That's already outdated: Chrome's official docs state the WebMCP origin trial starts with Chrome 149. Sites can register with Google to enable the feature for real users, rather than just toggling a local flag. And as of today, Chrome stable is already at version 151.

So can it be used? I tested it locally. My test page included Chrome's required isolation response header, satisfying the interface's prerequisite:

That doesn't make this useless—"developer preview" is exactly what this is. The value today is that you can prepare your site at zero cost, not that agents will flock to it tomorrow. Chrome lists a target milestone of 157 for this feature, and its status is still "Proposed."

For what it's worth, I also checked Cloudflare itself: their blog, main site, and Radar have not enabled this feature. Radar's own WebMCP tools haven't launched yet, with a release timeframe of "soon."

Chrome's Official List of Three Limits: An Open Page is Required for Tool Calls

The standard also has hard constraints, listed in the "Limitations" section of Chrome's official docs. These come from the people building the standard, so they carry more weight than any third-party critique:

There are also two security constraints: WebMCP only works on pages with origin isolation (disable it, and the interface goes away). Tool registration is also governed by a permissions policy that, by default, only allows top-level and same-origin pages to register. Cross-origin iframes are blocked by default; they'd need explicit permission to register tools.

Back to the original question: is the toggle worth flipping now? The cost is zero—click, no origin changes, silent fallback if unsupported. So the real question becomes another one: besides the two generic packs, do you have your own MCP server to connect? That's the pack that lets an agent actually get things done for users on your site. The image credential scanner is a nice bonus.

WebMCP itself is an in-development browser standard; supporting it normally requires writing your own code. Cloudflare has taken over that step: flip a switch in the dashboard, and your origin code remains untouched—no redeploys.

It injects the script while your page is in transit. Before the HTML moves from Cloudflare's edge to the visitor's browser, a script tag is added, served from your own domain. The script checks whether the browser has the WebMCP interface: if not, it exits immediately and the page is unchanged; if yes, it merges the selected packs into a tool manifest for the AI.

The preview includes two packs, both running in the visitor's browser without routing through Cloudflare's servers.

The second pack is more substantial: if you already have your own MCP server, this pack proxies its tools into the page as-is—names, descriptions, and parameter schemas included.

On 2026-08-07, I tested with the latest local Chrome.

Flip the toggle today, and the script will be injected. But most visitors' browsers don't have this interface at all. The script detects it, exits, and the page is unchanged. The only ones who can benefit are browsers with experimental flags on, and cloud remote browsers running Chrome Beta.