WebMCP vs MCP-B vs server-side MCP: which layer should a founder choose?

WebMCP is a browser surface. MCP-B is a runtime and bridge. Server-side MCP is a service boundary.

Those three things often get described as if they were competing versions of the same protocol. They are not. A founder deciding what to build should start with where the useful state lives, who needs to call the tool, and whether the user has a page open.

The status before the architecture

In the September 19, 2026 source review, the WebMCP draft was a Draft Community Group Report dated September 17. It explicitly says it is not a W3C Standard and is not on the W3C Standards Track.

Chrome's WebMCP documentation labels the implementation as an Origin trial and Intent to Experiment. Chrome also describes WebMCP as under active discussion. That is a good reason to prototype, not a reason to make native WebMCP the only path into a product.

OpenAI currently documents a WebMCP-based Site Tools surface in the ChatGPT desktop app's built-in browser. Its Help Center page says access depends on the account, selected model, and current page, and says Site Tools are not currently available in Chrome. OpenAI's developer documentation describes a subset of the API: top-level JavaScript tools work, while declarative form tools and iframe tools are not currently exposed as Site Tools. Treat that as current OpenAI product documentation, not as a claim about every ChatGPT account, model, browser, or agent surface.

The layer comparison

Layer	Where it runs	What the agent sees	Best fit	Main constraint
WebMCP	In the page and browser	Tools registered by the open page, with the page's live state and session	An agent helping with the screen the user is looking at	Tab-bound, browser-dependent, and still a draft/experimental platform feature
MCP-B	A browser compatibility/runtime layer	Tools exposed through a package or relay	When native coverage or a desktop bridge is the constraint	It is a project runtime, not the W3C proposal
Server-side MCP	A local process or remote service	Tools, resources, and prompts exposed through the MCP protocol	Shared business logic, background work, headless agents, and multiple AI hosts	It needs its own auth, connection, state, and product integration; it does not inherit the user's current tab automatically

The Chrome comparison guide makes the practical split clear. MCP is persistent and platform-wide. WebMCP is ephemeral and tied to a live website. WebMCP is also “MCP-inspired,” not a JavaScript implementation of the full server protocol: the browser API is focused on page tools and does not include server-side concepts such as MCP resources.

MCP-B is a project around the proposal, not the proposal itself. Use its documentation when a target browser or client needs compatibility; do not treat it as native browser support.

Server-side MCP is not a third competing standard. It is ordinary MCP implemented by a local or remote server. The official MCP architecture describes servers that expose resources, tools, and prompts, with stdio for local processes and Streamable HTTP for remote services. That layer is where durable business rules should live.

The founder decision

Choose WebMCP when the action depends on the page the user has open: the selected workspace, a dashboard filter, a canvas, a logged-in session, or a visible confirmation step. WebMCP lets the agent work inside the product's existing UI and state. It is a thin, contextual interface for a browser agent.

Choose server-side MCP when the capability should work without an open tab. Search, analytics, account data, long-running jobs, and core workflows usually belong here. A backend MCP server can serve several hosts and clients, enforce authorization centrally, and keep working when the user closes the page.

Choose MCP-B when a target browser or client needs compatibility or a desktop bridge. Treat it as runtime behavior, not native support.

For Mudpie, if the workflow depends on live page context, add a thin WebMCP adapter around authenticated logic. Keep analytics, search, identity, permissions, and background work server-side; use MCP-B only when a target client needs compatibility. This is an architecture recommendation, not a claim about Mudpie's implementation.

The first build decision is therefore not “WebMCP or MCP?” It is “what must be true about the user's current page for this action to be useful?” If the answer is “nothing,” build the service. If the answer is “the page is the product,” expose a browser tool. If the answer is “we need both,” make the backend durable and the WebMCP layer contextual.