Intent to Extend Experiment: WebMCP

[Chromestatus]

Contact emails

khusha...@chromium.org, yhk...@google.com, be...@chromium.org, mas...@chromium.org, d...@chromium.org, mfo...@chromium.org, fbea...@google.com

Explainer

https://github.com/webmachinelearning/webmcp

Specification

https://webmachinelearning.github.io/webmcp

Design docs

https://docs.google.com/document/d/1ZaQvuj4YnUnoqOfEhbfgFynpDRKk2zZZHavTNJ151gM/edit?tab=t.0#heading=h.ggi78l861caa
https://docs.google.com/document/d/1ycdzuXA-VE8lRDFSArh0Um3PChHV0Hq6Om1MSMG8qPE/edit?tab=t.0#heading=h.edohi3f5z12h

Summary

WebMCP is a proposal for a web API that enables web pages to provide agent-specific paths in their UI. With WebMCP, agent-service interaction takes place via app-controlled UI, providing a shared context available to app, agent, and user.

Blink component

Blink>Agentic Platform>WebMCP

Web Feature ID

document-modelcontext

Search tags

WebMCP

TAG review

Spec is being incubated. We will request TAG review before shipping.

TAG review status

Pending

Origin Trial Name

WebMCP

Goals for experimentation

For the experiment we are focused on understanding the API ergonomics for agentic workflows across various verticals such as web commerce and productivity. We expect the site owners to implement WebMCP tools in their sites to automate high-value workflows for them and will seek feedback on the functionality of WebMCP. We also plan to gather metrics for tool usage and latency, and assess opportunities for improvements.

Chromium Trial Name

WebMCP

Origin Trial documentation link

https://docs.google.com/document/d/1ZaQvuj4YnUnoqOfEhbfgFynpDRKk2zZZHavTNJ151gM/edit?tab=t.0#heading=h.ggi78l861caa

WebFeature UseCounter name

kModelContextRegisterTool

Risks

Interoperability and Compatibility

Given this is a new space and new API - there's no compatibility risk. Usual risk related to other browser vendors not adopting the API apply. This API is meant to augment capabilities provided by browser add-ons and so non-adoption in other engines would have limited user-impact and thus we consider the risk to be low.

Gecko: No signal

WebKit: No signal

Web developers: No signals Web Framework developers: Have shown a great deal of interest during the developer trial, as evidenced here: https://www.star-history.com/?repos=webmachinelearning%2Fwebmcp&type=date&legend=bottom-right Chrome web store features about 9 different extensions with WebMCP on their title and 4* or more ratings. https://chromewebstore.google.com/search/WebMCP?minimalRating=4

Other signals:

Ergonomics

There is a risk that site authors that wish to incorporate WebMCP tools into their sites will need to duplicate functionality that currently exists to drive the user interface. We're hoping that most imperative WebMCP tools are just thin wrappers around existing code that drives actions on the site, but we are working with framework developers like React to ensure that WebMCP tools can be added without rearchitecting the site logic. We are also offering a declarative version that requires only adding attributes to existing form elements, which is much lighter weight to deploy and does not require any refactoring of existing site functionality.

Activation

There are no activation requirements to register WebMCP tools. To execute WebMCP tools does require an agent, either provided by the browser or site author, to formulate and orchestrate tool calls. There are several Chrome extensions already available that allow cloud-LLM-based agents to discover and call WebMCP tools. It is also possible to use the Prompt API to call WebMCP tools using on-device models.

Security

Sites may consume and expose sensitive information when their WebMCP tools are called by agents. Agents should implement safeguards to ensure that sensitive information is passed to sites and between origins only under the consent of the user that is supervising them. LLM-based agents are susceptible to attacks such as indirect prompt injection, which can cause an exploited agent to exfiltrate sensitive information in its context to an attacker. Agents should implement safeguards against prompt injection and related attacks.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Reason this experiment is being extended

OT feedback has suggested improvements to the API, which we are implementing. The OT extension would enable us to get data on those improvements as well as to continue getting data on the rest of the feature.

Ongoing technical constraints

No technical constraints for the experiments.

Debuggability

Explicit debugging support through a new WebMCP Chrome DevTools Protocol domain. The domain supports listing registered tools, invoking tools, and logging all calls by agents. Registration issues for declarative tools (e.g., missing names or descriptions) are reported through the Audits domain.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No
The IDL and basic usage is tested via WPTs. Since the API provides the user agent with the ability to call certain tools, we might need to extend the WPT harness to support this.

DevTrial instructions

https://docs.google.com/document/d/1rtU1fRPS0bMqd9abMG_hc6K9OAI6soUy3Kh00toAgyk/edit?tab=t.0

Flag name on about://flags

Experimental Web Platform features

Finch feature name

WebMCP

Requires code in //chrome?

True

Tracking bug

https://crbug.com/445637567

Launch bug

https://launch.corp.google.com/launch/4460611

Estimated milestones

Origin trial desktop first	149
Origin trial desktop last	156
Origin trial extension 1 end milestone	162
DevTrial on desktop	146
Origin trial Android first	149
Origin trial Android last	156
DevTrial on Android	146
Origin trial WebView first	149
Origin trial WebView last	156

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5117755740913664?gate=5151396285513728

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAtRdyRw1WtO5va0K%3D_adYH-FRh01xvw5%2BosSd_DAq%3D%3DUQ%40mail.gmail.com
Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/bhhOmTGzD5Y/m/PGdM8lF6AQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a076b26.050a0220.3377b4.05fa.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1 conditional on some summary of developer feedback from the first OT. What did we learn? Are we making API shape changes in response? And why aren't we moving to I2S yet (or is that anticipated in this extension window)?

Best,

Alex

[Dominic Farolino]

Hey Alex, yeah, we’re hoping to move to I2S within the extension window.

So far we’ve learned a lot:

The imperative API is a lot more popular than the declarative one, so we're investing more into it in response to user needs.

1. We received excellent feedback from Mozilla about API changes we can make to benefit non-AI use cases, as a generic cross-realm function-calling primitive.

2. We've heard from partners with tools whose entrypoint is on one page, while the result is on another (after a navigation). So we're prototyping a continuation API that we'd like to get into the hands of developers.

3. We and popular frameworks anticipate gaps between async tool registration and when an agent collects a "snapshot" of a page's tools (driven by its page loading heuristics). So we're prototyping a tool stability API to let developers inform agent heuristics when an appropriate observation time might be. We're discussing this with major model vendors and want to understand how this impacts performance in the real world.

4. Some developers expressed a desire to pass user activation from an in-page agent (on a top-level document), into the page hosting a a tool. We're tracking this in https://github.com/webmachinelearning/webmcp/issues/62, but before pursuing a proposal like capability delegation, we'd like more experimentation to help us understand how much this comes up in practice.

5. We're exploring what it might look like to enforce size/character limits on tools, and we'd benefit from more time to experiment after discussing what a reasonable limit might look like with other browsers and major model vendors.

Those are a few things we've learned so far, and in particular, how we'd benefit from an extended experiment to understand how our proposed changes play with real-world sites and agents.