Type "WebMCP vs MCP" into a search box right now and the framing of the results is a fork in the road: two protocols, pick one. That framing is wrong, and getting it wrong is how teams will make the worst possible decision about a technology that is one prompt injection away from emptying a checking account.

WebMCP and Anthropic's Model Context Protocol are not rivals. They divide the agent's tool surface along a line most coverage misses: whose credential executes the call.

What WebMCP actually is#

WebMCP is a browser API. A web page calls document.modelContext.registerTool and hands an in-browser AI agent a typed tool — a name, a natural-language description, a JSON-Schema input, and a function the page runs itself:

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string", description: "The item text" } },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);   // reuse the app's own client-side code
    return { content: [{ type: "text", text: `Added: "${text}"` }] };
  }
});

The page becomes, in the spec's own words, "an in-page MCP server" — except the tools expose client-side logic and DOM state instead of a backend API. There's a declarative path too: annotate an HTML <form> and the browser synthesizes a tool from it. WebMCP borrows MCP's vocabulary — tools, descriptions, JSON-Schema inputs, the content result shape — but deliberately not its wire protocol, because MCP was built for server-to-client process communication and "lacks native web concepts like origins, standard browser permissions, DOM integration, and tab-level lifecycle management."

It is early. WebMCP is a Draft Community Group Report in the W3C Web Machine Learning Community Group — a proposal, not a standard — jointly authored by Google and Microsoft. Chrome opened a public origin trial in version 149, and the Chrome 149 DevTools added a WebMCP panel that lists a tab's registered tools and logs every agent-to-page invocation. No Safari, no Firefox. Microsoft co-authors the spec and has shipped nothing in stable Edge. This is a thing to prototype against, not to ship.

The line that actually divides them#

Backend MCP is for systems the agent connects to on its own authority: your database, a SaaS API with its own key, anything where the agent (or a server acting for it) holds the credential. That's why MCP has spent a year of its life on authorization — OAuth handshakes, token grants, scopes — because a remote server reaching into a user's account has to be handed permission to do so.

WebMCP is for everything on the other side of that line: the things the user is already logged into in their browser. Their bank tab. Their email. The dashboard they're staring at. The tool doesn't connect to those systems — it runs inside them, in a tab the user already authenticated.

WebMCP's headline feature isn't a new capability. It's that the authorization problem evaporates — because the agent never leaves the origin that already logged the user in.

No handshake. No token. No scope to grant. The hardest, slowest part of the entire MCP project, gone — not solved, relocated.

"No OAuth" is the warning label, not the feature#

Read that relocation carefully, because it is the whole story. "Free auth" is a euphemism for ambient authority: the agent inherits the user's live session by construction. The WebMCP spec does not bury this — it leads with it. The security questionnaire states plainly that the user's "authentication cookies and session state are automatically available to the page, allowing tools to: make purchases, transfer funds, modify account settings."

Now add the failure mode every agent ships with. A prompt-injected agent — fed a malicious instruction through a web page, an email, a retrieved document — is, on a WebMCP site, one tool call away from transfer-funds executing with the user's real identity and no second factor. Backend MCP at least forces that authority through a token you can scope, audit, and revoke. WebMCP dissolves the token into the browser's ambient session, where there is nothing to scope and nothing to revoke short of logging out.

The spec's answer is human-in-the-loop confirmation — and here is the part to underline before you enable the flag: that confirmation is a stated goal, not yet a normative requirement. The draft admits it "does not include normative guidance against the misuse of tools that expose sensitive or high-privilege operations." So the safety of any WebMCP deployment currently rests on the browser's implementation, not on the standard. You are trusting Chrome, not the spec.

The third answer to an old question#

There's a quieter reframing worth keeping. WebMCP is the third way an agent can operate a website, and it inverts the first two. Computer-use and DOM automation have the agent reverse-engineer the human UI — screenshots, selectors, guessing where to click — which works on every site and breaks the day you ship a redesign. WebMCP flips control: the site declares a stable, typed contract and maintains it, like a public API instead of screen-scraping. The price is adoption — a WebMCP tool only exists where a developer added one, while a computer-use agent works on the open web today.

So the real picture isn't a fork; it's a map. Backend MCP for the systems an agent connects to with its own credentials. WebMCP for the sites the user is already signed into. Computer-use for the long tail that has adopted neither. The same companies betting on an "agentic web" are shipping all three, plus the agent — Gemini in Chrome — that will consume them.

Pick by the question that actually decides it: not "client or server," but whose logged-in identity are you willing to let an agent borrow — and whether a confirmation dialog the spec hasn't yet made mandatory is enough to stand between that identity and a prompt injection.