UHP vs WebMCP

Choose by where the tool lives

Use WebMCP when a browser document exposes application actions to an agent; use UHP when a client submits work to a server-owned complete harness. The current WebMCP draft and Chrome implementation guidance, reopened 4 October 2026, describe a proposed browser API. They do not make it a W3C Recommendation. UHP is UHP 2026-09-28 Draft.

Requirement	Boundary to design
Act on the currently loaded web application	WebMCP document/tool scope, origin and browser support
Continue remote work after a page is closed	UHP execution lifecycle plus explicit bridge persistence
Cancel a page tool and an outer harness turn	Two cancellation paths; observe each outcome
Let another origin invoke a tool	WebMCP exposure/permissions policy plus application authorization

Consider a harness that asks a page to export a report. Before bridging the call, decide what happens if navigation destroys the document: whether the action already committed, whether a result can be retrieved independently, and whether the outer task should fail or await reconciliation. An AbortSignal or a cancelled outer run does not prove the report was rolled back.

The browser tool’s annotations inform an agent; the application still enforces its permissions. UHP security controls the outer server boundary. Keep these checks separate and feature-detect the concrete browser surface rather than treating publication of a draft or test dashboard as universal browser availability.

The one-sentence difference

UHP standardizes how a client asks a server to execute a selected, configured complete agent harness; WebMCP standardizes a browser-facing JavaScript/HTML surface through which a web document exposes structured tools to agents.

The overlap is agent execution, but the trust boundary and object model are different. A WebMCP tool lives with a web page and invokes page/application logic. A UHP Response or Session represents work owned by a remote UHP server and complete harness runtime.

Current WebMCP status

The September source snapshot was a Draft Community Group Report dated 4 September 2026, published by the W3C Web Machine Learning Community Group. The document explicitly states that it is not a W3C Standard and is not on the W3C Standards Track.

At the preserved 6 September review cutoff, the official webmachinelearning/webmcp repository main was 50c4b7fd6c4402731271649bc544b662b061ed44. That 4 September change explicitly documents headless use cases as in scope. The specification also links an active Web Platform Tests suite.

Caution

“W3C Community Group Draft” must not be shortened to “W3C Standard.” WebMCP is actively evolving, and implementation documentation can lag the current specification text.

What WebMCP currently defines

The current draft extends Document in secure contexts with document.modelContext. Its ModelContext interface exposes three principal methods plus a change event:

• registerTool(tool, options) registers a structured page tool.
• getTools(options) returns tools exposed to an in-page caller from the document tree.
• executeTool(tool, inputObject, options) invokes a registered tool on its owning document.
• ontoolchange notifies consumers when the exposed tool set changes.

An imperative ModelContextTool carries a name, human-facing optional title, natural-language description, JSON Schema inputSchema, an asynchronous-capable execute callback and optional annotations. Tool execution receives an AbortSignal, and callers can also cancel an execution with an AbortSignal.

The current annotations are:

• readOnlyHint — the tool is intended not to modify state;
• untrustedContentHint — returned content should be treated as untrusted;
• consequentialHint — execution may have significant or non-reversible real-world effects.

Registration can also declare exposedTo origins, while getTools() can request tools from selected fromOrigins. The API is gated by a tools Permissions Policy and origin-isolation requirements. The draft separately includes a declarative WebMCP path intended to expose form-driven functionality without requiring every tool to be authored only through imperative JavaScript.

WebMCP is related to MCP, but it is not the MCP wire protocol

The WebMCP specification says pages using the API can be thought of as MCP servers whose tools are implemented in client-side script. That is a useful mental model, not a statement that a page becomes a network MCP server speaking the MCP transport specification.

WebMCP’s normative surface is browser/web-platform API machinery: Document, ModelContext, document trees, origins, Permissions Policy, events and JavaScript callbacks. MCP’s canonical protocol surface is a client/server protocol with its own transports, capabilities, tools/resources/prompts and extensions.

Accordingly:

• WebMCP is not a new UHP version or UHP extension.
• WebMCP is not the MCP 2026-07-28 protocol release and should not be described as an MCP Core release.
• A WebMCP-capable website is not automatically a UHP server.
• A UHP server does not automatically expose WebMCP tools.

See UHP vs MCP for the broader MCP boundary.

Architectural comparison

Dimension	UHP	WebMCP
Primary concern	Execute work through a selected configured complete harness	Expose web-application functionality as structured page tools to agents
Primary boundary	Client ↔ UHP server ↔ complete harness	Web document ↔ browser/in-page agent
Core objects	Harnesses, Responses, Sessions, Containers, Files, streamed Events	Document.modelContext, registered tools, input schemas, execution callbacks, annotations
Execution location	Server-managed harness/runtime and workspace	The tool’s owning web document/application logic
Transport model	HTTP resource API plus SSE event streaming	Browser JavaScript/HTML API; not a remote UHP task transport
Discovery	UHP discovery and configured harness catalogue	Tool registration plus browser/in-page discovery through ModelContext
Cancellation	UHP response/task lifecycle cancellation	Per-tool execution cancellation through AbortSignal
Cross-origin model	Authenticated-principal/object scoping at the UHP server boundary	Origin isolation, tools Permissions Policy, exposedTo / fromOrigins controls
Current maturity	UHP 2026-09-28 Draft with a 85-check conformance suite	W3C Web ML Community Group Draft report, 4 Sep 2026; not a W3C Standard

How WebMCP and UHP can compose

A realistic architecture can use both layers:

Product / client
      │
      │ UHP: start/continue remote harness work
      ▼
UHP server + complete harness
      │
      │ browser automation / browser agent
      ▼
Web page
      │
      │ WebMCP: discover and invoke page tools
      ▼
Web application logic

For example, a complete harness running behind UHP could control a browser that understands WebMCP and choose a page-registered tool instead of inferring a sequence of DOM clicks. UHP would still own the remote task/session/workspace contract; WebMCP would govern the page-level tool exposure and invocation boundary.

That composition is an architecture, not a standardized UHP↔WebMCP binding. No primary source reviewed here establishes native WebMCP support in HarnessRouter, native UHP support in WebMCP, or a conformance mapping between their object models.

Security boundaries matter more than the similar “tool” vocabulary

WebMCP’s current security/privacy section treats agent-visible tools as a meaningful trust surface. It calls out prompt injection through tool metadata, output injection, malicious or inconsistent tool implementations, misrepresentation of intent, privacy leakage through over-parameterized tools, same-origin concerns and private-browsing boundaries.

The draft also records unresolved limits: agents cannot currently verify that an implementation matches its natural-language description, descriptions remain semantically ambiguous, and tool behavior lacks a statically verifiable behavioral contract. Its annotations help communicate intent and trust signals, but they are not cryptographic proof that a tool is safe or faithfully implemented.

UHP’s security requirements live at a different boundary: server authentication, principal/object isolation, artifact/credential handling, structured errors and harness execution controls. A deployment using both protocols must preserve both trust models rather than assuming one substitutes for the other.

What not to infer

Caution

• WebMCP is a W3C Community Group Draft, not a W3C Standard or Standards Track recommendation.
• document.modelContext is the current API surface; older examples using other globals should not be treated as the current draft without re-verification.
• WebMCP tool exposure is not evidence of native UHP adoption.
• HarnessRouter backend/provider support is not evidence that HarnessRouter implements WebMCP.
• Similar tool concepts do not make WebMCP, MCP and UHP interchangeable protocols.
• A future browser implementation or origin trial does not by itself establish cross-browser standardization.

What to watch next

Material changes worth revisiting include:

1. movement from Community Group Draft toward a formal W3C Standards Track deliverable;
2. substantive changes to the ModelContext IDL, declarative API, permissions/origin model or security annotations;
3. broader browser implementation evidence beyond experimental or trial surfaces;
4. a standardized bridge between WebMCP and network MCP transports; or
5. explicit UHP/HarnessRouter integration backed by primary-source code or documentation.

Related pages

Read UHP vs MCP for the network tool/context protocol boundary, MCP Tasks for MCP’s durable asynchronous-operation extension, Skills Over MCP for skill distribution, and the ecosystem map for adjacent interoperability layers.

Primary sources

• WebMCP — W3C Web Machine Learning Community Group Draft
• WebMCP specification repository
• September WebMCP main cutoff 50c4b7fd
• WebMCP Web Platform Tests
• Chrome for Developers — WebMCP implementation/origin-trial documentation