WebMCP: Give AI Agents a Real Door Into Your Site, Store, or Platform

Every digital interface we ship is optimized against friction. Catalogs became websites so buyers didn’t wait for the mail. Forms grew autofill so nobody retyped a shipping address. Checkout collapsed from seven steps to a guest path. Mobile put the store in a pocket. An Application Programming Interface (API) let one system talk to another without a person copying fields between screens. The companies that won were rarely the ones with the slickest skins. They were the ones that removed a step.

That campaign is now running into a new kind of visitor. People still land on pages, click, and buy. They also ask an agent to do the work: find the plan, compare SKUs, fill the form, check the order, file the ticket. The agent sits in a browser designed for eyes and a mouse. It screenshots the page, guesses at labels, misreads a date picker, and burns tokens walking a menu a human would skip. When that fails, the user does the work anyway, and the site looks like the problem.

The interface problem did not go away. It changed audience.

WebMCP

Web Model Context Protocol (WebMCP) is the next move in that same strategy. It is a browser standard that lets a site expose structured tools to agents in the page a person is already looking at, so the agent can help the user instead of scraping a user interface (UI) it does not understand.

Friction Was Always the Strategy

I have written before about machine-to-machine (M2M) communication as the real backbone of digital products. In SaaS Isn’t Dead. Your UI Is. I made the case that the subscription and the data still matter, and that the dashboard sitting on top of them is often the expensive part. Where a clean API exists, an agent finishes the work in seconds. Where only a UI exists, the same agent can still drive a browser, but it is the slow lane: screenshots, guessed clicks, confirmation dialogs, and a pile of tokens spent on navigation instead of the actual task.

WebMCP is that argument brought into the page. Anthropic’s Model Context Protocol (MCP) already gave agents a standard way to call tools on a server. WebMCP uses the same tool shape (a name, a description, a JavaScript Object Notation (JSON) Schema, an execute function) and puts it on the document the user is looking at. The page itself becomes a set of named, typed actions. The person stays in the loop. The traffic stays on your origin. The agent stops pretending it can read your stylesheet.

That last part is the whole point for a Software as a Service (SaaS) team, an e-commerce operator, or a publisher. You already invested in an interface humans can use. Agents are now part of that interface’s audience. If you do not give them a door, they will kick at the windows: crawl the Hypertext Markup Language (HTML), scrape the Document Object Model (DOM), screenshot the pixels, and invent a path through your product you never designed. Some of those paths will work. Many will not. All of them waste the user’s time and your support budget.

Removing friction has never been a feature list. It is the strategy. Search instead of a directory. One-click instead of a wizard. An API instead of a CSV emailed to ops. WebMCP is the same instinct applied to a visitor who doesn’t have a mouse, doesn’t share your mental model of the nav, and will happily spend a dollar of compute clicking the wrong filter if you don’t tell it which tool to call.

What Happens When a Site Has No Door

Watch an agent work a site built only for humans, and the failure mode is obvious. The model has to reconstruct your product from pixels and markup. A Single Page Application (SPA) that hydrates after load looks empty on the first pass. A date picker that is really a custom widget looks like a text field. A Continue button that is actually a <div> with a click handler does not show up as a form submit. Multi-step checkout hides the payment fields until shipping validates. The agent retries. The session expires. The user takes over, and you lose the conversion you were supposed to help.

Chrome’s own write-up on the problem is blunt: actuation (an agent simulating mouse clicks and typing as if it were the user) is slow, brittle, and open to interpretation at every step. WebMCP is the alternative. The site declares the purpose of an action, the inputs it needs, and the function that runs it. The agent calls search_products with a query string instead of tabbing through a mega-menu. It calls start_booking instead of hunting for a calendar icon. Sensitive steps can pause for confirmation. That is human-in-the-loop (HITL) as a first-class part of the protocol, not a screenshot of a modal the model might miss.

The difference is not academic. Without structured tools, every UI redesign is a breaking change for agents. A new class name, a moved button, A/B test on the CTA, a cookie wall: any of those can send an agent down a dead path. With tools, the visual design can change every sprint. The contract stays the same: the name, the schema, and the execute function. That is how APIs survived twenty years of UI churn. It is how agent-facing pages will survive the next twenty.

There is a business cut as well. Crawlers copy a page back to a server and often return none of the traffic and little of the credit. A browser agent that works on your site still loads your ads, still hits your analytics, still sits in a session you can authenticate, still converts on your checkout. Cloudflare put it this way when it launched a developer preview of WebMCP at the edge in August 2026:

The web was built on the assumption that there is a person on the other end: someone to read the page, click buttons, and fill in the forms.

Will Rowe, Cloudflare

Agents are now on the other end too. You can treat that as a scraping problem, or you can treat it as an interface problem and give them a proper door.

The Standard, Not Another Widget

WebMCP is not a vendor SDK. It is a draft from the Web Machine Learning Community Group at the World Wide Web Consortium (W3C), with editors from Microsoft and Google. The draft describes a ModelContext object in the document. A page registers tools. An agent (or a page-hosted assistant, or an assistive technology) lists those tools and calls them. Unregistration is an AbortSignal. Cross-origin use is off by default and gated by a tools permissions policy plus an explicit exposedTo list of origins.

There are two ways to put a tool on a page.

1. The declarative API is for work that already lives in a form: search, signup, contact, reserve a table, file a ticket. You add toolname and tooldescription to the <form>, and optionally toolparamdescription on fields and toolautosubmit if the agent can submit without a person tapping the button. The browser synthesizes a JSON Schema from the inputs and registers the form as a tool. When the agent calls it, the form stays visible, the fields fill in, and the user can see what is about to happen. If you skip toolautosubmit the browser parks focus on the submit control and waits. That is the right default for a purchase, a password change, or anything you would not want an agent to fire in the background.
2. The imperative API is for everything a form cannot express. Account state, filters that rewrite a result set, a diagnostic that lives three menus deep, a tool that should exist only while the cart has items. You call document.modelContext.registerTool with a name, a description, an input schema, and an execute function. Tools can come and go with the route. Google’s Chrome docs show the pattern with pizza layers, order status, and a to-do list. React and Angular already have experimental hooks that tie registration to component lifecycle, which is exactly what a dashboard needs.

Chrome is implementing it. An origin trial is available, and a local flag at chrome://flags/#enable-webmcp-testing turns the surface on for development. Cloudflare’s remote browser (Browser Run) can attach to a lab session and drive the same APIs. None of that makes WebMCP a Chrome-only trick. The point of a community-group draft is that any browser with an agent can speak it. The reason to adopt it now is the same reason people adopted RSS, OpenAPI, and MCP before the ink was dry on a Recommendation: the clients are already here, and the sites that speak the language get used.

One distinction is worth keeping clean. MCP is usually a server you connect from an agent runtime (stdio, HTTP, a remote endpoint). WebMCP is the same idea running in the page, in the user’s session, against the UI the user can still see. You can have both. In fact, Cloudflare’s edge bridge will proxy a same-origin MCP server into WebMCP tools if you already run one at /mcp. That is how a product team that invested in MCP last year gets a browser door without rewriting the tools.

How to Tell If a Site Has It

You do not need an agent to see the first signal. If the site is on Cloudflare and the WebMCP toggle is on, the edge injects a module script on HTML responses. On Martech Zone, that line is already in the head of the homepage and of articles:

curl -s https://martech.zone/ | grep webmcp

You should see a tag pointing at /.webmcp/bridge.js with a data-packs attribute. Ours currently loads the two preview packs: c2pa (Content Credentials) and mcp-server-client (a proxy for a site MCP server). The script is same-origin. If the browser has no WebMCP surface, the bridge returns and the page behaves exactly as it did yesterday. Humans notice nothing. That is the right kind of progressive enhancement.

A native implementation will not always inject that Cloudflare script. Those sites register tools themselves. In a WebMCP-capable browser, open DevTools and run:

await document.modelContext.getTools();

An empty list means the page has not registered anything yet (or the flag is off). A list of names, descriptions, and schemas means the door is open. Chrome also ships a Model Context Tool Inspector extension that lists tools, lets you call them by hand, and can prompt an in-page agent so you can watch whether it picks the right tool for a sentence like find a hotel in Paris with breakfast. Tools change with page state, so you re-list after each action. A search tool might yield a filter tool. A filter tool might yield a checkout tool. That lifecycle is the product.

No public directory is complete enough to trust. Discovery happens when the agent (or the inspector, or your own script) actually visits the page. That is a limitation of the current draft, and it is also a feature: tools are session-aware, permission-aware, and allowed to disappear when the user logs out. A badge in the footer would be marketing. The contract is the tool list.

What Agents Can Do With a Real Door

The capabilities are not a vendor feature matrix. They are the jobs you already asked humans to do, described so an agent can help without guessing. Across SaaS, ecommerce, and content, the useful set looks like this.

• Account and settings tools: Read plan state, rotate a key, invite a seat, toggle a flag, pull an invoice. These are the actions a dashboard hides behind nested menus, where screenshot-driven agents waste the most time. A read-only tool can carry a readOnlyHint so the agent doesn’t ask for confirmation it doesn’t need.
• Checkout and order tools: Search the catalog, apply a filter, add a line, start checkout, look up order status. Shopify merchants and custom storefronts both win here: the agent can stay inside the merchant’s branded flow instead of bouncing to a generic shopping graph. Payment and place-order tools should wait for a person. Shipping estimates and inventory checks should not.
• Content credentials: Cloudflare’s preview pack can sweep the images on a page and report Coalition for Content Provenance and Authenticity (C2PA) manifests: who signed the asset, which generator claimed it, whether a credential is present. On a news site or a brand library, that is how an agent answers whether an image was generated without downloading the whole file. The current pack reads metadata. It does not claim cryptographic verification (results come back with signature verification off), which is the honest default.
• Customer support tools: Create a ticket with the right product, severity, and diagnostics already filled. Chrome’s examples include mapping a conversation onto a support form so the agent does not dump a full name into a first-name field. For a SaaS company, this is the difference between an agent that files a useful ticket and one that files a screenshot of the wrong settings page.
• Form and lead tools: Newsletter, demo request, quote, reservation. Declarative attributes on the form you already have. The browser keeps the form on screen, which preserves brand, consent language, and the legal copy your counsel actually approved.
• Search and filter tools: Site search, facet filters, show me the comparison view. Content sites need this as much as stores. An agent that can call search_posts with a topic is more useful than one that tries to reverse-engineer your WordPress rewrite rules from the nav.
• Site MCP server tools: If you already expose MCP tools at a same-origin endpoint, the Cloudflare bridge can list them and call them with the visitor’s cookies. One tool definition, two doors: IDE agents hit the server, browser agents hit the page.
• Travel and booking tools: Search a city, filter amenities, start a reservation, complete it only after the guest confirms. Chrome’s hotel-chain demo is the canonical walkthrough, and it is the best picture of why this is not scraping: after each call, the available tools change to match the step the user is actually on.

Taken together, those tools are not a chatbot bolted onto a site. They are the site, described in a language an agent can speak, executed in a context a person can still see. That is how you keep trust. The user watches the form fill. The user confirms the charge. The user is still on your domain when the work is done.

How to Put It on Your Site

You can adopt WebMCP at three levels of depth. Start at the depth that matches the next hour of engineering time, not a six-month platform rewrite.

The zero-code path is the one we used on Martech Zone. In the Cloudflare dashboard, open Agent Readiness, then WebMCP, and turn it on. Pick the packs you want. Content Credentials and Site MCP Server are on by default in the developer preview. There is nothing to deploy and nothing to change at origin. The next HTML response includes the bridge. We flipped that switch. You can confirm it with the curl above. That is the floor: a standards-shaped door on every page, plus whatever the packs can do without your code.

The floor is not the product. A publisher gets image-credential scanning for free. A SaaS app still needs tools that match its actual jobs. Annotate the forms you already trust:

<form toolname="request_demo" tooldescription="Request a product demo. Accepts name, work email, and company. Returns a confirmation." action="/demo" method="post">
  <label for="name">Name</label>
  <input id="name" name="name" type="text" required>
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required toolparamdescription="Work email address, not a personal inbox">
  <button type="submit">Request a demo</button>
</form>

For anything that is not a form, register the tool in JavaScript and tear it down when the view unmounts:

const controller = new AbortController();
await document.modelContext.registerTool({
  name: "get_order_status",
  description: "Look up recent orders and return number, shipping status, and location.",
  inputSchema: {
    type: "object",
    properties: {
      timeframe: { type: "string", enum: ["today", "last_7_days", "last_30_days"] }
    },
    required: ["timeframe"]
  },
  annotations: { readOnlyHint: true },
  execute: async ({ timeframe }) => {
    const res = await fetch("/api/orders?timeframe=" + encodeURIComponent(timeframe), { credentials: "same-origin" });
    return await res.text();
  }
}, { signal: controller.signal });

Feature-detect document.modelContext (some older snippets still look at navigator.modelContext) and no-op when it is missing. Do not let a missing browser API break the human UI. Names should be short, unique on the page, and boring: search_products, not SuperSearchV2. Descriptions should tell the agent when to call the tool and what it returns. Schemas should distinguish first name from full name, email from username, SKU from free text. That is the work. It is the same work as writing a decent API spec, and it pays off the same way.

If you already run MCP tools for IDE agents, keep them. Point the Cloudflare pack at /mcp (or set data-mcp-url) and the bridge will re-register those tools on the page with the visitor’s session. One inventory of tools. Two runtimes.

A related Cloudflare toggle is worth turning on beside it, and it is not the same feature. Markdown for Agents converts HTML to Markdown at the edge when a client sends Accept: text/markdown. That is how an agent reads a page without drowning in nav chrome and scripts. WebMCP is how an agent acts. Martech Zone has both. We also expose a human-visible Markdown view on articles. Reading and acting are two halves of being useful. Do not confuse the toggle that feeds a model with the toggle that lets the model help your user.

How to See It Work

Start with this site. Fetch any HTML page and look for /.webmcp/bridge.js. Then open Chrome with the WebMCP testing flag enabled, load Martech Zone, and inspect document.modelContext. The Content Credentials pack should be able to talk about images on the page. We do not currently publish a public MCP server at /mcp, so that pack has nothing to proxy until we add one. That is an honest snapshot of a toggle-first rollout: the door is installed, the first pack is live, and the custom tools (search, subscribe, ask a question against an article) are the next layer of work, the same way a new API does not ship every endpoint on day one.

To see a full booking loop, Chrome’s early-preview demos are the fastest path: a hotel chain that grows new tools after each step, a restaurant form that is entirely declarative, a pizza builder that registers imperative layer tools. Install the inspector, type a prompt, and watch the agent choose a tool instead of a click. Chrome 149 and later also expose an Application → WebMCP pane in DevTools when the testing flags are on, so you can list tools, inspect schemas, and run them by hand without an extension. Then do the same on your staging site with one annotated form. If the inspector cannot see the tool, the schema or the flag is wrong. If it can see the tool and still clicks around it, the description is wrong. Fix the description. That is the entire debugging loop.

If you want a consumer agent rather than a developer tool, ChatGPT’s desktop app (as of late August 2026) can surface site tools in its built-in browser. Open a WebMCP-enabled page, and the address bar can list what the site registered. That path currently speaks the imperative API. Annotated forms may not show up there yet, so test both Chrome and ChatGPT if your first tools are declarative. Gemini in Chrome was previewed as forthcoming at Google I/O 2026. Do not treat that as a shipping surface until Google says it is live.

If you want a headless run, Cloudflare Browser Run can start a lab browser with WebMCP enabled and connect an MCP client over Chrome DevTools Protocol. The tools behave the same way in a laptop tab and in a remote browser. Sensitive tools will still wait for a person. Open the live view, confirm the reservation, and you have the HITL path working. That is not a gimmick. That’s why this standard can live on a checkout page without becoming a blank-check API for whoever shows up with a model.

Adopt the Standard

I don’t think SaaS is dying, and I don’t think ecommerce or publishing will be replaced by a chat window that never visits your domain. I think the winners will be the same as they were when we moved from paper to web, from web to mobile, from mobile to API: the teams that treated a new kind of visitor as a first-class user and removed the friction that visitor could not tolerate.

WebMCP is the first serious standard for that visitor. It is still a community-group draft. Chrome is still in an origin trial. Cloudflare’s edge packs are a developer preview. All of that is true, and none of it is a reason to wait. RSS was useful before it was boring. OpenAPI was useful before every vendor had a generator. MCP was useful the week teams stopped pasting JSON into prompts. The cost of a toggle plus a few form attributes is trivial next to the cost of letting agents guess their way through a checkout you already paid to design.

Give them a door. Keep the human in the room. Keep the session on your site. That is not a concession to the models. It is the same strategy we have always had, pointed at the next interface.

Turn On WebMCP