Repository navigation
WebMCP #670
Description
WebKittens
Title of the proposal
WebMCP
URL to the spec
https://webmachinelearning.github.io/webmcp/
URL to the spec's repository
https://github.com/webmachinelearning/webmcp
Issue Tracker URL
https://github.com/webmachinelearning/webmcp/issues
Explainer URL
https://github.com/webmachinelearning/webmcp/blob/main/README.md
TAG Design Review URL
Mozilla standards-positions issue URL
mozilla/standards-positions#1412
WebKit Bugzilla URL
No response
Radar URL
No response
Description
Note that #649 exists, but it lacks context, and was not published by the authors/editors of this feature, so I'm publishing this request for a position in hopes of obsoleting that old one, and providing updated links and more details here. We did the same thing for the Mozilla position.
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
marcoscaceres commentedon May 28, 2026
duplicate of #649 ... @domfarolino, mind moving the comment and cc's to the other issue 🙏?
domfarolino commentedon May 28, 2026
I'd prefer to use this issue as the source of truth, instead. It has updated links to the explainer and spec, and is actually filed by the proposal authors. Please read the first paragraph of the description of this issue. I can't edit the OP of #649 so it'll just be difficult to work over there. We'd prefer to close the old outdated one in favor of this one, just like we did with the Mozilla standards position.
mwyrzykowski commentedon Jun 3, 2026
WebKit is opposed to this proposal due to the following concerns:
Although browser-integrated agents could struggle to act on interfaces built for humans, we do not think a parallel agent-facing tool layer is the right solution. When a site's actions are hard for an agent to use, that is a gap in the page's own semantics, and the fix, in our opinion, is to close it in the platform's shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit. Describing those actions a second time as JavaScript tools would not deliver the reliability it promises: the agent still selects and interprets a tool from its natural-language name and description, which the specification itself concedes are ambiguous and unverifiable, with "no guarantee that a WebMCP tool's declared intent matches its actual behavior." A typed schema constrains an argument's shape, not the meaning the agent must infer, so the brittleness just moves from the DOM into the tool descriptions.
Our deeper concern is architectural. An agent acting on a user's behalf is, in effect, assistive technology: it should operate a site as the user would, and the site should not single it out for different treatment. WebMCP does the opposite, making "an agent is driving" an observable fact. Once that is separately addressable, nothing keeps the agent-facing and human-facing surfaces in parity: through
exposedToand the open "built-in agent exposure by default" question, a site can give agents capabilities it withholds from its human UI (disadvantaging anyone without an agent), or withhold them from agents (the "screen-reader-blocking problem", but applied to AI agents). It is also not clearly portable, since the richest surface may flow to a built-in agent not every engine ships. We are not convinced an API whose primary effect is to make agent-driven interaction separately addressable is the right foundation.Several risks compound this, and the spec leaves its hardest parts open. It is a new cross-origin invocation path (tools shared via exposedTo, agents carrying state across origins) whose interaction with the platform's isolation model (COOP, COEP, site isolation) is unexamined; it has no consent or reversibility model for consequential actions (
readOnlyHintis advisory,toolautosubmitsubmits without review); and it lets a site over-parameterize a tool so a helpful agent fills it from personalization the user never gave that site, which the spec itself calls a "personalization-to-fingerprinting" pipeline enabling cross-site tracking. The parts that would let anyone judge safety and interoperability, the declarative schema-synthesis algorithm, the cross-origin security analysis, and the consent hook, are each still a "TODO."Despite the name, the spec "does not prescribe the format in which tools are exposed" and says browsers may expose them "via Model Context Protocol, other proprietary 'function calling' methods, or any other way." So this is not really an MCP binding: it is a general mechanism for a page to register typed, callable functions for an external caller, not limited to forms or even to AI, and that belongs with the platform's existing messaging and capability mechanisms (
postMessageand similar), not a parallel one.On accessibility, the proposal says WebMCP "is not designed for ingestion by accessibility technology", the same fork: richer, actionable semantics reach agents while screen-reader and keyboard users get less. And tool and parameter descriptions, both machine-read and potentially shown in agent UI, carry no language or direction.
We also flag the README’s open questions and a Service Workers explainer, even if not yet in the spec, as it would extend tools to background Service Workers so agents can "discover and invoke tools on sites the user doesn't currently have open." Invoking authenticated, side-effecting tools with no open tab and no human present magnifies every concern above.
Finally, the Machine Learning CG/WG venue is wrong for the work. The gaps WebMCP identifies are in HTML and accessibility semantics, stewarded by WHATWG and the W3C ARIA and Accessible Platform Architectures Working Groups; a group chartered around machine learning is not the place to decide how HTML and ARIA should evolve.
I suggest we resolve this as position: oppose one week from now.
domfarolino commentedon Jun 11, 2026
Thanks for the clear feedback. While the proposed position has been submitted, I'm hopeful we can turn this thread into a productive dialogue about the feature, as its development is still early and subject to change, and we think converging on something every browser agrees on is within reach. Furthemore, it's super important to get this right as we all figure out what the "agentic web" looks like, and how best to serve users. Some responses below.
In that case, how does WebKit feel about just the declarative WebMCP API? It offers some very lightweight markup to forms—and we're brainstorming how this could extend to other elements—that still lets the agent actuate UI elements better. If WebMCP only consisted of the declarative variant, would this satisfy WebKit?
Regarding the imperative API, our belief is that virtually all other functionality that will need to be exposed to agents will have already been implemented in the site's JavaScript, which is where frameworks store much of their state and manage most interactions. So we're hopeful that imperative tools don't create a "parallel" web, but rather provide thin-wrappers over existing functionality, making it more accessible by agents. Are there any specific changes to the imperative API, short of ripping it out, that would satisfy WebKit? Any feedback on this part would be great to hear!
I think the declarative API keeps us pretty close to this vision. Still, I'm having a hard time squaring this with the reality of how most agents actuate real web content. While they use computer vision models, whenever they can they prefer a more programatic "toolified" approach to UI, to improve latency and accuracy. For example, most agent extensions actuate web UI by injecting JavaScript to click buttons and interact with forms, which is very unlike what the user would do. Some even use lower-level tools like the chrome.debugger API to access the underlying DevTools protocol. Additionally, when agentic IDEs spin up a browser to test if the changes they helped make to a site match expectations, our experience shows they prefer going through something like a DevTools MCP server to toolify higher-level actions. With that said, as long as agents prefer to use sites any different than humans, or take advantage of agent-aimed markup in the DOM, their use of a site will almost certainly be observable.
Is WebKit's support on an API like WebMCP predicated on making the agent unobservable? Or does WebKit believe that the toolified approach to developer tooling is sound, but that web authors should do no such thing to their sites to make them more agent-compatible?
I'd like to clarify our note that WebMCP "is not designed for ingestion by accessibility technology". While WebMCP—with its JSON schemas and callback functions—is optimized for programmatic agent consumption, rather than direct exposure to traditional screen readers, it's becoming clear that agents taking advantage of these tools stand to complement traditional accessibility technology, bringing its users unprecedented autonomy. From that angle, we see WebMCP and similar agentic technologies as a massive boon to accessibility on the web, just occupying a different place on the stack. We are happy to clarify this in the explainer.
So, no part of the API precludes it from being used as a strongly-typed messaging capability like
postMessage(), etc. Can you clarify what the actionable feedback is here? What would you like to be seen done differently?This is a huge capability being discussed, and we agree that it's a tough thing to get right. However, we will note that the purpose of agentic browsing/computing is exactly that—an agent invoking tools on sites that the user doesn't have open. This might come in the form of the agent navigating to sites that aren't open, or interacting with background Service Workers through DevTools or first-class Web APIs etc. We don't yet know how this will look, or if there is a place for background tools specifically, but collaborating on the right security model for this through both traditional web platform security mechanisms, and requirements or recommendations on agents invoking them, is something we'd love to do.
marcoscaceres commentedon Jun 17, 2026
Thanks for following up. The problem the community is trying to solve is real and worth solving: AI agents and tooling already help users with everyday tasks and can improve browsing. We want to help solve it.
We've read your questions, and we want to be straight about why we're not going to answer them point by point: each one asks us to evaluate a part of WebMCP on the assumption that the rest of the approach is sound, and that assumption is what we're opposed to, for the reasons in our position. So rather than debate individual pieces, we want to reframe from first principles.
Our view is that WebMCP proposes a new solution before the actual problem has been established. Before designing anything, the proposal needs to answer the following (not here, but in the venue described below):
Any solution also has to start from invariants that put users in control. For us these are not negotiable:
If we agree on those, here is the path we'd suggest:
We think that gets everyone, including the wider web community, to a better answer than iterating on WebMCP as it stands. We'd like to do this work with you on this, as it has architectural implications across a range of APIs.