The web was designed for people. Buttons tell us where to click, menus show us what is available and forms tell us which information a website needs. Product pages arrange information so a shopper can compare options and decide what to buy. AI agents do not necessarily need any of that.
Until now, browser agents have largely had to use websites the way humans do: interpret the page, locate the relevant interface element, click it, wait for the result and inspect what changed. That approach can work, but it is inherently fragile. Interfaces move, buttons change, dynamic pages behave differently and visual interpretation introduces another opportunity for error.
WebMCP proposes something fundamentally different. Instead of forcing the agent to understand how to operate the human interface, the website can expose structured tools describing what the agent is allowed to do: search the catalogue, retrieve a product, add an item to the cart, update a document, run an analysis or navigate somewhere. The browser can discover those tools and make them available directly to the AI. That sounds like another developer standard, but the strategic implication is more interesting: websites could begin developing two interfaces at once, one designed for people to navigate and another designed for agents to invoke.
WebMCP is MCP brought into the webpage
WebMCP is an experimental, proposed web standard for allowing web applications to register structured tools with the browser. An AI agent operating in that browser can discover the tools, understand their inputs and outputs, and call them directly rather than trying to infer the same action from the page's visual interface. OpenAI describes the objective simply: websites define how agents can use the application so tasks can be completed more quickly, accurately and reliably.
The distinction from conventional MCP is important. A traditional MCP server usually sits outside the webpage. An AI client connects to a service endpoint, discovers available resources or tools and invokes them remotely. That is useful when an agent needs programmatic access to Salesforce, Apollo, Shopify or another business system regardless of whether a human has the application open. WebMCP moves the interaction into the browser session itself.
OpenAI's current implementation calls these capabilities site tools. When a supported website is open inside the ChatGPT desktop application's built-in browser, ChatGPT can discover tools provided by that page and use them while the user remains in the live browsing session. The tools are available only while the relevant webpage is open and remain scoped to the page providing them. That creates a different relationship between the user, the agent and the website: the website does not disappear behind an API; the agent joins the user inside it.
The easiest analogy is an accessible entrance for agents
Without WebMCP, an agent trying to use a website resembles somebody entering a building and working out what everything does by observation. It sees a button and infers that pressing it might add a product to a basket. It sees a search field and guesses how the search behaves. It reads rendered content or underlying markup to understand the page. To complete a task, it effectively reproduces the user's clicks and typing.
WebMCP allows the building to provide another entrance. Instead of asking the agent to deduce how the interface works, the site can expose something equivalent to:
- Search catalogue: inputs such as query and filters.
- Get product: input such as product identifier.
- Update cart: inputs such as product, variant and quantity.
The human interface still exists. The agent simply has a more appropriate way to interact with the same application. This is why WebMCP should not be interpreted as an attempt to eliminate web design. Humans still need product pages, visual hierarchy, navigation, imagery and interfaces. Agents need something different: machine-readable capabilities, predictable inputs and structured responses. The same website can provide both.
Shopify makes the idea suddenly tangible
Shopify is where WebMCP stops feeling like a browser experiment. Shopify now provides WebMCP tools across every Liquid storefront, with support also available for storefronts using the Hydrogen developer preview. Shopify says merchants do not need to install or configure anything for the standard tools. Compatible agents can use them to search catalogue content, browse products, retrieve product details, manage the shopper's cart, proceed towards checkout, access order history and answer questions using store policies and FAQs.
Crucially, these tools operate in the shopper's live storefront session. If an agent adds something to the cart, the shopper sees the cart change. Navigation takes place in the page the shopper is already viewing. Shopify's standard storefront actions provide the underlying behaviour, allowing agents to interact with the store without attempting to reverse-engineer every merchant theme.
That is a significant deployment surface. Millions of Shopify-powered commerce experiences can potentially become more directly usable by compatible browser agents without every merchant independently engineering a bespoke agent integration. The practical difference can be illustrated with a request such as: Find me a waterproof jacket in navy, available in medium, below £150, and add the best option to my cart.
A conventional browser agent may inspect the site, find the search box, enter terms, interpret results, open candidate products, manipulate filters, select a variant and eventually locate the add-to-cart button. A WebMCP-capable experience can expose catalogue and cart operations directly. The AI still needs to interpret what the customer wants and make a sensible recommendation, but the mechanics of interacting with the shop become structured. The intelligence remains probabilistic. The execution becomes more deterministic.
This could change what it means to optimise a website
For two decades, digital optimisation has concentrated on the human journey. Can the customer find the navigation? Is the call to action obvious? Does the page load quickly? Is checkout friction low? Does the content answer the right questions? Those requirements do not disappear, but WebMCP introduces another audience: the agent.
If users increasingly delegate web tasks to AI, businesses will need to consider not only whether a site is understandable to people and discoverable by search engines, but whether its useful capabilities are legible and actionable to agents. That potentially creates a new layer of digital experience design. Search engine optimisation made websites legible to indexing systems. Structured data made page content easier for machines to interpret. APIs made application capabilities accessible to software. WebMCP could make those capabilities directly actionable by agents operating in the browser.
For retailers, the immediate possibilities are obvious: product discovery, comparison, basket creation and commerce assistance. But the concept extends far beyond shopping. OpenAI's WebMCP Challenge currently highlights examples spanning collaborative writing, travel planning, data analysis, 3D modelling and interactive content. The common pattern is not commerce. It is a website exposing meaningful actions so the human and the agent can use the application together.
Agent-native does not mean agent-only
A simplistic version of the agentic-web argument assumes AI will eventually bypass websites completely. Users will tell an assistant what they need, the assistant will transact through back-end APIs, and the traditional web experience becomes irrelevant. WebMCP points towards a more nuanced future.
The website can remain the environment in which the experience occurs while also providing tools to the user's agent. That creates the possibility of collaborative browsing rather than simple automation. A customer might visually explore products while asking an agent to narrow the range according to technical criteria. The agent can search the catalogue through a structured tool, while the customer evaluates photography and branding on the page. The agent can configure the cart, while the user retains visibility of the transaction before checkout.
OpenAI explicitly frames the WebMCP Challenge around applications becoming better when people and their agents use them together. That is potentially a much more important design principle than simply giving an autonomous system permission to click everything on behalf of the user. The future interface may therefore be neither human nor agent. It may be human plus agent.
Commerce is becoming a stack of agent-readable protocols
Shopify also illustrates how WebMCP fits into a wider architecture. WebMCP handles the interaction with tools provided by the live website. Shopify separately exposes Storefront MCP servers that agents can connect to outside the browser, giving access to catalogue, cart and policy capabilities for a particular merchant. Its Global Catalog MCP extends discovery across the broader Shopify merchant ecosystem.
Underneath that, Shopify's newer catalogue interfaces implement the Universal Commerce Protocol, or UCP. UCP is an open commerce standard intended to give AI agents, businesses and commerce platforms interoperable capabilities without requiring a bespoke connection for every pairing. The protocol defines commerce capabilities and can work through transports including MCP.
- UCP describes commerce capabilities.
- MCP gives AI clients a standard way to access tools and services.
- WebMCP exposes tools from the webpage into the browser session.
These standards solve different layers of the same emerging problem. The distinction matters because “agentic commerce” is not likely to be one protocol or one product. It is increasingly becoming a stack of interoperable mechanisms connecting buyer intent to merchant capabilities while preserving the merchant's underlying systems and transaction logic.
The browser could become an agent runtime
There is a deeper implication for browsers themselves. The traditional browser is a renderer and interaction environment. It downloads a web application, presents it visually and mediates the user's clicks, typing, permissions and navigation. WebMCP gives the browser another role: broker between websites and AI agents.
OpenAI's built-in browser is already doing this. When a page provides compatible site tools, the browser can surface them to ChatGPT. The user asks for an outcome, ChatGPT identifies a relevant site tool, the website performs the structured action and the browser keeps the human in the experience. That potentially moves agentic computing closer to the user's active session because the agent does not necessarily need permanent server-side integration with every site the user visits. The website can advertise capabilities at runtime, when the user opens it.
This matters for businesses because distribution could change. Today, companies ask how to integrate their services into ChatGPT, Claude or other AI platforms. WebMCP introduces another question: What tools should our website expose to whatever authorised agent the customer brings with them? That is a much more open model.
The governance question moves to the action
Making websites easier for agents to operate also introduces obvious risks. Reading a product catalogue and deleting an account are not equivalent actions. Searching a knowledge base and publishing a document are not equivalent actions. The value of agent-native interfaces therefore depends on permissions, user awareness and sensible control over consequential operations.
OpenAI's implementation currently presents website-access prompts before ChatGPT uses site tools, while the tools themselves remain available only in the context of the page that provides them. This is likely to become an important design principle for WebMCP implementations. The question should not simply be whether an agent can execute an action. It should be whether the agent is authorised to do so, whether the action requires confirmation, whether the user can see what happened and whether the website can maintain its own business rules throughout the transaction.
Shopify's implementation demonstrates part of that model. WebMCP cart changes use the storefront's existing actions and affect the shopper's active session rather than creating a parallel commerce state controlled by the agent. The agent gains another interface to the business. It does not automatically gain the authority to bypass it.
WebMCP could become as important as the visible website
It is too early to treat WebMCP as established web infrastructure. OpenAI describes it as experimental. Shopify calls it a proposed web standard. ChatGPT site-tool support is currently tied to the desktop application's built-in browser, account and model availability, while Shopify notes that broader agent support remains limited to Chromium-based browser environments. Those qualifications matter.
But the direction is strategically significant. MCP has already established the idea that enterprise applications can expose capabilities directly to AI clients. WebMCP carries that logic into the web experience itself. If adoption continues, businesses may increasingly design digital experiences around two complementary interfaces: the visible experience through which people understand and evaluate the service, and a structured capability layer through which their agents can act.
For commerce, that could mean agents searching products, evaluating variants and constructing carts while users remain inside the merchant experience. For productivity applications, it could mean agents editing documents or performing analysis through site-provided tools. For almost any transactional website, it raises the possibility that the user's AI assistant becomes an active participant in the experience rather than an external observer trying to operate it from the outside.
That changes the strategic question for digital teams. It is no longer simply: Can an AI agent understand our website? Increasingly, it may become: What should our website allow an AI agent to do?
The next generation of the web may not replace interfaces with agents. It may give every useful interface an agent-readable layer underneath it.
