Scraping is not about to die, although the button an agent spends twenty seconds hunting for in a screenshot may have a less secure future.
On August 6, 2026, Cloudflare announced a developer preview that can add a WebMCP interface to a domain from its dashboard without changing code at the origin.1 The pitch compresses neatly: rather than making an agent read a page like a determined but slightly confused human, locate the correct field, click a control and hope the DOM still resembles yesterday's version, the site can declare tools directly.
search_products. create_ticket. book_flight. A name, a description, an input schema and executable behaviour.
For browser automation the change is substantial; calling it the end of scraping, by contrast, hides the useful part of the idea.
The wrong replacement
An agent acting on a website without a purpose-built API has several options today. It can inspect the DOM, read the accessibility tree, analyze screenshots, search visible text, estimate where to click, fill forms and observe what changed afterwards.
The remarkable thing is how often this works, given how much infrastructure may be required merely to make a machine open a menu whose underlying application already knows exactly what that menu does.
A CSS class changes, a button moves, a modal arrives late, or an asynchronous step produces a different state and the agent has to reinterpret the interface. Visual models make this less brittle, but they buy flexibility with tokens, latency and ambiguity. Chrome frames WebMCP around precisely this problem: instead of guessing the purpose of a button or input, a web application can declare the action and the state around it.3
In the face of all that page-reading machinery, the useful distinction is action.
WebMCP does not say browser agents will stop observing web pages. The draft specification describes an implementation-defined “observation” delivered to a browser agent and explicitly notes that, alongside registered tools, a browser may include annotated screenshots, parts of the accessibility tree and other useful page context.2 Even a WebMCP-aware agent may therefore continue looking at the interface.
What the API adds is a structured lane for capabilities. Everything the site has not declared still needs some other route to understanding.
A news story does not need a tool to be read. An old documentation page can still be indexed. A shop that implements nothing will still be driven through its UI or a discovered backend API. A crawler extracting millions of documents from servers gains little by opening a full browser session for every page.
We have blurred content scraping and UI automation because HTML has often been used for both. WebMCP is much more directly aimed at the second problem.
A local tool
The imperative API is pleasantly small. JavaScript running in a page calls document.modelContext.registerTool() with a name, description, JSON input schema and an execute function.2
A browser agent can discover those definitions and call one with structured arguments, while the code that performs the action remains part of the site's application. It may update local state, call fetch, use an authenticated service or compose several internal operations.
By contrast with a conventional public API, the action can remain inside the application context that already owns the workflow.
Building an API generally means designing an endpoint, choosing authentication, documenting another contract and maintaining it beside the application. WebMCP can expose functionality that already lives in the client context, with the browser session and application state close at hand.2
State ownership changes with that choice, which is more consequential than the small JavaScript surface first suggests.
An agent may arrive without a separate API credential and act inside a browser session that is already authenticated. The security section of the draft explicitly assumes browser agents may inherit user identity and authentication context.2 That assumption is convenient enough to make WebMCP interesting and dangerous enough to explain why the browser has to be more than a dumb transport.
Not quite MCP
The name contains a small architectural trap, because the proposal borrows an MCP-shaped tool model without requiring an MCP-shaped transport.
Model Context Protocol defines a client-server protocol with initialization, messages, transport and primitives including tools, resources and prompts. WebMCP adopts the idea and shape of tools, yet the current design does not require MCP's data layer between the web page and the browser agent.5
The draft goes further: browsers are free to expose a page's tools to their agent through MCP, proprietary function calling, or another mechanism they consider appropriate.2
A WebMCP interaction can therefore happen without an MCP message crossing the page-agent boundary at all.
That separation is deliberate. In the project's design discussion, contributors argue that having the browser understand tool definitions avoids coupling the Web to a specific MCP protocol version and lets the browser impose web-specific security rules around capabilities and cross-origin frames.5
The name still makes sense because the tool model belongs to the MCP ecosystem and bridges can translate between the two. Architecturally, however, standardized function calling for web pages is often a clearer mental model than “an MCP server inside every tab”.
This matters for interoperability. An MCP-capable agent still needs a compatible browser or adapter to understand a WebMCP page, while the page itself is a different thing from a remote endpoint accepting tools/list over HTTP.
Some component still has to bridge those worlds, and in Cloudflare’s preview that component is deliberately visible.
Cloudflare's bridge
Cloudflare is building exactly that bridge.
Its preview leaves the site repository untouched, and there is no attempt to infer a complete agent API from every button on the page. When a domain enables WebMCP, Cloudflare uses HTMLRewriter at the edge to inject a reference to /.webmcp/bridge.js into HTML responses.1
The bridge checks for the WebMCP surface in the browser. If it is absent, nothing else happens; if available, the script registers groups of tools that Cloudflare calls packs.1
Here the wording “Give any website a WebMCP interface” deserves a careful reading. In the August preview, Cloudflare is not turning arbitrary site functionality into tools by inspecting the DOM. It ships two specific packs.1
One reads C2PA Content Credentials from images. The other is a Site MCP Server client: if the domain already exposes an MCP server, by default at /mcp, the bridge discovers its tools and registers WebMCP proxies in the page. Calling one of those proxies sends the request back to the site's MCP endpoint.1
That is more useful than pretending an edge service can infer every business action safely. Cloudflare lowers the integration cost between a browser agent, a page and an MCP server the site already controls; the business logic still belongs to the site.
A refund_order tool still requires somebody to implement the refund. Even the agentic web, in a rare concession to reality, cannot escape the backend.
Your session
Running the bridge in the page gives Cloudflare another useful property. Its example proxy calls the site's MCP endpoint same-origin with credentials: "same-origin".1
A tool can therefore reuse the user's existing session instead of forcing an agent to hold a second credential merely to access the same account currently open in the tab. “Cancel my latest order” may become an action within the current site rather than an abstract API integration maintained somewhere else.
At the same time, the security stakes rise because the tool can inherit an authenticated session rather than merely point at a public control.
A mistaken visual click on a public page may merely produce nonsense. A structured tool in an authenticated session can send a message, change a profile, buy something or delete data. Making the contract more reliable also makes an incorrect decision reliably consequential, because progress remains committed to finding new ways to make mistakes deterministic.
The draft integrates a Permissions Policy feature named tools, whose default allowlist is self, and includes origin rules governing which documents can expose tools across contexts.2 Those controls matter for frames and provenance, but they do not by themselves answer whether the user intended a particular purchase or submission at a particular moment.
The declarative WebMCP proposal explores a more visible form of mediation. It adds attributes such as toolname and tooldescription to HTML forms; unless the author opts into toolautosubmit, an agent can fill the form but should leave the final submission for the user to inspect and perform manually.4 Add toolautosubmit and that last human step can be removed.
That proposal remains under active design. The explainer still marks details such as exact schema synthesis for form controls and some cross-document response behaviour as unresolved, while Chromium is using experimentation to test the approach.4 Chrome's public programme is an origin trial, not a declaration that this API shape will stay unchanged for fifteen years.3
Forms can compile
The declarative proposal matters because registerTool() is not the only way its authors imagine sites participating. A developer may already have a real HTML <form> describing the workflow, complete with field names, input types, allowed values and validation constraints; rather than duplicating that entire contract in JavaScript, the browser can derive a tool schema from the form itself.4
In effect, the human interface becomes source material for the agent interface.
An email input already says something useful about the expected value, a select already contains an enumeration, and required already expresses a constraint. Over the last three decades the platform accumulated semantic information for forms because browsers, assistive technology and people needed it; WebMCP can reuse part of that information instead of asking every site to maintain a second description of the same transaction.4
This sounds like implementation detail until maintenance enters the room. If every WebMCP integration required a team to rewrite all fields, validation rules and choices into another JavaScript schema, an agent interface would quickly become another product surface that drifts away from the visible application. Deriving tools from semantic HTML creates the opposite incentive: keep the underlying form intelligible and the browser can translate more of it.
To be sure, this is still a proposal rather than settled platform behaviour. The explainer leaves some JSON Schema synthesis rules open and continues discussing how results should behave when submission navigates to another document.4 The direction is nevertheless notable: instead of always adding a parallel API, make more of the structure the web already has legible to agents.
The actual power
If WebMCP becomes common, its most consequential change may be less about agent reliability than about who defines the agent-facing interface.
With scraping or visual actuation, a site publishes a human UI and an agent decides how to interpret it. Developers can improve semantics and accessibility, but they do not necessarily declare which actions should be considered stable capabilities for a machine.
WebMCP lets the site choose that vocabulary.
A retailer can expose search_products without exposing export_all_prices. A bank could offer structured transaction search while keeping money movement behind another layer. A developer tool might publish a diagnostic action while requiring human approval for destructive repair.
The site regains some control lost when agents began treating every interface as something to reverse-engineer, including the power to leave capabilities undeclared.
Cloudflare also frames WebMCP as a way for creators to keep traffic and attribution because the agent visits the site rather than relying entirely on a remote crawler.1 For the pathway Cloudflare describes, that is technically true: the page loads, its bridge executes and same-origin calls return to the site's infrastructure.
Keeping traffic, however, is not the same as keeping attention.
An agent can open a page, call search_products, collect three results and answer inside its own chat interface without the human seeing an ad, understanding the site's navigation or reading the editorial material around those products. The server receives a visit; the media product may receive no human attention at all.
WebMCP improves the site’s technical position; whether that visit produces human attention or revenue remains a separate problem.
A new risk
A declared tool stops an agent guessing where to click, yet the tool description itself becomes part of the trust boundary.
The draft security section calls out prompt injection in tool metadata, inputs and outputs as a central risk.2 A description is no longer documentation read only by a developer; the model choosing a capability may receive that text directly among its decision inputs.
A malicious site can register a reassuringly named tool whose description attempts to manipulate the model. A compromised application may poison metadata. A legitimate tool can return user-generated text containing adversarial instructions. JSON gives the parameters shape, but natural language remains natural language, with all the traditional human invention of telling somebody to ignore the previous sentence.
The same draft assumes browser agents may correlate information across sites and may have access to identity, browsing history, payment information and other sensitive context.2 It also acknowledges that precise mitigations are split among sites, browsers and agent providers; much of the security discussion remains non-normative.2
Compared with an ordinary server API, the browser has extra work to do. OAuth scopes and ACLs can constrain an identified client, while an agentic browser also has to account for tool origin, the trustworthiness of its description, current human intent and the consequence of the call.
Reliable actuation and reliable judgement remain separate properties, however appealing it would be to purchase them as one feature.
What remains
WebMCP is still young. Chrome announced an early preview in February 2026 and an origin trial in Chrome 149 in June, while Cloudflare notes that the experimental surface had been available since Chrome 146.361
The Community Group draft is evolving. The declarative API has open questions, cross-origin and security behaviour continue to receive work, and browsers are not required to expose tools to their agents through the same internal mechanism.24
More importantly, WebMCP only covers capabilities that a site chooses and manages to expose.
The old web does not disappear when Chrome gains a new API. Billions of existing documents will still be read through DOM extraction, accessibility, rendering or crawlers. Sites hostile to automated access are unlikely to publish a friendly download_everything tool. Abandoned applications will not acquire structured capabilities through telepathy. Services that already have strong APIs will keep good reasons to expose those APIs or a remote MCP server directly.
The agentic web will be hybrid, which is the web's traditional method of adding a standard without removing any previous layer.
Still, the layer addresses a real problem that visual automation has made painfully obvious.
A third interface
Web services have long had two interfaces: a graphical UI for people and an API for programs. Agents created a third kind of user that fits neither category cleanly.
They understand language and can inspect screens, so we hand them the human interface. Then we expect structured, repeatable program-like reliability and express surprise when an intelligent model spends six steps locating a “Confirm” button whose backend knew the meaning of all along.
WebMCP's answer is fairly modest: let the application declare a capability interface inside the page where user state and session already exist.
The interface can coexist with the DOM and dedicated APIs, and its usefulness does not depend on carrying MCP messages end to end.
Its job is to stop an agent reconstructing the semantics of a known application from pixels and element trees on every visit.
Scraping will remain where nobody cooperates. Dedicated APIs will remain cleaner for server-to-server integrations. WebMCP can occupy a very specific middle ground: an authenticated site is already open, an agent is acting alongside the person, and the application would rather declare what it can do than make a model guess where to click.
That is not the end of the human web.
It may be the beginning of the end for the slightly absurd requirement that every software agent pretend to be human before it is allowed to press a button.