All posts
Productivity

WebMCP Lets AI Agents Use Your Website

August 29, 2026 · 6 min read
WebMCP Lets AI Agents Use Your Website cover image

Your visitors bring an assistant. Chrome, Edge, and ChatGPT Desktop each run an agent inside the browser, and the agent acts for the user. WebMCP decides whether that agent calls the tools on your site or guesses at the interface.

What WebMCP is

WebMCP is a small JavaScript API. The Web Machine Learning Community Group at W3C develops it. A page registers tools with document.modelContext.registerTool. Each tool has a name, a description, input rules in JSON Schema, and a function that runs when the agent calls it:

document.modelContext.registerTool({
  name: "update_cart",
  description: "Set the quantity of a product in the visitor's cart.",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string" },
      quantity: { type: "integer" },
    },
    required: ["productId", "quantity"],
  },
  execute: async ({ productId, quantity }) => {
    return { cart: await setQuantity(productId, quantity) };
  },
});

The browser shows the registered tools to the agent after the user approves them. The agent picks a tool and fills in the arguments. The browser sends the call to your handler. The handler runs inside the page as the visitor, so the login of the visitor authorizes the call. The handler returns its result as JSON, and the model never sees a password or a token.

The proposal separates look tools from act tools. A look tool reads page state and returns the state as JSON. The state can be the contents of a cart or a list of available times. An act tool changes data. The agent reads page state with look tools. The agent changes data with act tools. The state that the agent sees therefore matches the page. A screenshot-driven agent does not get that guarantee.

MCP is the Model Context Protocol. It connects coding agents to services outside the browser. WebMCP uses the same tool model inside the browser tab. A page works as a small MCP server. The server exists only while the user is on the page, and it exposes only the tools that the page chooses. A desktop MCP server needs an installation, a token, and a running process. A WebMCP tool needs a visitor with a compatible browser.

What changed in 2026

The proposal moved from draft to trials and to live storefronts in 2026. This is the state in late August 2026:

  • A new entry point. Pages now register tools on document.modelContext. navigator.modelContext remains as a deprecated alias. A May 2026 spec change moved the registration point.
  • Chrome and Edge run origin trials. Chrome opened its trial in version 149 in June 2026. Edge followed with version 150. The Chrome team plans stable availability for version 157. A DevTools panel in Chrome shows tool errors. The Tool Inspector extension calls the tools on a page with sample arguments.
  • Mozilla is neutral. A Mozilla position statement from May 2026 accepts the tool API. Mozilla rejects the proposal for annotated forms and disputes the name. An implementation for Gecko is in progress.
  • WebKit opposes the API. The Apple position statement from May 2026 lists security and design concerns. Apple objected to the charter in June 2026. Safari does not support the API today.
  • Assistants outside the browser also read the tools. The implementation tracker lists ChatGPT Desktop. Brave tests the API in Leo.
  • Shopify turned it on by default. Shopify enabled WebMCP on its hosted storefronts in July 2026. The tool list now reaches millions of shops.
  • The specification added restrictions. A tools Permissions Policy limits the origins that may register. It arrived in August 2026. Cross-origin registration exists behind an open security review. A pattern with AbortSignal handles the removal of a tool.

E-commerce: the first use case at scale

The proposal authors show shopping in most demos. Shopping is also the first use case in production at scale.

A storefront with WebMCP exposes a small set of named tools. The Shopify rollout includes about ten. The tools search the catalog, read product details, read the cart, update the cart, open checkout, and manage orders and returns. The tools also answer questions about shop policies. An agent shops for a visitor in this order:

  1. It calls search_catalog with the description from the visitor.
  2. It reads the get_product results for price, size, and availability.
  3. It changes the cart with update_cart.
  4. It stops at proceed_to_checkout. The visitor pays.

Payment stays human. Merchants expose no tool for payment. Checkout opens the standard payment flow, and the visitor pays in it.

Some demo shops in the proposal register a checkout tool only while the cart contains a product. A confirmation modal appears before the order goes to payment. Order status and returns run through manage_orders. One request answers “where is my order”, and the visitor opens no form.

Merchants get two direct benefits. Agent traffic can finish a purchase. The agent answers common questions without a support ticket.

The same pattern for other tasks

Bookings work the same way. The clinic demo in the proposal exposes get-clinics, get-available-times, and schedule-appointment. On travel sites, the visible tools change with the page. A search page offers a search tool. The results page offers filter and list tools. The agent therefore sees options that match the screen.

A companion specification adds annotations to ordinary HTML forms. Agents can then fill and submit the forms without JavaScript. This covers tickets, appointment requests, and settings pages.

A dashboard page registers a tool for account data. The tool returns the data as JSON. The agent reads JSON, not pixels. A redesign does not change the result of the tool. An automated suite can rely on that stable output.

Why declared tools are more reliable

Agents without WebMCP drive the browser from screenshots and the accessibility tree. They pick selectors and click. They take a second screenshot to verify the result. A redesign or an A/B test can stop the task in the middle. Every step uses tokens.

With declared tools, the model does not explore. It picks from a list that your page wrote. The arguments have types. The page publishes the list again on each navigation, so the tools and the page state agree.

The research prototype behind the proposal called tools 1,890 times. Processing per call dropped by about 68%. Cost fell between 34% and 63%. Conventional automation succeeded on 98.8% of the tasks. The declared tools succeeded on 97.9%. The success rates matched, and the declared tools cost less.

The agent can call only the tools that you registered. The user approves each tool. You can switch off one tool. The other tools keep working.

WebMCP is opt-in. Sites without it are invisible to agents that call only declared tools. Automation without declared tools still exists. The tools that you register decide what an agent can do on your pages.

Security and open questions

The trust model protects the visitor. Handlers run inside the page sandbox. WebMCP gives the page JavaScript no new privileges. The agent sees tool names, descriptions, and results, and nothing else on the page. The session that authorizes you also authorizes the agent.

Open questions remain, and the community group tracks them in public:

  • Tools cannot identify the agent that calls them. A bank cannot favor one agent and limit another.
  • The specification defines a destructive flag. The flag is advisory. Each agent decides how to enforce it.
  • Tool descriptions and results are text for the model. An attacker can put instructions inside a description. A security review therefore covers the cross-origin registration feature from August 2026.

WebKit opposes the API. The result across browsers is progressive enhancement. Tools activate in Chrome and Edge, and later in Firefox. Safari visitors see the site with no change. You add a feature check, and browsers without the API ignore the tools.

How to add tools to your site

  1. List the tasks that visitors repeat. Pick the two or three most common.
  2. Write the look tools first. Return page state as JSON before you write anything that changes data.
  3. Guard each act tool. Ask for confirmation in the handler for actions that cost money or delete data.
  4. Register sensitive tools under conditions. Demo shops register checkout only when the cart contains a product.
  5. Test the tools by hand. The DevTools panel in Chrome shows registration errors. The Tool Inspector extension calls your tools with sample arguments.
  6. Validate with Tarsk. Point Tarsk at your staging site. Tarsk registers your tools, calls them, and checks each response against the declared schema.
  7. Add your first act tool after validation. Watch an agent finish the task once. Then add more tools.

Summary

  • WebMCP replaces agent guesses with named tools. Your page declares the tools, and agents call them.
  • E-commerce led the adoption. Shopify enables it by default, and Chrome and Edge run origin trials. Bookings, forms, and dashboards follow the same pattern.
  • The visitor stays in control. Handlers run in the page, the login session authorizes, and the visitor pays.

Start with a look tool on the page with the most traffic. The specification and the demos are at github.com/webmachinelearning/webmcp. The Chrome developer documents describe the origin trial. Validate the complete tool set with Tarsk before you deploy.