WebMCP Explained: Letting AI Agents Use Your Website, After Shopify's Checkout Launch

WebMCP is a proposed browser API that lets a web page tell an AI agent what it can do there: a set of tools, each with a name, a description, an input schema and a JavaScript function. Instead of an agent guessing which button to click from a screenshot, the page says "here is searchProducts, here is addToCart, here is what they need". The idea moved from proposal to production on 28 September 2026, when Shopify added WebMCP tools to checkout: an agent in the buyer's browser can now fill in a checkout and place the order once the buyer confirms. The spec is still a W3C Community Group draft, and only Chromium supports it, through an origin trial. Below: what WebMCP is, how it differs from MCP, what Shopify shipped, how a page registers a tool, and what a business should do now.

---

What WebMCP is, and how it differs from MCP

Both describe tools the same way: a name, a natural-language description for the model, and a JSON schema for the inputs. Everything else differs (W3C Community Group technical notes):

Put simply: MCP is how an assistant reaches your system from outside. WebMCP is how your website helps an agent that is already in the user's browser. A business with customers who use AI assistants may eventually want both.

What Shopify shipped

From Shopify's changelog, as reported by Search Engine Journal, eligible checkouts now register four tools:

• get_checkout reads the open checkout, and the order after purchase;
• update_checkout changes contact details, shipping or pickup, discount codes, payment and extra fields;
• complete_checkout places the order;
• navigate_to_storefront returns the tab to the store.

The safeguards are the interesting part, and a good template for anyone else:

• Agents cannot change the items in the order, and the tools don't accept new card details. An agent can only select a saved Shop Pay card or an approval already on file.
• Checkout validates every update itself.
• Payment challenges such as 3D Secure return control to the buyer.
• Shopify tells agent developers to show the buyer the order and total and get permission before complete_checkout. A signature or a ready-to-complete status doesn't count as consent.

Merchants don't configure anything. Standard checkouts get the tools only when the buyer pays with Shop Pay, and B2B, embedded and mobile SDK checkouts are excluded. Agent support is Chromium-only for now.

How a page registers a tool

The API is still moving, so treat this as the shape, not copy-paste code. In the version described in the W3C notes, a page registers tools on navigator.modelContext:

navigator.modelContext.registerTool({
  name: "searchProducts",
  description: "Search the catalog by keyword and maximum price.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" },
      maxPrice: { type: "number" }
    },
    required: ["query"]
  },
  annotations: { readOnlyHint: true },
  async execute(input, client) {
    const results = await searchAPI(input.query, input.maxPrice);
    return { products: results };
  }
});

There are also provideContext() to replace the whole set, unregisterTool(), and a client.requestUserInteraction() call inside execute that pauses to ask the user before a consequential action. Reports say Chrome is moving the API from navigator.modelContext to document.modelContext, so check the current Chrome documentation before you build.

Is it safe?

WebMCP inherits the browser's protections: tools are confined to their own origin, it requires HTTPS, and a tool can stop and ask the user. Two gaps remain, and the technical notes are frank about both:

• Any site can register tools on visit, with no permission prompt, unlike camera or location.
• There is no defence against prompt injection beyond origin boundaries. An agent reading a malicious page or review can still be steered.

So build each tool as if it were a public API endpoint, because in practice it is one:

1. Validate everything on the server. The browser tool is a convenience. The server decides what is allowed.
2. Ask before anything that costs money or changes data, and show the user exactly what will happen.
3. Keep tools narrow. addToCart(productId, quantity) is a tool. runQuery(sql) is an incident.
4. Mark read-only tools as read-only, and treat everything else as a write.

These are the same rules we apply to server-side MCP tools. Why, and the attacks behind them.

What a business should do now

• On Shopify: nothing to switch on. Check how your checkout settings decide when agents can complete orders, and watch for reporting on agent-placed orders.
• With your own web app or portal: pick the two or three actions customers repeat most, and prototype them as WebMCP tools behind a flag. Measure whether agent-driven sessions convert.
• For B2B software: WebMCP helps a user who is on your page. For assistants that work in your system without a browser, like Claude or ChatGPT doing a task for a user, you need an MCP server. That is the larger opportunity today, and the one the spec has already settled.

We build MCP servers for business software, and the same tool design (narrow, typed, read and write separated, the user's own permissions) carries straight over to WebMCP.

Related: how to build an MCP server, ChatGPT apps for business, AI agent security, and the Personal Agent Protocol, the sign-in standard for customers' agents.