WebMCP vs MCP: what they share, where they differ

The recent WebMCP challenge gave developers a concrete reason to experiment: its submission window ran from August 25 to September 3, 2026. With that round of building just finished, this is a useful moment to separate what WebMCP enables from what its name suggests. See the challenge dates.

As of September 9, Chrome documents an origin trial starting with Chrome 149 and a flag for local testing. WebMCP is still experimental; enabling it on a website does not mean every visitor’s browser or assistant can use it. The Chrome documentation tracks implementation availability. The September 4 draft is a Community Group Report, not a completed W3C Standard.

MCP’s architecture separates the host application, its clients, and the servers that provide capabilities. WebMCP’s introduction describes tools implemented in page JavaScript, with a shared interface for users and agents. A familiar tool description does not make these interfaces interchangeable.

Both let a developer describe an operation with a name, a purpose, and structured inputs. An agent can choose a tool and supply arguments instead of inferring the operation from a collection of buttons. MCP defines discovery and invocation through tools/list and tools/call, with JSON Schema describing the inputs. See the MCP tool messages and tool definition.

With WebMCP’s JavaScript API, a page registers a tool through document.modelContext.registerTool() and supplies the callback that implements it. The imperative API guide shows how names, descriptions, and input schemas accompany that callback. These are familiar design ingredients for an MCP developer, even though the browser integration is different.

The same product question follows: can an agent understand exactly what this tool will do? For a hypothetical booking service, a tool called prepare_reservation should make clear that it fills a draft. A separate confirm_reservation should explain that it creates the booking. A valid schema cannot repair an ambiguous promise.

Imagine a travel service offering both interfaces. Through MCP, an assistant could ask the service for available trips and work with the returned data from its own chat interface. The travel website does not need to be open. MCP servers can be local processes or remote services; the server architecture is independent of a particular web page.

Through WebMCP, the same service could let an agent update the trip search already open in the user’s browser. Our hypothetical tool would apply the dates, show the matching journeys, and leave the user looking at the result. It could reuse the application’s existing frontend logic and call its backend when needed. This is the collaborative workflow described in the WebMCP explainer.

There is also an HTML route: WebMCP’s declarative API adds attributes such as toolname and tooldescription to forms. The browser derives the tool parameters from form controls. That can make an existing search form a useful starting point; it does not require inventing a separate MCP server. See the declarative API guide and the draft’s declarative API section.

Not automatically. A page registering WebMCP tools does not thereby publish an MCP endpoint. An integration would need browser access and a way to expose those page tools to the client. The WebMCP project explicitly describes backend integrations as complementary rather than replacements for one another. See the explainer’s non-goals.

Nor does browser context mean the model runs on the user’s device. The tool executes in the page; the agent’s model and hosting are separate choices. WebMCP’s terminology includes agents supplied through browser extensions as well as browser features.

A WebMCP tool can reuse a web application’s logged-in experience, but a logged-in user has not necessarily approved every action an agent might attempt. Our recommendation for the booking example is to keep preparation and confirmation distinct, enforce authorization in the backend, and make the final effect visible before committing it.

Structured tools also leave room for prompt injection through their descriptions or returned content. The draft’s security considerations discuss these risks. Chrome’s tool security guidance explains hints for untrusted content and consequential actions, and restrictions on exposing tools across origins. Treat these as useful signals and boundaries, not proof that an action is safe.

Our recommendation: choose MCP when your capability needs to work across assistant applications without depending on an open website. Explore WebMCP when helping a user operate your website is the product experience. Offer both when both workflows matter, sharing business logic while testing each interface separately.

For WebMCP, start with one useful action and test its whole page lifecycle: whether it appears in the right state, accepts valid inputs, reports failures clearly, and leaves the interface consistent. Chrome’s best practices cover tool scope and registration, and the Model Context Tool Inspector extension lets you inspect and invoke page tools while developing.

For an MCP server, run a quality audit on mcpscore.dev to check protocol behavior, tool descriptions and schemas, and security and auth posture. mcpscore currently audits MCP servers; it does not inspect WebMCP page registrations. A server score does not validate a browser workflow.

Whichever interface you expose, the useful work is in the contract: tell the agent what the action does, what it needs, and what changed when it finished. That is where a callable tool becomes a usable one.