[Proposal]: WebMCP as a UCP Transport

[bengreenstein]

Summary

WebMCP is a W3C WebML standards proposal that allows Web developers to expose tools to AI agents imperatively via a new JavaScript API, or declaratively via new HTML attributes. See the WebMCP Github for more information about these APIs. This proposal is to use WebMCP as a new transport for UCP. The idea is that in the same way that MCP, as a transport, provides a 1:1 mapping of MCP tools to UCP capabilities, WebMCP would do the same.

Motivation

This proposal solves two problems:

First is that currently UCP does not have a great way of enabling a web browser agent to conduct commerce client-side on web page front-ends. Doing this in the front end as opposed to using REST to interact with a server has advantages such as providing user authentication and state management for free, and being able to invoke client-side web page UX.

Second is that WebMCP currently does not have standard tools for conducting commerce-related business on the web. Without UCP, every web page that offers a shopping cart, for example, would expose their own bespoke “add_to_cart” WebMCP tool, which would make it harder for an agent to learn how to use all of them, leading to decreased reliability of agents that use WebMCP for commerce.

Goals

We expect use by web pages of UCP and WebMCP to grow. We hope that UCP + WebMCP would be the most popular path for agents to conduct commerce on the web.

Non-Goals

The WebMCP transport only makes sense to connect agents to web pages, or to otherwise automate web pages. Thus it is a non-goal for UCP-over-WebMCP to be used for conducting commerce on anything other than a web page.

Detailed Design

WebMCP is a proposed pair of JavaScript and declarative APIs that allows web applications to expose their functionality as "tools" directly in the browser. By using WebMCP as a transport for UCP, we can bridge the gap between AI agents and the human-centric web, enabling "human-in-the-loop" shopping experiences where an agent can perform complex commerce tasks (like adding to cart or resolving shipping) directly within the user’s active browser session.

In this model, the Business (Merchant) acts as a WebMCP server. Instead of a backend MCP server, the merchant's website registers UCP capabilities as JavaScript or declarative tools that the Platform (Browser Agent) can invoke.

• UCP Platform: The AI agent or browser assistant.
• UCP Business: The web page (e.g., https://shop.example.com) currently loaded in the user's tab.
• Transport: WebMCP (JSON).
• UCP defines capabilities (cart, checkout) specifying well defined schema and operations. Using WebMCP, these can map 1:1 to WebMCP tools registered on the page.

The merchant site uses the WebMCP API to register UCP operations. For example, the dev.ucp.shopping.cart capability's create_cart operation is exposed as a tool:

const createCartTool = {
  name: 'create_cart',
  description: 'Creates a new cart session with line items and optional buyer/context information for localized pricing estimates. When **all** requested items are unavailable, the business MAY return an error response instead of creating a cart resource. `ucp.status` is the primary discriminator; the absence of `id` is a consistent secondary indicator.',
  inputSchema: {
    type: 'object',
    properties: {
      meta: {
        type: 'object',
        properties: {
          ucp-agent: {
            type: 'object',
            properties: {
              profile: {
                type: 'string',
                format: 'url'
                description: 'the URI of the UCP profile'
              }
            },
            required: ['profile']
          }
        }
        required: ['ucp-agent']
      },
      cart: {
        type: 'object',
        description: 'A cart to create'
      }
    },
    required: ['meta', 'cart']
  }
}

window.navigator.modelContext.registerTool(createCartTool);

The UCP Specification requires a negotiation phase to ensure capability and version compatibility.

1. Discovery: The Platform (Agent) detects WebMCP tools on the page. An agent that can connect to the browser and speak WebMCP is presented with WebMCP tools that are registered. Currently an agent connected to Chrome can only see the tools of web pages that are currently loaded in browser tabs. However, there are discussions in the W3C WebML Community Group to expand this to service workers, and a declarative registry so that agents can discover WebMCP tools available on pages that have not yet been loaded in the browser.
   There are 3 approaches to connecting to a web page (or iframe within a web page) that registers tools: First is via a non-standard path provided by the browser to connect its “AI browser agent” to a web page. Second is via a browser extension API. Third is via an API that allows the parent frame of the web page or an iframe on the page to list and invoke tools in another iframe.
2. Advertisement: The Platform passes its profile URI (as required by UCP-Agent headers) within the meta argument of the WebMCP tool call.
3. Negotiation: The Business (The WebMCP tool implementation) fetches the Platform profile, computes the Intersection Algorithm, and determines if the requested action is supported.
4. Execution: The tool performs the commerce action (e.g., updating adding an item to a cart) and returns a UCP-compliant JSON response.

Risks and Mitigations

Connecting web pages to AI agents poses new security risks that are well studied and being addressed by browser agent developers. In particular, a tool description or its output could contain instructions meant to mislead an agent into exfiltrating sensitive data or cause other harm, such as completing unwanted financial transactions.

This proposal introduces no negative performance impact. Since the context is operating a loaded web page, this proposal, if anything, could speed up a user’s interaction with a web page to complete a commerce transaction.

This does not introduce backwards compatibility issues.

The maintenance burden added to UCP is that WebMCP is still an emerging standard, and may change over time. There will likely be some work to update its binding to UCP.

Test Plan

Unit tests, i.e., that UCP-over-WebMCP tools work well in isolation, would be the responsibility of websites. Chrome extensions exist already to test UCP-over-WebMCP tools in isolation and when connected to an agent. WebMCP is not yet available in any browser agent, e.g., Gemini-in-Chrome, Co-Pilot, Atlas, Comet, etc, but we expect each browser to provide a way to run end-to-end tests as well.

Graduation Criteria

We expect WebMCP as a transport to graduate maturity levels in parallel, but slightly lagging Chrome’s API launch stages.

Currently WebMCP is in a Chrome Developer Trial, where breaking changes are infrequent, but expected. During the Developer Trial, which exposes the API only to developers and not their users, we expect to gather feedback and iterate on the design. When the API is functionally complete, bugs except for very minor ones have been resolved, and browser implementers find the API ergonomics to be acceptable, Chrome will start an Origin Trial. It is expected that the implementation will further improve during the OT and that early adopters will implement the APIs. As Chrome developers receive feedback to indicate that the APIs are working well for developers, we will graduate it to stable.

We expect WebMCP’s use as a transport for UCP to be in Working Draft as WebMCP in Chrome enters its origin trial, to graduate to Candidate while the OT is running, and to become stable at the same time, or slightly behind when the WebMCP API becomes stable.

Implementation History

• [YYYY-MM-DD]: Proposal submitted.
• [YYYY-MM-DD]: TC approved "Provisional"; capability enters "Working Draft".
• [YYYY-MM-DD]: TC approved advancement to "Candidate".
• [YYYY-MM-DD]: TC approved "Implemented"; capability enters "Stable".

Code of Conduct

• I agree to follow this project's Code of Conduct