Skip to main content

WebMCP vs MCP: Where Each Runs and When to Use Which

Short answer

MCP is a protocol that connects AI apps to tools on a server, either on your computer or on a remote host. WebMCP is a proposed browser API where a web page registers tools in JavaScript, and an agent in the visitor's browser tab calls them. Use MCP when an agent needs a service without a page open, or when the caller is a desktop or IDE app. Use WebMCP when the actions already live in your page and should run in the visitor's signed-in session. Many sites will end up needing both.

Tested withWebMCP draft report dated 2026-10-20Chrome WebMCP origin trial from Chrome 149 (docs updated 2026-10-16)MCP spec 2026-07-28Checked 20 Oct 2026

By Tony LewisHow we test these guides

Check the status first​

WebMCP is a draft, and its status changes every few weeks. These are the facts as of 20 October 2026:

ItemStatus on 20 October 2026Where it's from
SpecificationDraft Community Group Report, dated 20 October 2026. It's not a W3C Standard and not on the W3C Standards TrackThe spec's status section
Browser APIdocument.modelContext.registerTool(). Chromium removed navigator.modelContext on 9 July 2026Chromium commit 4a9fee9 and the spec
Declarative (HTML form) APINot in the draft spec. The WebMCP README says it's "not part of the specification at this time." Chrome's declarative API page, last updated 25 September 2026, still describes itWebMCP README and Chrome docs
ChromeOrigin trial from Chrome 149. A local flag is available for testing. Not in Chrome stableChrome docs and the Chrome blog
Microsoft EdgeOrigin trial with an expiry date of 30 March 2027Edge origin trial page

Chrome's May 2026 Intent to Experiment planned the origin trial for Chrome 149 to 156, with shipping in Chrome 157. Secondary reports say Google extended the trial through Chrome 162, which matches the Edge expiry date. Chrome's own docs don't state an end date, so check Chrome Status before you plan a launch around a date.

For local testing, open chrome://flags/#enable-webmcp-testing, set the flag to Enabled and relaunch Chrome. For a live site, you register your origin for the origin trial, create the Chromium issue the registration asks for, and serve the token with an Origin-Trial header or a meta tag.

Where each one runs​

MCPWebMCP
Where the tool code runsOn an MCP server: a local process your AI app starts, or a remote server reached over Streamable HTTPIn the JavaScript of a web page, in the visitor's browser tab
Who writes itWhoever builds the serverWhoever owns the website
Who calls itAn MCP host, such as an AI app, connects to the server and sends tools/callA browser agent, or JavaScript running in the page, calls the tool
How tools are foundThe host asks with tools/list after it connectsSomeone has to load the page. Tools exist only while the page registers them. The draft spec has no manifest format
How the caller is signed inHTTP transports can use OAuth 2.1 when the server requires authorization. Local stdio servers take their credentials from the environmentThe agent works inside the visitor's browser session, so it carries the cookies and logins the page already has
Does a person need to be thereNo. A server can run on a schedule or in a backend jobThe API is built for a person with the page open. Chrome's docs say headless use "may be possible" but the API is "primarily designed for local browser workflows with a human in the loop"
Message formatJSON-RPC 2.0 over stdio or Streamable HTTPSet by the browser. The spec doesn't prescribe how tools are passed to the agent

The WebMCP spec's introduction says pages that use WebMCP "can be thought of as Model Context Protocol servers that implement tools in client-side script." That's a good way to picture the tool shape: a name, a description and a JSON Schema for the inputs are the same idea in both. Treat it as an analogy, though. The discovery, transport and sign-in are different, so an MCP host can't call a page's tools the way it calls an MCP server.

The questions that decide it​

Work through these in order. The first answer that points one way is usually enough.

  1. Does the action need someone to have your page open? If yes, WebMCP is a candidate. If the agent should work in the background or from an app outside the browser, use MCP.
  2. Is the logic already in your page? If a form, a booking flow or a cart already runs in your JavaScript, WebMCP lets you expose it with a few registerTool() calls. If the logic lives only on your backend, put an MCP server in front of it. MCP vs API covers that choice.
  3. Who is the caller? WebMCP tools are for a browser agent or a script on the page. The spec doesn't define a path for an AI app that runs outside the browser to reach a page's tools. For Claude Desktop, Cursor or a coding agent, use MCP.
  4. Whose sign-in should the action use? If the visitor already signed in to your site, WebMCP runs inside that session. If a third party or a service account needs access, use an MCP server with OAuth.
  5. Should the visitor watch it happen? WebMCP tools run on the page, and Chrome's docs say they "execute on your webpage visibly." An MCP server's work happens out of sight unless the app shows it.
  6. Is the action sensitive? Mark it. WebMCP tools can carry a consequentialHint annotation, which the spec says lets clients require a confirmation before running the tool. An MCP host should ask before running a tool too. The MCP spec says tool annotations should be treated as untrusted unless they come from a trusted server.

Many sites end up needing both. A company might run an MCP server for its API, so that AI apps can use it, and add WebMCP tools to the website, so that a shopper's browser agent can use the page. The two don't share a transport or a discovery mechanism, so you write each side separately.

What the two look like in code​

A WebMCP tool is a JavaScript object registered on the page. This is the shape of a tool from Chrome's imperative API docs, shortened:

await document.modelContext.registerTool({
  name: 'book_flight',
  description: 'Book a flight for the user with confirmed flight details.',
  inputSchema: {
    type: 'object',
    properties: {
      flightId: { type: 'string', description: 'ID of the flight to book' },
      passengers: { type: 'number', description: 'Number of tickets to purchase' },
    },
    required: ['flightId', 'passengers'],
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: true,
  },
  execute: async ({ flightId, passengers }) => {
    // Add your flight booking transaction logic here.
    return `Booked ${passengers} passenger(s) on flight ${flightId}.`;
  },
});

An MCP tool is a function on a server, which the SDK turns into a tool entry with the same kinds of fields. The tools/list example in the MCP vs API guide shows the entry an MCP host receives, and How to build an MCP server writes one in Python and TypeScript.

What changed recently​

DateWhat happenedSource
13 August 2025The WebMCP API proposal is dated, with authors from Microsoft and GoogleWebMCP API proposal
10 February 2026Chrome opens an early preview programChrome blog
18 May 2026Chrome's origin trial plan for Chrome 149 to 156 is approvedblink-dev Intent to Experiment
9 June 2026Chrome opens origin trial registration from Chrome 149Chrome blog
9 July 2026Chromium removes navigator.modelContext in favor of document.modelContextChromium commit 4a9fee9
By 20 October 2026The draft spec no longer includes the declarative form APIWebMCP README and draft spec

Older tutorials and the February 2026 technical notes use navigator.modelContext. Use document.modelContext in new code.

Common misconceptions​

"A WebMCP site is an MCP server." The spec uses that analogy, but a page doesn't speak MCP. The browser decides how to pass the tools to the agent, and the spec says it "does not prescribe the format" for that.

"Once I add WebMCP tools, every AI app can use my site." Tools exist only while a page with the tools is open. Chrome's docs list tool discoverability as a limit: clients and browsers have to visit the site to learn what it offers.

"WebMCP means I don't need a backend." The tool runs in your page's JavaScript, and that code often calls the same backend the page already uses. WebMCP exposes what your page does. It doesn't replace the server work behind it.

"The navigator.modelContext examples still work." They worked in early builds. Chromium removed that property in July 2026, so use document.modelContext.

How to do each option​

FAQ​

Is WebMCP the same as MCP?

No. MCP is a protocol that connects AI apps to tool servers. WebMCP is a proposed browser API that lets a web page register tools in JavaScript. They share the idea of a named tool with a description and a JSON Schema for its inputs, but the transport, discovery and sign-in work differently.

Can WebMCP replace my MCP server?

Only for actions that happen on a page a visitor has open. A background job, a server-to-server integration or an AI app that runs outside the browser still needs MCP.

Is WebMCP available to all users?

Not yet as a standard feature. Chrome offers it through an origin trial from Chrome 149, which lets you enable it for visitors on your registered origin. Chrome says the API may change, so plan for updates and check Chrome Status for the current milestones.

Do I need to choose between WebMCP and MCP?

Not always. Many sites will use both: an MCP server for AI apps and API access, and WebMCP tools for the actions visitors take on your pages. The two don't share a transport, so each needs its own code.