WebMCP

[domfarolino]

Specification title

WebMCP

Specification or proposal URL (if available)

https://webmachinelearning.github.io/webmcp/

Explainer URL (if available)

https://github.com/webmachinelearning/webmcp/blob/main/README.md

Proposal author(s)

@domfarolino @bwalderman

web-feature id

No response

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

@jakearchibald @bvandersloot-mozilla

WebKit standards-position

WebKit/standards-positions#670

Other information

I just want to call out the fact that WebMCP is designed for two distinct use cases:

1. Built-in "native" browser agents actuating a site through WebMCP tools (things like Gemini in the sidebar in Chrome, ChatGPT Atlas, Co-pilot in Edge, you get it...)
2. In-page agents written in JavaScript—possibly in cross-origin iframes—actuating content in another origin via its explicitly-exposed tools.

WebMCP was conceived with only the first use case in mind, and we've been adapting to support (2), the agents-in-cross-origin-iframes case, due to developer demand. This demand came from wanting to democratize tools, so that they weren't only available to the "built-in" native agent running in your browser, but are available to in-page agent widgets that might want to use those same tools. This has led to things like webmachinelearning/webmcp#179, and webmachinelearning/webmcp#188, which are still under discussion. So we'd love your feedback!

Anyways, we'd love if you reviewed the proposal with both use cases in mind.

/cc @markafoltz, @bengreenstein, @khushalsagar, @bwalderman, @johannhof, @liady

[bvandersloot-mozilla]

WebMCP provides a way for websites to provide in-content actions with natural language descriptions and inputs as “tools” to automated browsing techniques.

At its core, this API provides a way for websites to declare dedicated “lanes” for automated interaction with the site. With honest participants, the benefit is twofold: (1) it can provide a clear signal to any automated browser what actions are easily available on a given page, improving their user’s experience and (2) it reduces the need for web developers to design a single user interface for both automated browsers and humans (e.g. screen area and the accessibility tree).

However, in an adversarial setting there is a risk that sites will provide tools that do not match the experience of a user on the page for a variety of reasons. This may be to tar pit automated browsers, provide prompt injection that is invisible to typical users, collect user data from the inputs of the tools, or otherwise manipulate a user’s browsing “agent” in a way that is to the user’s disadvantage. These are significant risks, though it is not clear to what extent they are exacerbated by this API or if they are inherent to LLMs consuming content from and driving a browser.

One area of potential future direction for WebMCP would be to define standard tools or provide a mechanism for their definition. This API is a bit backward from normal: the site is providing an interface to the browser. It’s hopeless to standardize all websites into a single interface for browsers, and even probably hopeless to get even a single complex website to commit to one backward-compatible interface. Subsets of core functionality of classes of websites may be within reach and could open up a much more consistent web for stochastic assistants.

The name is misleading, focusing on how tools are exposed rather than the capability granted and confusing developers that (reasonably) assume the MCP spec is involved in any way. There is no MCP here. While a tool like a headless browser might choose to expose page tools over the MCP protocol in order to be consumed by an MCP client, it’s a strange and unnecessary branding decision for a web API. Something like Website Tool API, or Agent Capability API, would be better and more future proof.

Declarative WebMCP provides the site operator a chance to, in cooperation with the user, prevent malicious actions by a prompt-injected agent, by disallowing tool auto submit and carefully defining the form’s visible elements. However, this is no defense against a malicious site. Declarative WebMCP also lowers the bar for adoption, particularly in use cases where agents and users are being directed toward the same interfaces.

This API, if successful, provides a mechanism for meaningful improvement of web browsing agents. As of now, use of this mechanism is restricted to browser developer’s own products and in-page agents. An important step to ensuring an open ecosystem of web browsing agents is opening up tool invocation to other consumers, by adding WebExtension and WebDriver BiDi integrations.

Overall, WebMCP introduces a potentially valuable abstraction for aligning websites and web browsing agents, but it also opens a surface whose real-world dynamics leave too many open questions to wholeheartedly endorse. Given that, I propose we mark this as neutral and be willing to come back to revisit it once there is more evidence of how it will be used by sites.