WebMCP vs. MCP: what runs in the browser, what runs elsewhere
A practical map of where browser-exposed WebMCP tools fit within the much broader Model Context Protocol ecosystem.
The short version: WebMCP and MCP share a tool-shaped mental model, but they solve different integration problems and live at different trust boundaries.
MCP in one minute
Model Context Protocol is a client-server protocol for connecting AI applications to external capabilities and context. An MCP server can expose tools, resources, and prompts over a defined transport. It can run beside a database, inside an enterprise service, on a developer machine, or anywhere else a client can reach it.
That boundary matters. The MCP server is not automatically the website a person is looking at, and its state is not automatically the state visible in a browser tab. Authentication, transport, deployment, and client compatibility are part of the integration.
What WebMCP adds inside a web application
WebMCP is an evolving browser API proposal. A page registers JavaScript-backed tools with its document model context so a compatible browser agent can discover and invoke them. The handler executes in the page environment and can reuse the same state and application services as the visible interface.
This makes WebMCP especially interesting for authenticated, stateful workflows already implemented in a web app. The user and agent can work against one tab, one session, and one visible result. It does not remove the need for server-side authorization or a good human interface.
Similar tools, different execution boundaries
Both systems describe callable operations with names, descriptions, structured inputs, and results. The resemblance helps developers reuse contract-design habits, but it should not hide the operational differences.
- A WebMCP tool belongs to a document lifecycle; an MCP server usually belongs to a service lifecycle.
- WebMCP naturally shares the page session and visible UI; MCP requires an explicit client-server identity and transport story.
- WebMCP exposure is shaped by browser origins and document context; MCP exposure is shaped by endpoint, client, and server policy.
- A WebMCP result can immediately update visible application state; an MCP client must decide how remote results appear to the user.
When to use WebMCP, MCP, or both
Choose WebMCP when the job is anchored in a live web application: filtering the catalog currently on screen, editing the draft currently open, or operating within an authenticated session the user can inspect. Choose an MCP server when capabilities should exist independently of a page, serve multiple clients, or access back-office systems directly.
Many serious products will use both. A backend MCP server may expose organization-wide capabilities while a WebMCP layer gives an agent safe access to the current page workflow. Keep names, authorization rules, and outcome semantics aligned, but do not make one interface a blind proxy for the other.
Six questions before you choose
Architecture becomes clearer when you name the state and trust boundary before naming the protocol.
- Does the action depend on the exact page, route, selection, or unsaved draft?
- Should the capability remain available when no browser tab is open?
- Where is identity verified and authorization enforced?
- Must a person see or confirm the effect in the current interface?
- How will registrations or connections be cleaned up?
- What observable state proves the action actually succeeded?
Evidence note. Status note: the WebMCP report dated August 26, 2026 is a Community Group draft, not a W3C Standard.
Primary references
Read the sources
Put it to work
Use the guide on a real product surface.