WebMCP Adoption: Are We There Yet?
Since March, I have been exploring WebMCP from several angles: what it changes for web applications, how Angular supports it at the framework level, and whether the same tools can be called by an agent outside the browser. Those experiments were mostly about one question: what can we build with WebMCP?
Now a more interesting question is emerging: is anyone actually adopting it?
How I am looking at adoption
Before looking at adoption, it is worth separating two things.
WebMCP is still a proposed web standard. The API can change, browser vendors have not reached consensus, and no browser exposes it today as a stable, broadly available platform feature.
At the same time, a community is beginning to form around WebMCP. I see that every time I speak about it at a meetup: people stay after the talk to ask what it is, how it differs from browser automation and traditional MCP servers, and whether they can already use it in their own applications.
But curiosity is not the same as adoption.
To understand whether that curiosity is translating into adoption, I think we need to separate several signals that are easy to group together. A browser implementing the API makes WebMCP available, while an agent supporting it provides a potential consumer. A website or platform exposing tools creates supply, and tooling makes those integrations easier to build and maintain.
Actual usage is another stage. It begins when compatible agents discover those tools and people use them to complete real tasks. The earlier signals make that possible, but none of them tells us on its own how often WebMCP is being used or whether users find it valuable. I will therefore treat browser support, agent support, developer readiness, platform enablement and end-user usage as related but distinct parts of the adoption story.
The best place I have found to follow these signals is the WebMCP Ecosystem Adoption Tracker. It brings browser implementations, agents and agent frameworks together in one place, and distinguishes between documented support, hands-on verification and the absence of a public signal. I use it throughout this article as a map of the ecosystem, but not as a measure of end-user adoption because it does not provide production usage data.
Browsers: Chrome moves first
Chrome is the furthest along. Since Chrome 149, WebMCP has been available through an origin trial that runs through Chrome 156. This allows registered websites to expose WebMCP tools to real visitors, not only to developers who enabled an experimental browser flag.
For example, my own website, pawelkubiak.dev, is one of them. It already serves an origin-trial token, so the WebMCP tools I built for it can run on the live website in compatible versions of Chrome. WebMCP can run in production today, but it is not yet a stable production API. It works because the website participates in a time-limited browser experiment.
Chrome Platform Status currently points to Chrome 157, scheduled for November 3, 2026, as the anticipated milestone. But “anticipated” is the important word here. It is a target, not a commitment to ship, and the final decision will follow the origin trial.
Chrome is no longer the only Chromium browser experimenting with the API. Microsoft says its WebMCP implementation in Edge is ready for testing and has published sample websites together with a WebMCP Explorer extension. This remains an early testing capability rather than stable browser support, and the announcement does not say that Copilot in Edge can consume those tools.
The situation becomes more complicated once we look beyond Chrome. Firefox does not support WebMCP, and Mozilla has not published a final standards position yet. The issue currently carries a position: neutral label, but its review status is still Position is proposed, so it should not be read as Mozilla’s final position on the proposal.
Safari does not support WebMCP, and WebKit has taken an opposing position. Its concerns cover areas including API design, duplication with existing web capabilities, portability, privacy, security and the standardization venue itself.
So the browser story is not that WebMCP is shipping everywhere. Chrome and Edge are testing implementations, Mozilla is still reviewing the proposal, and WebKit disagrees with the current direction.
Agents: ChatGPT is here, Gemini is still coming
For a long time, WebMCP had a producer side without an obvious consumer. A website could register tools, Chrome could expose them and developers could inspect their behavior, but there was still a fundamental question: which agent would actually use them?
ChatGPT provided the first practical answer with Site Tools in the browser built into its desktop app. Site Tools are OpenAI’s implementation of the proposed WebMCP standard, allowing ChatGPT to discover the tools exposed by the current page and invoke them while working with the live website and its signed-in session. The same support is available to both ChatGPT Work and Codex, although it currently requires GPT-5.6 Sol or GPT-6 Sol.
ChatGPT’s implementation currently supports only a subset of WebMCP. It does not expose declarative tools defined through HTML form attributes and does not discover tools registered inside same-origin or cross-origin iframes. Developers targeting Site Tools therefore need to register their tools through JavaScript on the top-level page.
I tested this with my own WebMCP tools and confirmed that ChatGPT Work could discover and invoke them directly from the page. This is the point at which WebMCP stopped feeling like an API waiting for its future consumer: I could expose a tool on a real website, open that website in ChatGPT and ask the agent to use it. OpenAI also made Site Tools available during the WebMCP Challenge, giving developers a working agent against which they could test what they were building.
Google announced a similar direction at Google I/O in May 2026, saying that Gemini in Chrome would soon support WebMCP APIs. That connection has not shipped publicly yet, and Google has not provided a release date. Chrome currently exposes WebMCP through its origin trial, but its documentation still treats WebMCP as separate from the Gemini in Chrome features.
ChatGPT currently provides one of the most accessible ways to test WebMCP with a working agent, while Gemini in Chrome remains an announced integration without a public release. That makes Site Tools a practical reference point for developers without implying that ChatGPT is the only WebMCP consumer in the wider ecosystem.
Tooling is growing around WebMCP
Browser support and agents are only two parts of the adoption story. Developers also need practical ways to define WebMCP tools within their application architecture, inspect what the browser exposes and verify that agents continue to use those tools correctly as the application evolves. We are starting to see progress across all of those areas.
Angular now provides experimental framework-level support for WebMCP. Tools can be registered at the application or route level and connected to Angular’s dependency injection lifecycle, which takes care of registering and removing them together with the relevant part of the application. Angular can also expose Signal Forms as WebMCP tools, deriving their schemas from the form model and connecting tool execution to the existing validation and submission flow.
Chrome is developing the debugging side as well. The dedicated WebMCP panel in Chrome DevTools shows which tools are currently registered, how their descriptions and schemas appear to an agent and how often they have been called. Developers can inspect the parameters and results of individual invocations, see errors and canceled calls, and execute a tool manually without waiting for an agent to select it.
Manual testing can confirm that a tool works for a specific set of parameters, but WebMCP introduces another source of uncertainty. The implementation may be correct while the agent still selects the wrong tool, provides unexpected arguments or calls several tools in the wrong order. Traditional unit and integration tests remain useful for deterministic application logic, but they cannot fully test decisions made by a generative model.
This is the problem the Chrome team is addressing with the WebMCP Evals CLI. It can evaluate tool descriptions and schemas in isolation, run user journeys against tools exposed by a live website and execute deterministic smoke tests without involving a model. The project is also expanding toward multi-step scenarios, reports and automated analysis of failures, which makes it possible to test not only whether a tool executes, but whether an agent understands when and how to use it.
I explored this topic earlier in Bringing Agent Evals to WebMCP. Evals do not make agent behavior deterministic, but they make its reliability measurable. When a tool description, schema, model or browser implementation changes, the same user journeys can be executed again to detect regressions before they reach users.
These tools cover three different stages of the development workflow. Angular handles registration and lifecycle, Chrome DevTools shows what the browser and agent can see, and evals make it possible to rerun the same journeys after a schema, model or implementation changes. A team can now investigate failures at each of those stages instead of treating every incorrect agent action as the same kind of problem.
Shopify changes how WebMCP can be distributed
One of the developments that caught my attention the most is Shopify. It now provides WebMCP tools on every Liquid storefront and on storefronts built with the Hydrogen developer preview, without requiring merchants to install or configure anything!
An agent supporting WebMCP can use those tools to search the product catalog, work with the shopper’s cart and navigate the storefront. Because the tools operate within the shopper’s current browser session, actions performed by the agent can update the same cart and interface the user sees.
What interests me here is not only the number of storefronts that can expose WebMCP tools, but the distribution model behind it. Until now, I mostly thought about enablement as a decision made by an individual development team: developers discover WebMCP, choose which capabilities to expose, implement the tools and gradually make their application agent-friendly.
Shopify shows that enablement can happen at the level of an entire platform. Once WebMCP becomes part of the underlying infrastructure, thousands of storefronts can gain the same capability without every merchant or development team implementing the standard from scratch.
That is significant, but it is a measure of potential reach rather than active usage. Shopify can make WebMCP available across its storefront infrastructure, but that does not tell us how many agents discover those tools, how often shoppers ask agents to use them or whether those interactions lead to completed purchases.
Platforms can still have a major effect on how quickly WebMCP spreads because they remove the need for website-by-website implementation. Whether that distribution turns into adoption will depend on the other side of the market: compatible agents and users choosing to complete real shopping journeys through them.
PayPal and Stripe bring WebMCP to checkout
Shopify shows how an agent can interact with a storefront. PayPal adds another part of the journey by moving from product discovery and cart management toward an actual transaction, while keeping the final payment decision under the buyer’s control.
PayPal recently published its work on making merchant storefronts accessible to WebMCP-compatible assistants while keeping checkout inside PayPal’s existing payment experience. In the flow described by PayPal, an agent can search for products, select an item, prepare the cart and initiate checkout. The buyer is then handed over to PayPal to sign in, confirm the funding source, review the transaction and approve the payment.
While I was writing this article, Stripe also published documentation for using WebMCP with its payment interfaces. Stripe exposes structured tools across its hosted Checkout, embedded forms, Elements and hosted invoice pages. Depending on the interface and the current state of the payment session, an agent can read the checkout context, select a payment method, fill in the required fields and, where Stripe controls the action, initiate payment submission.
The Stripe documentation also shows why tool discovery needs to remain dynamic. The tools and their schemas can change as the customer moves through the payment flow, for example after selecting a payment method that requires a different set of fields. Stripe therefore tells agents to discover the available tools again after actions that change the form and to fall back to regular browser automation when the required capability is not available.
Both approaches reinforce an important distinction: agentic commerce does not have to mean fully autonomous commerce. An agent can remove the repetitive parts of the shopping and checkout journey while the user remains responsible for the sensitive decision at the end. That feels much closer to how I expect many practical agent experiences to work, especially around payments and other actions that are difficult to reverse.
As with Shopify, these integrations demonstrate capability and distribution rather than active use. PayPal and Stripe are making parts of the transaction layer available to compatible agents, but neither announcement tells us how many real customers are completing payments through WebMCP.
Early evidence: PayPal's benchmark
PayPal also published early results from a sandbox benchmark in which an AI assistant completed the same gift-card purchase with and without WebMCP. The WebMCP-enabled flow used approximately 4.6 times fewer model-inference resources, completed around twice as fast at the median and replaced more than 30 interface-interaction steps with three structured tool calls.
Those numbers need to be treated carefully. PayPal describes them as directional results from a small internal benchmark, and the outcome will depend on the website, task and agent being tested. They do not prove that every WebMCP flow will be faster or cheaper than browser automation, but they do move the discussion in a useful direction.
Until now, one of the main arguments for WebMCP has been intuitive: structured tools should require fewer steps and less interpretation than asking an agent to operate an interface built for humans. PayPal’s benchmark gives us an early example of how that assumption can be measured, while Stripe shows that the same idea is already making its way into another major payment infrastructure.
This is the kind of evidence I would like to see more of. We should be comparing the number of steps, inference cost, completion time, tool-selection accuracy and overall success rate against the same journey performed through regular browser automation. WebMCP becomes much more interesting when we can evaluate it as an engineering trade-off rather than only demonstrate that an agent can call a tool.
Should you experiment with WebMCP today?
My answer is yes, provided the scope stays small. I would start with one concrete interaction where the user’s intent is clear and the result can be measured, rather than trying to make an entire product agent-friendly or designing a critical journey that depends on WebMCP being available.
That could be a product search, a set of filters, a cart operation, a booking lookup or a form. Expose the interaction as a structured tool, keep the existing interface as the fallback and compare how an agent completes the same task through both paths. Measure how many steps it takes, whether the correct tool is selected, how invalid inputs are handled and whether changes made by the agent remain synchronized with the interface.
Build an eval around that journey and record a baseline for tool selection, arguments, completion time and success rate. When the schema, browser or model changes, rerun the same evaluation and compare the result. One useful journey, a safe fallback and a repeatable measurement will teach you more than exposing a large collection of tools without knowing how reliably an agent can use them.
So, where are we?
When I compare the WebMCP ecosystem today with what I wrote about in March, the biggest difference is not that the standard has become mature. It is that the pieces required for adoption no longer have to be assembled entirely by an individual development team.
Those pieces still represent different stages, and public evidence of end-user adoption remains limited. Browser implementations, compatible agents, developer tooling and platform integrations show that the conditions for adoption are forming, while PayPal’s benchmark offers controlled evidence of potential efficiency rather than production usage at scale.
There are still good reasons to remain cautious: the API is changing, browser vendors have not reached consensus, Gemini in Chrome has not arrived and the number of compatible agents remains limited. Even so, describing WebMCP as only a Chrome experiment no longer captures what is happening around it.
The experiment is not finished, but it is starting to look like an ecosystem.
Comments