There is a familiar demo everywhere right now. An AI agent opens a browser, reads a page, clicks through a few menus, fills out a form, and finishes a task that would have taken a person five minutes.
It is impressive. It is also a brittle way to build software.
A web page was made for people. We pick up meaning from layout, labels, copy, colour, and years of learned habits. An agent working from screenshots, scraped DOM elements, and simulated clicks has to guess its way through the same experience, one uncertain move at a time. Move a button. Change a label. Run an A/B test. Add a modal. The agent is back to figuring it out.
That is why Model Context Protocol (MCP) matters. It is also why WebMCP may matter more than many teams expect.
MCP is not just another way to put a chatbot in a product. It is an integration contract for a world where software agents need controlled access to the data and actions that run a business. WebMCP brings that idea into the browser, where the customer, the agent, and the product experience are all in the same room.
The practical split: MCP connects agents to services and systems. WebMCP lets a web application state what can happen in the current interface, with structured inputs, structured outputs, and shared, visible context.
If you build ecommerce, customer platforms, internal operations software, or real-time systems, this is not a standards debate for some future quarter. Architecture is being set right now.
Agents are being asked to work through pixels
Most agent workflows begin with the same trade-off: hand the model a browser and teach it to act like a person. It looks at a page, finds an element, clicks it, waits, then does it again. That is useful. It lets an agent work on an existing site without a special integration.
But “works” is carrying a lot of weight.
A person checking out on a retail site knows that “Continue” might mean shipping details, payment details, a carrier offer, or final submission. They understand it from the page around it. An agent sees a possible next move. It might be right. It might also be thrown off by a promotion, a hidden field, an altered class name, or an ambiguous call to action.
The result is an expensive loop: more prompting, more retries, more exception handling, more monitoring. And still no strong assurance that the system has done what was intended. Everything can seem fine until a small front-end release breaks the path.
A clever browser automation layer is not the same thing as a durable integration model.
MCP makes business capabilities usable, not just visible
MCP is an open protocol that connects language-model applications with external data sources and tools. An AI application acts as a host, connects through a client, and reaches a server that can expose resources for context, prompts for reusable workflows, and tools for actions.[1]
That sounds technical, because it is. The business value is simpler: rather than teaching every AI product its own custom way to talk to your order system, product catalogue, analytics stack, CMS, support platform, or operations software, you expose the capability once through a standard interface.
The old question | The better question
Can the agent find the correct screen and click the right button? — Can it call a clearly defined capability with approved inputs?
Did the agent scrape enough page text to understand the customer? — Can it retrieve the permitted customer, order, inventory, or product context?
Will this automation survive the next interface redesign? — Is the business operation beneath it stable and versioned?
An MCP server can make an operation like get_inventory, create_return, quote_shipping, find_customer_order, or publish_campaign_draft available to an agent in a form it can reason about. The action has a name, a description, parameters, and a response. It is not trying to decide what an unlabeled icon was meant to do.
That is especially relevant in commerce. Agentic commerce will not be won by the model that clicks through the most screens. It will be won by businesses that can expose trustworthy product, pricing, availability, fulfilment, and service capabilities without handing broad, ungoverned access to a bot.
MCP brings another benefit that is easy to overlook. A tool is a promise. It makes a team decide what an action does, which data it needs, who can invoke it, what it returns, and when a human must approve. Those are useful decisions whether or not an AI agent ever calls the tool.
WebMCP handles the part APIs do not
An API or an MCP server can tell an agent that a product is in stock and add it to a cart. That alone does not solve the customer experience in front of it.
The customer may already be on a product configuration page. An assistant may be helping compare options in the browser. A complicated date picker, bundle builder, service-plan selector, or application flow may be on screen. The page has state and intent that a generic back-end action does not always carry.
WebMCP is a proposed browser-facing web standard that lets a site register JavaScript-based tools for AI agents. Those tools have natural-language descriptions and structured JSON Schema inputs. They are meant to be invoked in the very web interface where the user is working.[2]
Google’s Chrome documentation puts the improvement plainly: instead of asking an agent to inspect a button or field and infer its purpose, the site declares the purpose so it can be used correctly.[3]
A WebMCP-enabled site could expose a tool for:
Situation on the site | An agent-ready tool
A visitor needs the right product from a large catalogue —
filter_productsorcompare_productsA flight, appointment, or delivery interaction has tricky date rules —
select_available_timeA customer needs help in a layered support flow —
start_support_requestA configurable product has interdependent options —
configure_productA checkout needs a deliberate handoff —
request_purchase_confirmation
The names are not the point. The site owns the semantics. It can use its existing validation rules, pricing logic, accessibility work, state management, and customer-facing interface, rather than hoping an outside agent interprets the page properly.
MCP and WebMCP are not rivals
It is tempting to call WebMCP “MCP in the browser.” That is close enough to be handy, but loose enough to lead to messy architecture.
MCP is a protocol for application-to-service connectivity. It is often the right choice when an agent needs controlled access to systems behind the interface or needs to work across several of them. WebMCP is a browser API proposal. It lets a web application expose tools from client-side code and keeps the agent, user, and page in a shared interaction space.[1] [2]
Use MCP when… | Use WebMCP when…
The agent needs back-end data or business operations — The agent is acting inside an open web application
The task crosses CRM, ERP, PIM, OMS, support, or analytics systems — Current page state and visible user interaction matter
You need server-side authorization, audit trails, and lasting integrations — You need the site to express intent beyond what a DOM reveals
The task can happen without a particular page open — The customer and agent should see and shape the work together
The useful implementations will use both. A commerce assistant might use MCP to look up eligible offers, inventory, and order status. In the browser, WebMCP could let it apply an approved filter, set a configuration, update a visible cart, or ask for confirmation before a purchase.
That is better than giving an agent broad credentials on one side and a mouse on the other.
This is a trust and control question, too
“Agentic” is sometimes treated as a synonym for taking people out of the loop. In most commercial and customer journeys, that is a mistake.
The better goal is to remove mechanical work while keeping intent, approval, and accountability in view. MCP’s specification calls for explicit user consent around data access and tool invocation, along with clear authorization interfaces.[1] WebMCP is built around shared browser context and includes an example of requesting user interaction for sensitive actions such as a purchase.[3]
That is worth protecting. A customer should see what an assistant selected, understand the total, correct an error, and deliberately approve the final commitment. An operator should know whether an agent merely drafted a return, issued a refund, or changed fulfilment. A business should be able to limit the tools an agent sees, the actions it can take, and the moments that require escalation.
Neither standard creates trust by itself. Vague tool descriptions, loose permissions, and hidden side effects are still bad design. But both encourage a more honest kind of agency: offer narrowly scoped capabilities, make inputs and outcomes clear, and keep consequential actions under the right level of control.
The near-term opportunity is not “add AI”
WebMCP is still under active development. Chrome lists it as an origin-trial technology, and the W3C Community Group report is explicit that it is not a W3C Standard.[2] [3] No one should hang a critical customer flow on a draft browser API alone.
Still, this is the right time to pay attention.
The work that prepares a product for WebMCP pays off whether browser support settles in six months or two years. Clean service boundaries. Explicit actions. Stable schemas. Clear validation. Permissions. Observable outcomes. Interfaces that say what they mean. That is not speculative work. It is the basis of good software and dependable AI integration.
Start with one frustrating workflow. In commerce, it might be product discovery, compatibility guidance, returns, order changes, or post-purchase service. Decide what data an assistant needs. Decide what it may do. Make the side effects obvious. Put a confirmation step around the actions that carry real weight. Then work out which capabilities belong behind an MCP server and which should be available in the browser through a WebMCP-style interaction.
The web is moving beyond pages that agents merely look at. The question is whether your business can explain itself, safely and precisely, to the software that will increasingly act for a customer.