WebMCP vs MCP

MCP (the Model Context Protocol) is for the backend: a persistent server that gives AI agents tools, often over JSON-RPC. WebMCP is for the frontend: a web page registers tools in the browser with document.modelContext, and those tools live only as long as the tab. Chrome’s own comparison recommends using both.

The names are similar, so people often mix them up. This page sets out the differences in plain terms.

What is the difference between WebMCP and MCP?

MCP is for the backend: a persistent server that often speaks JSON-RPC. WebMCP is for the frontend: tools live in a browser tab, use the page’s session and DOM, and go away when the tab closes.

• An MCP server runs on a machine somewhere. It keeps running whether or not anyone has your site open. Chrome’s docs describe it as a persistent server or daemon (a background program), with SDKs (software development kits) for many languages.
• A WebMCP tool runs inside a web page. It exists while the page is open in a browser tab. Chrome calls these tools “ephemeral (tab-bound)”. The browser passes messages between the page and the agent.

That one difference drives most of the others.

WebMCP vs MCP comparison table

	MCP	WebMCP
Where it runs	Backend server or daemon	Frontend, inside a browser tab
How long tools live	Persistent	Ephemeral, tied to the tab
How messages travel	Often JSON-RPC	The browser carries them between page and agent
What tools can use	Whatever the server can reach	The live page: session, cookies and DOM
How agents find tools	The agent connects to the server	Only by visiting the site; no remote discovery
Where it is defined	The MCP specification	A Draft Community Group Report (Web Machine Learning Community Group), dated 20 October 2026; not a W3C Standard
How you add tools	Write a server with an MCP SDK	Call document.modelContext.registerTool() or add form attributes
Chrome’s guidance	Use it for the backend	Use it for the frontend; use both

What WebMCP gets from running in the page

Because a WebMCP tool is just JavaScript on your page, it can use what the page already has:

• The user’s session. If the user is signed in, the tool acts as that user, with the same cookies your own scripts use.
• The DOM. The tool can read and update the page the user is looking at.
• Your existing code. A tool can call the same functions your buttons call.

Here is the smallest useful shape. It is guarded so it does nothing in browsers without WebMCP.

const controller = new AbortController();
if (document.modelContext?.registerTool) {
  document.modelContext.registerTool(
    {
      name: 'view_cart_items',
      description: 'Return the items currently in the shopping cart.',
      annotations: { readOnlyHint: true },
      async execute() {
        const res = await fetch('/api/cart');
        return res.json();
      },
    },
    { signal: controller.signal }
  ).catch(console.warn);
}

Calling controller.abort() removes the tool. An MCP server has no equivalent need, because it is not tied to a page.

What MCP does that WebMCP does not

WebMCP needs a browser with your page open. An agent cannot reach your tools from a server, a scheduled job or a chat app that never loads your site. A browser or agent learns about a site’s tools only by visiting it.

That is where an MCP server fits. It keeps running, and an agent can connect to it directly.

Chrome’s overview also says WebMCP is “primarily designed for local browser workflows with a human in the loop”. In other words, it was built with a person watching the browser in mind. Headless use, with no visible browser window, is in scope in the explainer too.

Is WebMCP “MCP for websites”?

It is often described as “MCP for websites”, but it is not MCP running in the browser.

• The WebMCP spec references the MCP specification only non-normatively, which means for background, not as a rule it must follow. That reference was added on 28 September 2026.
• WebKit points out that the spec “does not prescribe the format in which tools are exposed”. In WebKit’s view, that means WebMCP is not really an MCP binding.
• Mozilla called the “MCP” naming “a strange and unnecessary branding decision”.

What the two share is the idea of a tool: a name, a description written for a language model, and a schema for the inputs. If you have written MCP tools, WebMCP tool definitions will look familiar.

Where does MCP-B fit?

MCP-B is the name used by the WebMCP-org project, which publishes community npm packages that connect the two. One of them, @mcp-b/webmcp-local-relay, is a relay that forwards a site’s WebMCP tools to desktop MCP clients. These are community packages, not part of either spec.

Security differs too

An MCP server is code you deploy and control on your own infrastructure. A WebMCP tool runs in the user’s browser with the user’s session, so the risks look different.

The WebMCP spec warns about prompt injection through tool descriptions and output. It also warns that agents cannot verify what a tool does before calling it. Two of the spec’s annotations help agents decide:

• untrustedContentHint: the output contains content you did not write, such as user reviews.
• consequentialHint: the action is significant or cannot be undone, so the agent may ask the user first.

A site can also switch WebMCP off with the header Permissions-Policy: tools=().

Should I build WebMCP or an MCP server?

Most sites should build both, which is what Chrome’s comparison page recommends.

If you need	Build
Agents to reach your service without a browser, or work that has nothing to do with a user’s live session	An MCP server
Agents to act on your site the way a signed-in user would: search, filter, add to cart, fill a form	WebMCP
Both of the above (most sites)	Both, as Chrome recommends

If your site runs on a platform, check what it already does first. Shopify, for example, says its WebMCP tools are live on every Liquid storefront with nothing to install. You can check your site for free to see what a browser finds today.

For the full API, read what is WebMCP. For browser status, see WebMCP in Chrome.

Questions people ask

What is the difference between WebMCP and MCP?

MCP is for the backend: a persistent server that often speaks JSON-RPC. WebMCP is for the frontend: tools live in a browser tab, use the page's session and DOM, and go away when the tab closes.

Is WebMCP part of the Model Context Protocol?

No. WebMCP is a separate web API drafted in the Web Machine Learning Community Group. Its spec references the MCP specification only non-normatively, and WebKit notes it does not prescribe the format in which tools are exposed.

Should I build WebMCP or an MCP server?

Chrome's comparison page recommends using both. An MCP server suits work without a browser, and WebMCP suits actions that need the user's live session on your site.

Can an agent find my WebMCP tools without visiting my site?

No. A browser or agent learns about a site's WebMCP tools only by visiting the site. There is no remote discovery.

Sources

1. Chrome for Developers: WebMCP vs MCP (read 2026-10-24)
2. Chrome for Developers: WebMCP (read 2026-10-23)
3. WebMCP, Draft Community Group Report (20 October 2026) (read 2026-10-23)
4. WebMCP commit history (read 2026-10-23)
5. WebKit standards position on WebMCP (#670) (read 2026-10-24)
6. Mozilla standards position on WebMCP (#1412) (read 2026-10-24)
7. WebMCP-org npm packages (read 2026-10-24)
8. Shopify changelog: WebMCP support for Liquid and Hydrogen storefronts (read 2026-10-24)