Let AI agents use your website properly with WebMCP

What's co-browsing?

Co-browsing is a new way of working in which the agent works alongside the human in the same browser session. The agent acts on the user's instructions, and the user can watch, approve steps, and take over when necessary. For example, on a grocery e-commerce site, the user can ask the agent to add products to the basket based on a shopping list, and then manually log in, review the basket, make adjustments, and proceed with checkout. If you want to try this today, you can install the ChatGPT desktop app, switch to the Codex tab, and prompt the agent to open your favourite site and perform some tasks. The Claude desktop app has a similar built-in browser.

Agents today access and act on the site through a combination of screenshots and a text outline of the page. The text outline uses the browser's accessibility features, which are also used by screen readers. This means that the effort put into making a site accessible also directly helps agents use the site. In the EU, accessibility has also been a legal requirement for most e-commerce sites since June 2025 under the European Accessibility Act. For some use cases, this might be good enough, but it's still relatively slow, as well as expensive, because the agent requires a lot of tokens to read and act on the site.

What's WebMCP?

WebMCP is a proposed browser standard that aims to solve this, drafted by engineers at Google and Microsoft. Using WebMCP, a website can offer tools to AI agents, like "search products" and "add to cart". This is conceptually similar to MCP but occurs in the browser, within the user's own session, rather than through a separate API. Tools can be read-only or perform actions that may require user confirmation. Browsers without support can simply skip WebMCP.

So, where does WebMCP pay off the most? For finding public information, other methods like well-structured semantic HTML, JSON-LD structured data, sitemaps, and product feeds already do most of the job well. Agents can also use search engines to look up content on your site. WebMCP can still provide more token-efficient structured data here, but the benefit may be modest. It becomes much greater for features where the agent acts on the user's behalf, e.g. manipulating a shopping cart or selecting a delivery option.

So what's the catch?

As of October 2026, ChatGPT desktop is the only production client that supports WebMCP in the EU, so the current user pool is limited. This might well change within a year. Google is currently running an origin trial that lets you register your domain to temporarily enable WebMCP in Chrome. The issue here is that there is no co-browsing product in Chrome that uses WebMCP yet. The Claude in Chrome extension could in principle call the tools on nitor.com, but when I tested it, it read and clicked through the page instead. Google has Gemini in Chrome, but it's not available in the EU, most likely for regulatory reasons. It launched in the UK in July, but there is no timeline for the EU. Microsoft is running its own origin trial in Edge, but has not announced WebMCP support in Copilot. Firefox has been neutral towards WebMCP, while Safari has been actively opposed, arguing that agents are essentially assistive technology and should use standard HTML and ARIA instead of a parallel set of tools.

Whether WebMCP catches on in the future is therefore still uncertain. Google's current estimate is to ship WebMCP by default in Chrome 157 in November, while WebKit has suggested starting over in a new W3C group. Personally, I think it's reasonably likely that Gemini in Chrome will be available in the EU with WebMCP support within a year or so. That alone would be enough, as Chrome has around 60% of the browser market share in Finland at the moment. Edge might also follow relatively quickly, as Microsoft is already testing WebMCP. Even if Firefox and Safari never support WebMCP, it can still be implemented as a progressive enhancement in browsers that do. Claude could also follow ChatGPT and add WebMCP support to its built-in browser.

How does WebMCP relate to the broader tech landscape?

MCP is similar in that it also provides tools for agents, but they are exposed on a server. This has the benefit that the service can be used from anywhere, such as directly within an AI chat tool. The drawback is that login is handled separately, often via OAuth, rather than reusing the browser session. The user also loses the ability to follow what happens visually on the site or take manual actions. This can be partly solved using MCP Apps, which lets you embed a custom user interface in a chat tool.

Another natural comparison is to agentic commerce protocols, of which Google's UCP currently appears to be the most realistic option in the EU. It's specific to e-commerce and handles the full shopping process inside AI tools, including checkout and payment. Nordic payment providers like Klarna and Vipps MobilePay are already working on UCP support. The hard part is checkout without the user present, as online payments in the EU generally require strong customer authentication under PSD2, with no special rules for agents.

A potential issue with both MCP and the agentic commerce protocols is that the business gives up some control of the user journey and data, as the user is no longer directly exposed to the brand, advertising, and possibly personalisation of an e-commerce site. WebMCP provides a more conservative approach to supporting agentic commerce, which many businesses might prefer. The options are not exclusive either: you can support both MCP and WebMCP and possibly even reuse many of the tools. Shopify does both: since August, it has enabled WebMCP tools for product search, the cart, and checkout, alongside separate MCP servers for agents outside the browser.

What does this look like in practice?

This section is for the developers reading this, or anyone interested in the details. To allow you to test WebMCP, we have implemented a search_content tool on nitor.com and registered for the origin trial. If you are using Chrome versions 149–156, you can open the developer console and perform a search, for example:

const tools = await document.modelContext.getTools();
const search = tools.find((t) => t.name === "search_content");
const input = JSON.stringify({ query: "developer survey" });
await document.modelContext.executeTool(search, input);

This returns a structured response of all "developer survey" articles on the site. You can also open nitor.com in the ChatGPT desktop app (see the requirements) and ask it to search for content like "open positions for senior developers"; it should use WebMCP instead of searching the site manually. Note, though, that if you don't open nitor.com first or explicitly instruct the agent to do so, it might just use a search engine instead. Content search is not the best use case for WebMCP, but it provides a simple proof of concept.

So, how do you implement WebMCP? The main API is document.modelContext. Here's a simplified example of our content search:

if (document.modelContext) {
  document.modelContext.registerTool({
    name: "search_content",
    description: "Search articles, case studies and job listings on nitor.com.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Words to search for" },
      },
      required: ["query"],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ query }) => {
      const url = `/api/content?query=${encodeURIComponent(query)}`;
      const response = await fetch(url);
      return response.json();
    },
  });
}

Each tool definition has a name, description, input schema in JSON Schema format (which can be generated, e.g. using Zod), annotations like readOnlyHint (which is not trusted blindly by agents), and a function to execute the tool that can make an API request or call any other JavaScript code on your site. It's important to provide readable errors so that the agent can self-correct if something goes wrong. It's also useful to log tool calls. As with any API, treat tool input as untrusted.

For manual testing, you can open the site in ChatGPT desktop and ask it to find and test any available WebMCP tools. It's also worth asking the agent what it thinks of the tools. When we did this, it gave a precise critique of our first version, which mirrored the site's paginated "load more" listing and forced the agent to make dozens of calls to find all matching articles. Tools should be designed for how agents work, not copied from the UI.

Conclusion

Agentic co-browsing is still in its early days, but it's coming, so it's best to prepare for it. My recommendation is to start with the fundamentals: semantic HTML and accessibility, JSON-LD structured data, sitemaps, and product feeds. Then pick a couple of key tasks users perform on your site and implement WebMCP support for them, to get to know the technology. Based on those experiences, you can then consider expanding WebMCP support. Keep a close eye on the Gemini in Chrome launch in the EU. If you want your service to be usable directly inside AI chat tools, consider also supporting MCP and UCP. And talk to Nitor if you want help in making your service agent-ready.