Repository navigation
WebMCP #1412
Description
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)
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:
- 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...)
- 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
Activity
bvandersloot-mozilla commentedon Jun 1, 2026
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.
domfarolino commentedon Aug 24, 2026
By way of an update to this thread, we've had more discussions with Mozilla folks (Jake and Martin) who have expressed interest/support for the imperative API, and not the declarative API, and have some API shape recommendations and more, most of which I think we're supportive of!
In that case, I hope it's OK if I ask for clarification here:
jakearchibald commentedon Aug 25, 2026
To clarify, I haven't really looked at the declarative API. It sounds like a reasonable idea, but I don't think it should be instead of an imperative way to call functions between environments.
martinthomson commentedon Aug 26, 2026
webmachinelearning/webmcp#236 (your "and more") is pretty significant here. As is naming. But this position is not really based on the declarative variant. It's an interesting thing to contemplate, but, as Jake says, it's not a significant factor.
domfarolino commentedon Aug 26, 2026
The reason I ask is because most of Mozilla's interest in the API has been in precisely the declarative variant (see #1412 (comment) for example). This seemed to have changed recently so I want to better understand the impact it'd have on the position.
Oh yeah, declarative would never come at the cost of imperative. Our current thoughts are they'd co-exist. But that's what I want Mozilla's opinion on. I think the options are:
Agreed. I responded over there in webmachinelearning/webmcp#236 (comment) to tease out some of the specifics.