WebMCP vs MCP: What's the Difference

MCP is a protocol for running a server that exposes your tools to AI agents from anywhere. WebMCP is a proposed web standard that lets a web page declare what an agent can do on that page while the user has it open.

If you’ve already built an MCP server, the name “WebMCP” suggests the same protocol, just moved into the browser. It isn’t. The difference decides where your agent-facing code lives, which identity it runs under, and whether you can depend on it yet.

This article compares the two on runtime, identity, lifecycle and discovery. It then maps each one to a product type and gives a plain status check on WebMCP.

What Is the One-Line Difference Between WebMCP and MCP?

MCP is a server you run so an agent can call your tools. WebMCP is your page declaring what an agent can do on the page it’s already on. The Model Context Protocol is an open standard for linking AI apps to outside data, tools and workflows, and it doesn’t care whether the agent runs in a browser. Chrome’s guide on when to use WebMCP and MCP calls WebMCP a proposed browser standard made of two APIs. Those APIs only reach the agent built into the browser, and the browser passes messages between that agent and your site. For background on browsers that ship their own agent, see our introduction to agentic browsers. Chrome calls WebMCP “MCP-inspired”. It is a browser API modeled on MCP, not MCP rewritten in JavaScript.

Who Runs What in MCP and WebMCP?

An MCP server is a separate process with its own deployment, its own authentication and its own uptime. WebMCP adds no new process: it runs inside the open tab.

With MCP, you run a service that agents on desktop, mobile, cloud or web clients can connect to at any time. That reach has costs. You host the server, you version it, you monitor it, and you decide how to authenticate each caller. The developer’s guide to the MCP ecosystem covers how clients, servers and the protocol fit together.

With WebMCP, the tool definitions ship as part of your frontend. There is nothing extra to deploy, but the tools are tied to the tab. Each WebMCP tool disappears along with the tab that registered it. If the user navigates away or closes the tab, the agent loses access to that tool.

Identity: The Agent Acts as the Signed-In User

Because WebMCP tools execute inside the page the user already has open, an agent using them works within that user’s existing session, cookies and permissions. It does not hold a separate credential for your site. Chrome points out that WebMCP can use the page’s live session data, cookies and DOM, none of which exist outside an open tab. It follows that a tool’s network requests go out with whatever session the page already has.

An MCP server faces a different problem. It is a standalone service, so it has to work out for itself who is calling and what they may do. That usually means issuing and checking some form of credential for the agent or the user it represents. WebMCP skips that step because it never leaves the user’s session. You don’t provision API keys, set up service accounts or build a separate authorization layer for the agent.

WebMCP’s session-based identity has a cost. From the page’s point of view, a WebMCP tool call is an action taken as the signed-in user. Unless you design a distinction in, your code can’t tell an agent call apart from a click. Three practices follow:

• Give each tool only the scope of something the user could already do in the UI.
• Require confirmation for sensitive actions. The WebMCP overview says a tool that does something sensitive, such as a purchase, can show the user a confirmation dialog before it goes ahead.
• Rely on the platform gating. WebMCP only runs in origin-isolated documents and is gated by the tools Permissions Policy. The policy defaults to self, so a cross-origin iframe must be granted access explicitly.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

If the iframe doesn’t have this attribute, the self default blocks tool registration in that cross-origin frame. Chrome’s docs also state that WebMCP APIs are turned off in any document that enables document.domain, for example through the Origin-Agent-Cluster: ?0 header.

WebMCP vs MCP Side by Side

The core split between MCP and WebMCP is persistence and reach on one side, and page context and user session on the other.

The first five rows are based on Chrome’s WebMCP and MCP comparison.

When Should You Use MCP or WebMCP?

Use MCP for work that happens on a server with no UI, and WebMCP for work that happens on a page with a user on it.

• Backend service, background jobs or data access with no UI: MCP. WebMCP needs an open page, and Chrome’s overview says it is built mainly for a person working in a local browser, not for headless runs. Start with how to build an MCP server.
• Web app with a logged-in user: WebMCP. Use it for actions on the current page, such as filling a complex form or picking dates in a booking widget, where the user’s session and page state matter.
• Both. Many products will want both. MCP carries the core business logic and data, and WebMCP covers in-tab actions. If you already have an HTTP API, exposing that API to LLMs with MCP is the natural server-side half. For the browser side, see our companion article, Exposing Your Site’s Actions to AI Agents With WebMCP.

Does WebMCP Replace MCP?

No. Chrome says plainly that WebMCP neither extends nor replaces MCP. It is built for the browser and leaves out server-side concepts such as resources. It also depends on a page. Its tools can only be found by visiting the site, and they disappear when the tab closes. Many agent tasks never touch a web page at all: scheduled jobs, IDE assistants, data pipelines and agents running in the cloud. Those tasks still need an MCP server.

How Mature Is WebMCP?

WebMCP is experimental. It is available through a Chrome origin trial starting in Chrome 149 and locally through the chrome://flags/#enable-webmcp-testing flag, and Chrome warns that the API is still being discussed and may change. Origin trials run for a fixed period, can come with usage caps, and are meant to gather feedback that shapes the final API. The WebMCP specification is a draft report from the W3C Web Machine Learning Community Group. It is not a W3C Standard and is not on the W3C Standards Track. Chrome’s documentation only covers Chrome’s implementation, so don’t assume support in other browsers or agent hosts until their own documentation confirms it. Follow WebMCP on Chrome Status for milestone changes. Chrome also notes that WebMCP can be added as a progressive enhancement. Build it that way, so your UI works the same whether or not an agent can see the tools.

Choosing Between Them

MCP and WebMCP answer different questions. MCP makes your capabilities reachable from any agent at any time. WebMCP makes the page a user is on usable by the agent in their browser, under their own session. As a next step, list the actions your product exposes and sort them: headless operations go to an MCP server, and session-bound page actions become WebMCP candidates behind the origin trial. Keep the WebMCP layer thin, because the API may still change.

FAQs

How do I turn on WebMCP for real visitors, not just my own browser?

Register your origin in the Chrome Origin Trials console and generate a WebMCP token. Serve it on every page that registers tools, either in an origin-trial meta tag or in an Origin-Trial HTTP response header. Tokens are per origin. Without one, visitors on standard Chrome never see your tools, because the local testing flag only affects the browser where you enable it. The trial started in Chrome 149 and was first set to run through Chrome 156. Google has asked to extend it through Chrome 162, so check the end date for your token in the Origin Trials console.

How can I test WebMCP tools without building an agent?

Use the Model Context Tool Inspector, a Chrome extension listed in Chrome's WebMCP documentation. It lists the tools a page has registered and lets you run them yourself. It also confirms the browser can parse your JSON Schema, and it displays whatever result or error each tool sends back. Your page still needs WebMCP turned on, either through the WebMCP testing flag in chrome://flags or through an origin trial token.

Can I reuse my MCP tool definitions for WebMCP?

You can often reuse the input definitions, but not the handlers. Both MCP tools and WebMCP tools describe their inputs with JSON Schema, so a tool's name, description and argument shape usually carry over. The handler is different. An MCP handler runs on your server under whatever auth you implement. A WebMCP handler is JavaScript that runs in the page, with the user's session and live DOM state.

Does Angular support WebMCP?

Yes, but only experimentally. Angular's experimental support lets you register WebMCP tools that follow the lifecycle of Angular's dependency injection, and it can turn Signal Forms into tools without you writing JSON Schemas by hand. Angular's documentation warns that the WebMCP spec is changing often and that these APIs may change even outside major versions. Pin your Angular version and expect to update your code.