WebMCP providing understandable actions to agents in Optimizely

WebMCP is coming to Optimizely: a strategic view for CMS and Commerce teams

At Opticon 2026 in New York, Alex Atzberger framed Optimizely's strategy around three experiences: the marketer experience, the customer experience, and the agent experience. The first two are familiar territory. The third is the one that changes how we plan a site, and WebMCP is the most concrete piece of it.

The premise is simple. Your site now has two audiences. Humans arrive through search, ads and email, and interact with the interface you designed for them. AI agents arrive on a customer's behalf, running in that customer's browser, and try to complete the same tasks through the same interface. Today they do that badly. They read the screen, guess which button does what, and break the moment a designer moves something. The result is a slow, unreliable experience that the brand has no control over and no visibility into.

WebMCP is the proposed fix, and the shift it represents is worth understanding before the implementation detail arrives.

And what's more it was announced that WebMCP support will be coming automatically to the platform, so similar to how we can help fix AEO and GEO issues, agents and the DXP platform will give you features to be able to add this to your website!

What WebMCP?

Instead of leaving an agent to work out what your interface does, the site tells it.

A page can publish a short, structured list of the actions it supports: search the catalogue, choose a size, book an appointment, request a brochure, check an order, start a return. Each action has a name, a description, and a defined set of inputs. The agent picks from that menu rather than guessing, and the action runs in the customer's own browser window, visibly, so the person can see what is happening and step in.

That last part matters commercially. The action executes inside your site, in your session, under your rules. Your brand, your pricing logic, your validation and your design decisions all stay intact. This is the opposite of the alternative future, where agents scrape your content, complete tasks in an interface you do not own, and reduce your brand to a data source.

WebMCP is a proposed web standard being incubated at the W3C, led largely by engineers from Google and Microsoft. It is the browser-side counterpart to the server-side integrations many teams have already started building. Optimizely shipped a server-side MCP server for Experimentation earlier in 2026, which lets an agent work with your experimentation programme on behalf of an authorised user. WebMCP addresses the other side of the equation: not your team's tools, but your customers' journeys on your live site.

Where the standard actually is

Set expectations carefully, because this is early.

Chrome and Edge both have developer trials running. Brave and ChatGPT's desktop app have shipped early support. Firefox and Apple are engaged in the standards process but have not committed to implementing it, and the specification is still changing. Nobody should be building a business case on WebMCP delivering measurable revenue this quarter.

What it does justify is a place on the roadmap and a set of preparatory decisions, most of which have value whether or not the standard lands as expected. That is the useful framing for a client conversation: this is not a bet on one specification, it is groundwork for agent-mediated traffic that is already arriving. Optimizely reported agent-related traffic growing around 6% month over month in its own data.

What Optimizely showed, and what is still unclear

Optimizely previewed WebMCP as part of the agent experience story at Opticon 2026, alongside agent-facing measurement: AI citations, brand mentions, share of voice, and which pages are receiving machine rather than human requests. The stated direction is that these capabilities become part of the platform rather than a per-project custom build.

What has not been published in detail, at the time of writing, is the shape of that delivery: which products get it first, whether it surfaces through Forms and Visual Builder or through developer tooling, and on what timeline. If you are planning around specifics, get them from your Optimizely contact rather than from conference coverage, including this article.

Where this is useful on a content site

The strategic question is not "how do we support agents". It is "which actions on our site are worth an agent completing reliably". That list is usually shorter and more obvious than people expect.

On a content-led site, the strongest candidates are the interactions that already have a clear structure and a clear business value attached:

• Enquiry and lead capture. Brochure requests, contact forms, event registration, quote requests. These are the highest-intent actions on most sites and the ones most damaged by friction.
• Booking and appointments. Complex date and time selection is exactly where agents struggle and where drop-off is highest for humans too.
• Search and filtered discovery. A faceted listing is a set of choices you have expressed as an interface. The underlying capability is easy for an agent to use well.
• Multi-step journeys. Applications, eligibility checks, configurators. Anywhere a visitor currently works through several screens to reach an answer.
• Account self-service. Change a detail, download a document, check a status.

Quinnipiac University, which runs around 17 sites on Optimizely, pointed at precisely this class of task at Opticon: booking a campus visit, requesting information. Nothing exotic. Just the things people came to the site to do.

There is a second-order effect worth raising with content teams. Nazanin Ramezani made the point at Opticon that as generating channel variations gets easier, managing the source content repository becomes the harder part of the job. The same logic applies to actions. If your taxonomy is thin and your product data is inconsistent, the descriptions of your actions will be vague, and vague descriptions get used incorrectly or ignored. Content and data quality stop being a hygiene issue and become a performance issue.

Where this is useful on a B2C storefront such as Customized Commerce

For consumer commerce on Customized Commerce, the value concentrates in three places.

Getting the right product into the basket. Consumer catalogues are option-heavy, and the valid combinations are messy. The navy is out of stock in a 12; the longer leg length only comes in three colours. An agent reading two dependent dropdowns will get this wrong some of the time, and it will get it wrong quietly, putting the wrong item into a basket the shopper then buys. Your product data already holds the correct answer. Letting the site resolve an option request, rather than letting an agent infer it, turns the most likely failure into a point of difference. On a fashion, homeware or consumer electronics site, this is the single most valuable action to get right.

Repeat and low-consideration purchases. Reordering consumables, refilling a subscription, adding to a wishlist, registering interest in an out-of-stock line. These are the journeys where the customer has no interest whatsoever in your interface and every interest in the outcome. They are also, conveniently, low risk.

Post-purchase self-service. Order tracking, delivery changes, returns and exchanges. High volume, low margin for error, and a direct line to both customer service cost and repeat purchase rate.

Running these actions inside the shopper's own session is what makes them viable. The session already knows the market and currency, the signed-in customer, the delivery preferences, the current basket and the promotions applied to it. An external integration has to reconstruct all of that before it can answer a question as ordinary as "what does this cost me, delivered, by Friday?". Keeping the action on your site means it simply answers.

Where to start

Three things are worth doing in the next quarter, none of which depend on the specification settling.

1. Inventory your actions. List the things customers actually come to your site to do, and rank them by business value. If an action cannot be described clearly and briefly, that tells you something about the journey rather than about WebMCP.
2. Audit the data underneath the top three. Product options, availability, taxonomy, form routing. This is the work that determines whether agent-assisted journeys succeed, and it improves the human experience in the meantime.
3. Decide how you will recognise agent traffic. Before it grows large enough to distort your reporting and your testing programme.

The technology here will not be the hard part. The hard part is the same thing every Opticon takeaway eventually circles back to: knowing which actions matter, having data structured well enough to describe them, and having governance robust enough to let something other than a human trigger them. None of that is blocked on a specification reaching maturity. It can start now.

When we have more information about the specifics of the Optimizely implementation, I'll provide another article. Until then, I wanted this article to highlight where Optimizely is going around the agent experience and the new WebMCP technology.