Most websites were designed with a simple assumption: a person would arrive, read the page, navigate the interface, complete a form, and click the appropriate button.
AI agents are beginning to challenge that assumption.
An agent may visit a website on behalf of a user, interpret the interface, collect information, complete several steps, and attempt to reach an outcome. It could help someone book a complicated trip, submit an application, configure a product, troubleshoot a problem, or complete a purchase.
Today, agents often perform this work by interpreting the same interface created for people. They examine text, buttons, forms, and page structure, then try to determine what each element means.
That approach can work, but it is inherently fragile.
A person may understand that “Continue” advances an application while “Save” preserves progress. An agent has to infer that meaning from the interface and surrounding context. A minor design change, ambiguous label, hidden validation rule, or unexpected page state can cause the workflow to fail.
WebMCP proposes a different approach.
Instead of requiring an agent to guess how a website works, the website can describe its capabilities in a structured form that an agent can understand and use.
The website is becoming an agent-facing product surface.
That may sound like a technical improvement. For product leaders, it represents something larger.
Why WebMCP is receiving attention now
WebMCP is an experimental open standard that allows websites to expose structured tools to AI agents.
Google describes it as a way for websites to declare the purpose of page features instead of requiring agents to interpret every button, field, and interaction. A website might expose tools such as filter_results, submit_application, run_diagnostics, or checkout, along with clear definitions of the information those tools require.
The tools still operate within the website. The experience can remain visible to the user, and sensitive actions can require confirmation.
The Chrome WebMCP documentation currently describes support for tool discovery, structured input and output definitions, and awareness of the page’s current state. Chrome is also making WebMCP available through an origin trial while the proposal continues to evolve.
OpenAI has added momentum through its WebMCP Challenge, which asks developers to explore what becomes possible when people and their agents can use web applications together.
The challenge itself is not the important story. The stronger signal is the participation surrounding it. OpenAI, Google Chrome, Shopify, Cloudflare, Vercel, Netlify, and other web infrastructure companies are exploring a future in which agents become legitimate users of web products.
WebMCP is still experimental and may change significantly. Product leaders should not treat it as a mature standard that every roadmap must immediately support.
They should, however, pay attention to the product direction it represents.
The current web forces agents to imitate people
Most browser agents interact with websites through a process sometimes called actuation.
The agent looks at the page, identifies what appears to be interactive, and simulates the actions a person would perform. It clicks buttons, enters text, opens menus, selects options, and waits for the page to respond.
This is impressive when it works.
It is also an indirect way for software to interact with software.
Imagine asking an agent to change a configuration in an enterprise application. The agent may need to:
- Find the correct navigation area.
- Identify the relevant account or environment.
- open a settings page.
- Locate the appropriate configuration.
- Interpret the current value.
- Enter the new value.
- Understand any validation messages.
- Submit the change.
- Confirm that the operation succeeded.
Every step creates another opportunity for misunderstanding.
The agent might click the wrong control. It might confuse a display name with an identifier. It might miss a warning that appears elsewhere on the page. It may believe an action succeeded even though the product rejected the change.
WebMCP allows the site to expose the underlying intent more directly.
Instead of navigating through eight interface steps, the agent could discover a clearly defined capability such as update_configuration. The tool could specify the required inputs, validate the request, present the proposed change to the user, and return a structured result.
The agent is no longer trying to reverse-engineer the interface. The product is explicitly explaining how it can be used.
WebMCP does not make the user interface irrelevant
Whenever agents become more capable, it is tempting to predict that conventional interfaces will disappear.
I do not think that is the most useful conclusion.
WebMCP is primarily designed around browser experiences with a person involved. Its tools execute within the context of the website, and their activity can remain visible to the user.
That creates an opportunity for a shared experience.
The agent may handle navigation, data entry, coordination, and routine steps. The interface can help the person understand what the agent found, what it intends to do, and what requires a decision.
Consider a complex business application.
An agent might gather the relevant configuration, run diagnostics, and prepare a recommended change. The interface could then show:
- What problem was detected
- Which information the agent examined
- What change it recommends
- Who or what will be affected
- Whether the change can be reversed
- Which approval is required
The interface is no longer responsible only for helping a person operate the software manually. It becomes a place where people supervise, understand, and collaborate with software acting on their behalf.
Agents do not eliminate the need for good product experience. They change what the experience must communicate.
This is closely related to the role of AG-UI, the open protocol focused on communication between agent backends and user-facing applications. The AG-UI project addresses real-time agent activity, shared state, structured messages, and human involvement inside an application.
The two ideas operate at different boundaries, but they point in the same direction. AI products need better ways to connect agents, applications, and people without turning every interaction into an improvised chat experience.
WebMCP and MCP solve different problems
The similar names can create confusion.
The Model Context Protocol, or MCP, gives AI applications a standard way to connect with external tools, data, and services. An MCP server may expose business capabilities that several AI clients can use, whether or not a browser is involved.
WebMCP focuses on capabilities exposed by a website within the browser experience.
A simple way to think about the difference is:
- MCP connects an agent with services and systems.
- WebMCP helps an agent use capabilities available through the active website.
They can also complement each other.
An enterprise application might use MCP to make approved services available to several AI applications. It could use WebMCP to help an agent work reliably within the customer’s current browser session and page context.
Neither replaces the product’s existing APIs, user interface, authentication, or business logic.
The important product decision is not which acronym the company should support. It is deciding where the customer’s agent should interact with the product, which capabilities it should receive, and how those interactions remain safe and understandable.
Websites will need to declare what they are for
Websites already contain a great deal of information about what users can do. The problem is that much of this meaning is embedded in visual design, page structure, labels, and JavaScript behavior.
People interpret those signals naturally. Agents do so imperfectly.
WebMCP introduces the idea that a product should describe important capabilities explicitly.
That creates a product-design responsibility.
A team still needs to decide:
- Which customer outcomes should be available as tools?
- How broad should each tool be?
- Which information should the tool require?
- What should happen when information is missing?
- Which errors should the agent be able to recover from?
- Which actions require the user’s confirmation?
- What should the person see while the tool is operating?
These decisions should not be made by automatically converting every button into a tool.
A product with hundreds of controls does not necessarily need hundreds of agent-facing capabilities. Exposing everything may create ambiguity, increase risk, and require the agent to reconstruct the same workflow the product team should have designed.
Good tools should reflect meaningful customer intent.
A travel site could expose separate tools for searching flights, selecting a fare, adding a passenger, and purchasing a ticket. It could also expose a higher-level tool that helps prepare a complete multi-city itinerary while requiring approval before any purchase.
The appropriate design depends on the customer, the task, and the consequences of an error.
A WebMCP implementation should describe the customer’s work, not reproduce the website’s internal structure.
Product discovery will need to include agent journeys
Most product teams conduct research by observing what customers do inside an interface.
They look for confusing navigation, repeated data entry, incomplete tasks, slow workflows, and moments where customers need documentation or support.
Agent-enabled experiences introduce another useful perspective.
Where would a customer benefit from delegating part of the journey? Which steps are mechanical? Which require interpretation? Where must the customer remain responsible for the final decision?
For example, imagine a customer applying for a financial product.
The agent might already know the customer’s approved personal information. It could help map that information into the correct fields, identify missing documents, explain unfamiliar requirements, and prepare the application.
The customer should still be able to review what was entered and confirm the submission.
The product opportunity is not simply to make the existing form easier for an agent to complete. The team should reconsider the complete journey.
Does the customer need to see every field if most information can be prepared safely? Which disclosures must remain prominent? When should the agent pause? How can the customer correct one part of the application without restarting the entire process?
Those are product and experience questions, not protocol questions.
Trust becomes part of task completion
A successful agent interaction is not only one that reaches the intended result.
The customer must also understand what happened.
This becomes especially important when the workflow involves personal information, money, access, business configuration, or communication with other people.
Before allowing an agent to act, the product may need to answer several questions:
- Whose authority is the agent using?
- What information can it access?
- Is access limited to the current task?
- Which actions can it take automatically?
- Which actions require confirmation?
- How will the user review the proposed change?
- What will appear in the audit history?
- Can the action be undone?
WebMCP includes browser security mechanisms such as origin isolation and permissions policies. Those controls are important, but they do not define the complete trust model for a product.
The product still owns authorization, confirmation, auditing, recovery, and communication.
A tool named delete_account can be accurately described and technically secure while still producing a terrible product experience if an agent can call it without sufficient context and approval.
This is the same lesson product teams are learning from MCP.
A protocol can provide structured access. It cannot decide whether granting that access creates a trustworthy product.
Agent readiness may expose existing product weaknesses
One of the more useful side effects of designing for agents is that it forces teams to make product intent explicit.
If the team cannot clearly describe what an action does, when it should be used, what information it requires, and how success is confirmed, customers may already be struggling with the same ambiguity.
An agent-ready review could reveal:
- Similar actions with inconsistent names
- Workflows spread across unnecessary screens
- Important rules that exist only in documentation
- Validation that occurs too late
- Actions that provide no clear success state
- Authorization decisions that are difficult to explain
- Product behavior that depends on undocumented assumptions
These are not exclusively AI problems.
Making a product understandable to agents may also make it easier to test, document, integrate, support, and use.
This does not mean products should be redesigned for machines at the expense of people. It means clear product semantics benefit both.
Where product teams should begin
WebMCP is too early for most companies to justify a broad implementation program.
A focused experiment is more appropriate.
I would begin with one important but contained customer workflow. It should involve enough complexity that agent assistance creates visible value, but it should not carry irreversible consequences.
Strong candidates might include:
- Completing a complex support request
- Configuring filters across a large dataset
- Preparing an application for review
- Running diagnostics and explaining the results
- Gathering information needed for an administrative task
- Creating a draft configuration without activating it
The team should then compare the current human journey with the potential agent-assisted journey.
Where does the customer spend time navigating rather than deciding? Which information could the product expose more clearly? What should the agent prepare? When should it return control to the user?
The experiment should also test failure, not only the ideal demonstration.
What happens when required information is missing? What if the tool returns an unexpected result? Can the agent explain the problem? Can the user recover without losing progress? Does the product prevent the agent from exceeding its intended authority?
Those scenarios will reveal more about product readiness than a polished demo in which everything works perfectly.
Measure outcomes, not tool calls
A WebMCP implementation should not be considered successful simply because an agent discovered and invoked a tool.
The customer still has an outcome to achieve.
Useful measures may include:
- Successful task-completion rate
- Time required to complete the workflow
- Number of manual corrections
- Frequency of inappropriate tool selection
- Confirmation acceptance and rejection rates
- Recovery rate after a failed action
- Customer understanding of what the agent did
- Support volume related to the workflow
- Percentage of customers willing to use the agent again
The team should also compare the agent-assisted journey with the existing experience.
If WebMCP makes a task technically possible but slower, less understandable, or less trustworthy, the product has not improved.
WebMCP is early, but the product shift is already visible
WebMCP is under active development. Browser support is limited, APIs may change, and customers are only beginning to understand where they want agents involved.
It would be premature to treat it as a universal requirement.
It would also be a mistake to dismiss it as another temporary protocol discussion.
The durable change is that software will increasingly interact with web products on behalf of people. Websites designed only for manual navigation may become difficult for agents to use reliably. Products that describe their capabilities clearly may be easier to include in agent-assisted workflows.
This creates a new form of product accessibility.
A customer may begin a task inside an AI assistant, arrive at a website with an agent, collaborate with that agent inside the application, and return to the assistant after the task is complete.
The product may no longer control the beginning or end of the journey.
Its value will depend partly on how well its capabilities can participate in a workflow that extends beyond its own interface.
The question product leaders should ask
The immediate question is not, “Does our website need WebMCP?”
A better question is:
If a trusted agent arrived with our customer tomorrow, what could it help them accomplish safely?
That question leads to customer workflows, product capabilities, authorization, interface design, and business value.
It also forces the team to decide what should remain manual, what can be prepared by an agent, and what the product should make easier for both.
The web was originally created for people to find and consume information. It evolved into a platform where people could operate applications and complete complex transactions.
Agents may represent its next important transition.
Products will still need interfaces for people. They will still need APIs for developers and integrations. But they may also need a structured way to explain what they can do to software acting with a customer’s permission.
WebMCP is one early proposal for creating that connection.
Its long-term significance will not be determined by how many websites register tools. It will be determined by whether those tools help people reach meaningful outcomes with less effort and without losing control.
That is the product opportunity worth watching.