WebMCP does not replace MCP. MCP is a client-server protocol for durable tools and data outside the page; WebMCP is a proposed browser API so the open tab can expose structured tools to in-browser agents using the user's live session. Browser-use-style DOM actuation is what you use when the site offers neither. Think layers, not a three-way fight.
Everything below was checked against Chrome's WebMCP documentation, Google's WebMCP vs MCP comparison, Shopify's WebMCP API reference, and the browser-use project on 4 November 2026. WebMCP is origin-trial territory, not a finished platform guarantee.
WebMCP vs MCP vs browser-use at a glance
| WebMCP (page tools) | MCP (Model Context Protocol) | Browser-use / DOM actuation | |
|---|---|---|---|
| Where it runs | Inside the browser tab the user already has open | Separate MCP server (local stdio or remote HTTP) | Automated browser (often headless) driven by an LLM |
| Who authenticates | The user's session in that tab (cookies, logged-in state) | The server's credentials (OAuth, API keys, env vars) | Whatever login the automation can perform or inherit |
| Lifetime | Ephemeral: tied to the page visit | Durable: server can be always-on | Per automation run |
| What you get | Tools only (imperative JS API + declarative HTML annotations) | Tools, resources, prompts, extensions | Unstructured UI: click, type, scroll, read DOM |
| Best when | A site publishes checkout or catalog tools on the page | You integrate systems you or a vendor own via a protocol | No API, no WebMCP, and you still need the task done |
| Status (Nov 2026) | Proposed standard; Chrome origin trial from 149; early merchant adopters | Production protocol; many hosts and vendors | Mature pattern; browser-use is a popular open-source stack (MIT) |
Google's analogy in the compare doc is blunt: MCP is the call-centre expert with its own systems access; WebMCP is the in-store associate who can use whatever the customer is already logged into on this page. Browser-use is asking a stranger to squint at the menu board and guess which button is "Add to cart".
What WebMCP is (Chrome, November 2026)
WebMCP is a proposed web standard for exposing tools from a document to an in-browser agent. Chrome published the explainer on 18 May 2026 and updated it on 7 October 2026. As of this writing it is in an origin trial from Chrome 149, with local testing via chrome://flags/#enable-webmcp-testing. That is not "shipped everywhere"; it is "try it in Chromium if you opt in".
Two surfaces matter:
- Imperative API —
document.modelContext.registerTool()registers named tools with schemas the agent can discover and call. - Declarative annotations — HTML form attributes so common actions (search, add to cart) can be advertised without bespoke JS.
Permissions Policy controls exposure: the tools directive defaults to self, so only your origin registers tools unless you deliberately widen it.
Agents discover tools with document.modelContext.getTools() and invoke them with executeTool(). That is ordinary tool use, except the executor is the page, not your backend.
What MCP is (and why it is still the integration layer)
If you need the full MCP story — function calling underneath, the 2026 stateless spec, when to skip a server — read MCP vs function calling. The one-line version for WebMCP vs MCP: MCP standardises how your app or a vendor's service publishes tools outside the browser. A host (Claude, Cursor, ChatGPT, your orchestrator) lists them with tools/list, calls them with tools/call, and still passes definitions to the model as tools.
I use MCP daily as a consumer: coding agents and personal assistants reach Supabase, Gmail, Google Calendar and Notion through MCP servers. The Claient WhatsApp agent I ship in production does not use MCP; it uses plain function calling with tenant scoping in code, for the same reasons as in that post. I have not shipped an MCP server or WebMCP tools to production. The MCP column here is architecture I trust from the spec and from the receiving end, not from running a merchant's WebMCP checkout in anger.
MCP shines when credentials should not live in the user's browser tab — backend systems, team-owned integrations, tools reused across many hosts. WebMCP shines when the user's session on this site is the credential.
What browser-use and DOM actuation are
When neither WebMCP nor MCP nor a plain HTTP API helps, agents fall back to acting like a human at the keyboard: open URLs, read the DOM, click, type, wait for navigation. browser-use is an open-source Python library (MIT) built for that pattern; its docs describe the stack. The same category includes Playwright- or Puppeteer-driven agents and hosted "computer use" products. I am not endorsing one vendor here; the pattern is generic.
Strengths: it works on any site that renders HTML, including legacy admin panels nobody will annotate for agents.
Weaknesses: layout changes break flows; multi-step checkout through mystery modals is expensive in tokens and time; consent and terms of service are your problem; and you are inherently less precise than calling add_to_cart with a SKU.
Prefer structured tools first. Treat browser-use as fallback, not the default architecture — especially if you are building something durable that must survive retries and partial failures without duplicating orders.
Shopify as a real WebMCP surface
Shopify is the clearest production-shaped example as of November 2026. Their WebMCP API docs cover Liquid storefronts and Hydrogen (2026-10), with tools such as search_catalog, get_product, add_to_cart, update_cart_lines, proceed_to_checkout, and complete_checkout, plus navigation and policy search helpers. Agents discover them the same way Chrome specifies: getTools() / executeTool().
Implementation details worth knowing if you are wiring an agent:
- Chrome 153 expects JSON string arguments for some calls; objects are planned for Chrome 155 (per Shopify's compatibility notes).
- Agent support is documented as limited to Chromium-based browsers for now.
That is a useful sanity check: WebMCP adoption is real on paper, but your user's browser and argument-shape quirks still gate you. Do not plan a cross-browser agent that assumes every storefront exposes the same tool surface until the trial graduates.
Decision rules: an ownership test
Ask these in order for each task:
- Do I control an MCP server or HTTP API for this system? Use it. Identity, rate limits, and audit logs belong on infrastructure you operate — same discipline as securing keys and tool descriptions when descriptions are untrusted input.
- Is the user on a page that publishes WebMCP tools for exactly this job? Use WebMCP inside that tab. You inherit their session; you do not get to bypass their consent UI.
- Neither exists? Only then reach for browser-use / DOM actuation, with explicit human approval where money or PII moves.
If you are the merchant, publishing WebMCP tools is how in-browser shopping agents call you without scraping. If you are the platform builder, MCP is still how Gmail, Notion, and your own backend show up everywhere. If you are the agent author, you probably implement all three code paths behind one orchestrator — see single agent vs multi-agent for why one loop with clear tool boundaries usually beats a committee of subagents guessing the DOM.
How the layers stack in one workflow
Picture a lead agent like the one in WhatsApp bot with Claude: it qualifies in chat, then needs to check stock and maybe place an order.
- Qualification and CRM — your MCP server or plain function calling against your database (tenant id from the webhook, never from the model).
- Partner storefront — open the merchant site in Chromium, call WebMCP
search_catalogandadd_to_cartif exposed; the user's login on that site is the auth boundary. - Obscure supplier portal with no API — a guarded browser-use sub-run with a step cap, screenshots for audit, and a human confirm before pay.
That is not three competing products; it is three egress strategies chosen per hop. The mistake is picking browser-use because it is universal, then paying latency and fragility on flows Shopify already exposes as tools.
FAQ
Does WebMCP replace MCP?
No. Google's own comparison doc says WebMCP is not a replacement for MCP. MCP is a client-server protocol for tools and data that live outside the browser, with the server's own credentials. WebMCP is a proposed browser API so an open page can expose structured tools to an in-browser agent using the visitor's live session. They solve different problems and stack rather than compete.
When should an agent use browser-use instead of WebMCP or MCP?
When the site exposes neither WebMCP tools on the page nor an MCP or HTTP API you control or trust. Browser-use and similar stacks (Playwright plus an LLM driving clicks and typing) act on the DOM. They are slower, brittle, and harder to permission, but they are the fallback for the long tail of sites that publish nothing structured for agents.
Is WebMCP available in all browsers?
As of 4 November 2026, WebMCP is a proposed web standard in an origin trial starting in Chrome 149, with a local testing flag at chrome://flags/#enable-webmcp-testing. It is not generally available everywhere. Shopify documents agent support limited to Chromium-based browsers for its WebMCP tools. Treat it as early preview infrastructure, not a baseline you can assume for every user.
Can I use WebMCP and MCP in the same workflow?
Yes, and that is the normal shape. An orchestrator agent might call your product's MCP server for CRM or inventory, open a merchant's storefront in a browser for checkout tools exposed via WebMCP, and only fall back to DOM actuation when neither layer exists. Pick the most structured, most permissioned path available for each step.
About the author
I'm Joan Comadran, an industrial engineer turned AI engineer and full-stack developer in Barcelona. I ship production agents with plain function calling — Claient is the WhatsApp example — and I use MCP every day as a consumer on coding and personal assistants. I have not shipped an MCP server or WebMCP tools to production; this post is architecture guidance from someone who draws those boundaries for real systems. If you want that line drawn on your product, that's what I do.