Yoav's blog thing

Mastodon   RSS   Twitter   GitHub  

Why WebMCP matters

AKA - WebMCP is Agentic WebPerf

For the last few months, I’ve been working (amongst other things) on getting Shopify’s storefront WebMCP tools ready for production and shipped. That’s now done, other folks have added Checkout support, and WebMCP seems to be getting traction: OpenAI added support in ChatGPT Desktop and ran the super-interesting WebMCP Challenge, Cloudflare supports it both in Kitesurf and for its customers, and my WebMCP presentation at the Agentic commerce W3C/GS1 workshop was really well-received.
As part of shipping WebMCP at Shopify, I’ve found myself more and more involved in the evolving standard proposal, filling the various gaps we found along the way.

But I wanted to write a bit about why I chose to work on those tools.

AI agents are a thing nowadays, and people are increasingly relying on them to get things done. These agents can execute local tools and code, and if we want the web to stay relevant, we need to enable agents to interact with it.

There are three types of agentic interaction with services on the web:

I believe that if we want the web to succeed in the agentic age, we need the co-browsing model to work and work really well for users. Co-browsing is the only model where the developer and the user maintain control over the experience, and the user can take over from the agent at any point. It’s the only model where the web remains the web.

At the same time, none of the early demos I’ve seen that relied on DOM- or screenshot-based interaction had a great UX. They seemed slow, exposed the user to the agent fumbling around the site, and provided suboptimal results.

# WebMCP to the rescue

WebMCP enables the site to provide agents with direct JS tools they can call to accomplish tasks, and as a result, makes direct interaction significantly faster, better and cheaper. That circumvents the slowness/awkwardness of an AI agent trying to figure out how to interact with the site as if it’s a human.

The site can register tools with explicit input and (soon) output schemas, as well as a clear description of what they do and when they should be called. The agent can then call these tools to achieve whatever the user asks it to do.

The idea is simple enough, but it’s a super powerful primitive that IMO would unlock significantly better co-browsing experiences.

In short, WebMCP is web performance for AI agents on the web.

The folks from nekuda.ai gathered data on that front, and found WebMCP to be 2.5-7.5x faster and up to 47x cheaper than other direct interaction methods. Shopify’s Checkout team ran a similar experiment and found WebMCP to be 2.7x faster and 58% cheaper, with 60/60 successful attempts vs. 56/60 with browser automation!

# Stuff to figure out

As simple as the basic idea of WebMCP is, there’s obviously a bunch of complexity to rein in: Who can register tools for the site? What kinds of agents do we want to support? How do we monitor the user experience? How can we get an explicit signal from the human user? How do we test all of this across a wide range of different browsers and agents? And how do we protect users from malicious tools?

We need answers to all of these questions, and we’re figuring them out one by one.
For example, when discussing who can register tools, we’ve landed on a Permissions Policy model to allow the site to decide which iframes can register tools. We also decided that tools should support in-browser agents, extension-based agents as well as in-page agents (potentially from a cross-site iframe).

Another big piece to figure out is the testing story. Web developers can currently evaluate their WebMCP implementations against vanilla models, e.g. using the webmcp-evals framework. But there’s no way to run their evals against real, representative agents that also include the harness, the system prompt and the various security verifications that agents employ.

# Can’t we just build better websites?

I heard people ask whether allowing agents to navigate your site isn’t simply a crutch for bad UX design. One example I heard - won’t a better product search with more precise criteria help users find the product they are looking for without scrolling through 87 slightly different ones?

Well, at least in my experience some of it is true, as many merchant sites don’t allow users to filter their search by every characteristic they might care about. So if you’re looking for something very specific (trail running shoes with a drop of up to 5mm, lightweight 175-177cm skis with 80-85mm underfoot, etc.), unless you have an AI agent to help you, you end up scrolling through products, looking at the detailed specs of each one and hoping that the info is actually there. Not a great outcome. AI agents really change the picture there.

But I don’t think that’s all there is to it. If I’m looking at e.g. home improvement projects, I can typically buy the materials and tools I need online, but going to a physical store and talking to an experienced person is super helpful to get a holistic view of all the details of the project, what you’d need to tackle each one and where you can get it.
Agents can similarly help brainstorm a project, work out its details, and figure out what you'd need to get it done.

WebMCP lets online stores offer the equivalent of an experienced salesperson that helps customers plan their project and find everything they need to get it done.
And while they can also do that by shipping an agent themselves, that’s significantly more complex. And at least some users prefer to have their familiar agent do that, rather than rely on someone else’s agent.

With WebMCP, merchants can rely on the user’s agent to integrate with their site and drive it, without having to provide the smarts themselves.

# Can’t we just rely on HTML semantics?

A recurring question, in the ongoing W3C TAG review and at the heart of WebKit’s opposition, is around the use of JS tools instead of HTML semantics. There’s concern that content on the web would fragment into “human content” and “agent content”. WebKit considers AI agents to be “assistive technology” and hence expects them to be invisible to the site, and cites risks of abuse.

That concern is understandable, and I think it can be split into two different risks.

# Discrimination

Since WebMCP tool calls reveal that an agent is involved, sites could now discriminate against agentic users.

But developers can already discriminate against agentic users, with or without WebMCP, through their regular bot detection mechanisms. If this is their goal, WebMCP won’t help them.

My discrimination concerns lie elsewhere. I’m concerned that without an explicit “agentic experience” signal, developers will wrongfully categorize such users as “bots”, due to the non-human interaction patterns. That can get agentic users blocked or relegated to sub-optimal experiences.

So I disagree with WebKit folks there, and think that having a way for the server to know there’s a human or a trusted agent involved is critical. I’m hoping Web Bot Auth can help us solve that part of the equation.

# Semantic divergence

The other risk is semantic divergence, where different capabilities would be presented to non-agentic users vs. agentic ones. But developers can already create these kinds of semantic divergence between different types of users. There are similar risks already for JS support in general, as well as for ARIA semantics.

And while there are certainly cases when users without JavaScript or assistive-technology users get sub-par experiences, I believe those come from neglect, not from explicit discrimination against such users.
Developers and site owners are not incentivized to present completely different sites to users with or without JS, nor to provide different semantics to assistive-technology users.

The same holds true for agentic users. Developers are incentivized to provide them with the best agentic experience, but not one that’s entirely semantically different from what non-agentic users get. The agent may help these users to avoid jumping through certain hoops, but at the end of the day, all users will reach the same destination.

# Declarative WebMCP is not enough

The semantic divergence concern can be addressed by the Declarative WebMCP proposal that would reuse and augment form semantics to enable agents to perform various operations. That can be great, but I would argue it is complementing imperative tools, rather than replacing them.

Relying solely on HTML semantics for agentic interactions (and discarding an imperative solution) would be akin to saying that we don’t need JavaScript, as we can just bake any functionality developers need into HTML.

Declarative WebMCP can work well for “one-shot action” tool calls. But that doesn’t represent all potential tool calls.

Some tools aim to be a single step in a multi-step task (e.g. to scan through multiple products and take the user to the best fit) or to provide further context to the agent (e.g. an answer to an FAQ). The information returned from those tools is aimed for consumption by the agent, which will either answer the user’s question, or call more tools with that information as input. The user-visible outcome of that journey would be either in their interactions with the agent, or in a destination page/UI they asked the agent for.

And while one can imagine developers rearchitecting their sites such that each action would match a form on the page, that’s likely to be a worse user experience in many cases.
That would force agents to navigate these forms while presenting intermediate results to the user, before they are done accomplishing what they were tasked with.

In many agentic use cases, the user wants the outcome, but doesn’t necessarily want to be exposed to the journey.

If I’m looking for lightweight skis 85mm underfoot, I don’t want to see the agent go through all the potential candidates while skimming their specifications. I just want it to bring me the end results of that search, so I can make a decision on the relevant product.

The same applies to many other user journeys across the web.

# To summarize

I want the web to win and continue to thrive as the world’s most far-reaching computing platform. For that to happen in the agentic age, co-browsing must win. I believe WebMCP is extremely aligned with that goal, and therefore I’m putting my energy behind it and doing whatever I can to make it successful.

Thanks to François Beaufort for reviewing an early draft of this post.

← Home