WebMCP Connects AI Agents To Actions Inside Websites

0
1
WebMCP Connects AI Agents To Actions Inside Websites


In May, Google shared guidance for making websites usable by both AI agents and people. WebMCP was one of several technologies Google pointed to, though it still looked like a browser experiment.

Now, in August, we have more concrete updates. Shopify said WebMCP tools were live on every Liquid storefront. The very next day, Cloudflare introduced a developer preview that adds a WebMCP bridge right at the network edge.

On Aug. 25, OpenAI added Site tools to ChatGPT’s built-in desktop browser. For eligible users, ChatGPT Work and Codex can discover and use tools provided by the current page.

Ilya Grigorik, a Distinguished Engineer at Shopify, explained that ChatGPT’s browser can use site-provided tools on Shopify storefronts to browse merchant catalogs and assemble shopping carts. While this doesn’t mean it’s being used everywhere just yet, it does create a useful link between sites that offer tools and an AI system that can actually use them.

One of the key points to consider is control. WebMCP gives a website the ability to guide an agent’s behavior, but the current implementations also involve commerce platforms, infrastructure providers, and agent companies. The site owner may not be the only party shaping that interface.

Why August Changed The Story

Chrome announced an early WebMCP preview on Feb. 10 and opened a Chrome 149 origin trial on June 9. The proposal already had a draft specification, demos, and browser testing, but it still lacked a platform-wide site deployment and an agent client people could use.

Shopify supplied the sites, OpenAI supplied the client, and Cloudflare showed how an infrastructure provider can add the interface without changing code at the site’s origin. Additionally, OpenAI kicked off a 10-day WebMCP Challenge with support from Google Chrome, Shopify, Cloudflare, Netlify, Vercel, and Render.

While this doesn’t mean widespread adoption yet, it shows that several companies are exploring this idea.

How WebMCP Changes A Browser Task

Browser agents usually work with interfaces made for people. They look at a screenshot or page layout, understand what each control does, and then imitate clicks and typing just like a user would. However, each step in that process can be prone to little mishaps. For example, a button label might change, an unexpected pop-up could show up, or a custom date picker might appear, all of which can momentarily disrupt the flow.

WebMCP gives the page another route. A website can register a named tool with the browser, along with a description and structured input schema. An agent can discover the tool, send the required details, and receive structured data.

Chrome’s comparison between WebMCP and MCP describes the relationship as follows:

“Instead of your application being a guest within an agent, the agent is a guest on your platform.”

ChatGPT might rely on standard browser functions if a page doesn’t have a suitable Site tool.

Shopify Shows Where The Agent Interface Comes From

Shopify provides 10 WebMCP tools on every Liquid storefront, and they are also available on storefronts using its Hydrogen developer preview.

Shopify’s proceed_to_checkout tool takes the shopper to checkout with the current cart, but it doesn’t complete the purchase. All interactions happen within the customer’s active tab. Any updates to the cart are immediately reflected, and navigation will take the customer to the page the agent has chosen.

Shopify explains that the agent chooses the right tool based on what the customer requests. This creates a second layer of control. WebMCP lets a website declare its available actions, but Shopify selected the initial actions and descriptions across its platform.

While this setup can make things easier for merchants, it also means that the agent-facing version of a hosted storefront might start with default settings set by the platform, rather than personalized preferences from each merchant.

Shopify’s published WebMCP documentation does not address whether merchants can turn off individual tools or edit their descriptions.

Cloudflare Injects The Bridge At The Edge

Cloudflare’s developer preview makes it easy for websites to turn on WebMCP right from the Cloudflare dashboard, without needing to change their site’s original code. Once it’s activated, Cloudflare adds one line to each HTML response at the edge, referencing a same-origin bridge script. The bridge checks for browser support and registers the selected tool packs. In the current preview, the tools run inside the visitor’s browser rather than on Cloudflare’s servers.

Shopify installs a uniform set of tools across hosted stores, while Cloudflare provides a bridge without modifying the original code. In both cases, the agent-facing layer comes partly from a company between the site owner and the agent.

Discovery And Action Are Separate Problems

The current WebMCP documentation describes an in-browser interaction layer, not a ranking, indexing, or citation feature. The tools become available after a compatible agent opens the page, while existing discovery systems determine how the agent or user reaches the site.

This makes WebMCP a bit different from many AI search discussions, because a site can be friendly to agents without necessarily being easier for users to find. WebMCP is designed for a different purpose than MCP; for instance, a remote MCP server can offer tools even without an open webpage, whereas WebMCP tools are temporary and tied to the current tab.

These systems can work well together: a user might find a merchant through a search, visit its site, and then allow an agent to use the available tools. For SEO professionals, it’s helpful to keep in mind that WebMCP is mainly relevant once a user or agent has reached the site. It focuses on what can be done afterward, rather than on the page’s ranking or citations.

Signed-In Sessions Can Pose Security Risks

WebMCP can operate within the user’s live session. That is part of its appeal, and it is why Chrome’s security guidance focuses on authenticated state. An agent can access cookies, session info, and page context available in the live tab, making it easier to avoid the need for a separate login. However, this also means the tool runs inside an authenticated session.

Chrome highlights two main risks: malicious tool definitions that hide instructions in their name, parameters, or description, and responses that can return contaminated content, including embedded instructions from third-party data. Even without WebMCP, Chrome’s security guidance acknowledges these risks. While the protocol offers a structured way for agents to interact with tools, it can’t prevent prompt-injection issues that are inherent to the web.

OpenAI views website-provided tool definitions and results as untrusted. Every Site tool call goes through a safety review, with standard rules applied to purchases, messages, deletions, and permission changes. Users also have the option to turn off Site tools in ChatGPT’s browser settings.

While these checks are helpful in reducing risks, they don’t guarantee that a website or its output is completely trustworthy. SEJ has already highlighted Chrome’s warning that WebMCP tools could manipulate agents. The new controls introduced by OpenAI add an extra layer of protection, but they don’t promise to fully solve the issue.

Browser Support Is Still Narrow

The W3C Web Machine Learning Community Group has published the WebMCP specification. It is not a W3C Standard and is not on the W3C Standards Track.

OpenAI documents WebMCP support through Site tools in ChatGPT’s desktop app. The WebMCP implementation tracker lists origin trials for Chrome 149 and Edge 150, along with experimental support through Brave Leo. According to Benjamin VanderSloot on Github, Mozilla’s standards position is neutral and according to Mike Wyrzykowski on Github, WebKit opposes the proposal and lists concerns involving API design, duplication, internationalization, portability, privacy, security, use cases, and venue.

The implementation tracker does not list WebMCP support for Firefox or Safari. The majority of existing support is focused on Chromium-based browsers and the OpenAI desktop application.

OpenAI’s Site tools require the latest ChatGPT desktop app, ChatGPT Work or Codex, and GPT-5.6 Sol or Terra. They’re unavailable with GPT-5.6 Luna and in Enterprise or Edu workspaces. Availability also depends on rollout and the tools provided by the current page. Shopify’s tools require a compatible WebMCP agent and browser environment.

What Has Not Been Demonstrated

OpenAI and Chrome highlight WebMCP as faster and more reliable than simulated browser actions. However, the official materials reviewed for this draft don’t include specific performance comparisons. Neither the OpenAI nor the Shopify sources provide figures for site tool calls, completed tasks, error rates, checkout starts, purchases, or changes in conversion rates. They also don’t clarify what merchants can see in their analytics or how agent-assisted sales are attributed.

Cloudflare Radar tracks detected WebMCP adoption across successfully scanned domains. It doesn’t measure tool calls, completed tasks, or business outcomes.

The sources reviewed don’t show a preference among agents for sites with WebMCP, nor do they reveal whether users are requesting shopping through this method. The sources reviewed also do not show whether the tools affect which merchant gets selected.

Based on what’s available, the only clear point is that WebMCP is currently active on some live sites and compatible with agent clients. However, how it’s used in practice and its actual impact on business remain uncertain.

Looking Ahead

WebMCP has moved beyond a browser demo and now runs in live products. It remains experimental, and it’s too early to say how well it works, or how widely it will be adopted.

More resources:

 


Featured Image: Jack_the_sparrow/Shutterstock