WebMCP: Make Your Website Ready for Browser AI Agents

For years, AI agents have interacted with websites the hard way: by reading the rendered page, guessing where the buttons are, and clicking through the DOM like a confused human. It is slow, brittle, and breaks the moment you ship a redesign. At Google I/O 2026 on May 19, Google and Microsoft proposed a fix that flips the model on its head: instead of agents scraping your site, your site tells the agent exactly what it can do.

That proposal is WebMCP — the Web Model Context Protocol — and it could become as fundamental to the agentic web as the <form> element was to the interactive web.

What Is WebMCP?

WebMCP is a proposed open web standard that lets a website expose structured tools — JavaScript functions and HTML forms — directly to browser-based AI agents. Instead of an agent reverse-engineering your UI, your page publishes a machine-readable menu of actions: "add to cart," "search orders," "book a table," each with a name, a description, and a JSON schema for its inputs.

It is being developed through the W3C Web Machine Learning Community Group, with Google and Microsoft co-authoring the specification. An early preview landed in Chrome 146 in February 2026, and a Chrome 149 origin trial is now open to registered developers. Microsoft's involvement signals Edge support, while Safari and Firefox are expected to evaluate the proposal.

If you have followed the rise of the Model Context Protocol (MCP), think of WebMCP as MCP's browser-native sibling.

How It Differs From Server MCP

Standard MCP connects agents to backend servers over JSON-RPC, usually running outside the browser. WebMCP keeps everything inside the browser tab. That single architectural difference solves some of the thorniest problems in agent automation:

Because tools execute in the page itself, they share whatever session the user already has. There is no second login, no API key to provision, no parallel permission system. If a user is signed in, the agent acts within that same session — and only within it.

The Core API: navigator.modelContext

WebMCP extends the browser with a ModelContext interface, available only on secure (HTTPS) pages. The primary method registers a tool with the browser so any visiting agent can discover and call it.

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the shopping cart by ID and quantity.",
  inputSchema: {
    type: "object",
    properties: {
      product_id: { type: "string" },
      quantity: { type: "number" }
    },
    required: ["product_id", "quantity"]
  },
  async execute({ product_id, quantity }) {
    await cart.addItem(product_id, quantity);
    return {
      content: [
        { type: "text", text: `Added ${quantity} of ${product_id}.` }
      ]
    };
  }
});

Each tool has four essential parts: a unique name (1 to 128 characters), a natural-language description the agent reads to decide when to use it, an optional inputSchema expressed as JSON Schema, and an execute callback that does the work and returns a result. The execute function runs your real application logic — the same code your buttons already call — so the agent and the human use identical code paths.

Note: the spec is still stabilizing during the origin trial. Recent drafts also reference the interface via document.modelContext, and exact naming may shift before the standard track. Treat the surface as evolving and pin to the version behind your origin-trial token.

No JavaScript Required: Declarative Forms

The most underrated part of the proposal is that simple sites need no JavaScript at all. You can annotate an existing HTML form with a few attributes and it instantly becomes an agent-callable tool:

<form tool-name="book_table"
      tool-description="Reserve a table at the restaurant">
  <input name="party_size"
         tool-param-description="Number of guests" />
  <input name="date"
         tool-param-description="Reservation date in YYYY-MM-DD format" />
</form>

This means legacy CMS pages, static sites, and server-rendered apps can join the agentic web without a rewrite. The browser maps the form fields to a tool schema automatically, and submitting the tool submits the form.

Why This Matters for Your Business

The shift here is bigger than a new API. For the past decade, the web was optimized for human eyes and mouse clicks. WebMCP optimizes it for delegated intent — a user says "reorder my usual" and the agent calls your reorder tool directly, reliably, every time.

A few concrete payoffs:

• Reliability over scraping. DOM-based agents break on every redesign. A registered tool keeps working as long as its contract holds, no matter how the UI changes.
• You stay in control. You decide exactly which actions agents can take. A read-only analytics tool can be flagged so agents know it is safe; a destructive action can require confirmation.
• Discoverability in the agent era. As users increasingly act through agents, sites that expose clean tools will be the ones agents can actually use. This is shaping up to be the SEO of the agentic web.

For e-commerce, that is "find me running shoes under 100 dinars and add my size to the cart." For SaaS dashboards, it is "show every account that renewed in Q1 and export the list." These are the same flows we explored in our guide to browser agents and web automation — except now the website cooperates instead of being scraped.

Security and Human-in-the-Loop

Keeping execution in the browser is powerful, so the design is deliberately conservative. Tools can only be registered in a secure context, and access is gated behind a tools permissions policy that defaults to the page's own origin. The execute callback receives a client object that lets a tool pause and request explicit user confirmation before doing anything sensitive — a built-in human-in-the-loop checkpoint.

Tools can also carry annotations such as readOnlyHint and untrustedContentHint, helping agents reason about risk. Cross-origin exposure is opt-in through an exposedTo allowlist, and CORS-style policies for tool access are still being finalized to prevent cross-tab data leakage. As always with a fast-moving standard, the security model is part of what is still being incubated — review it carefully before exposing high-stakes actions.

How to Get Started Today

1. Enable the flag. In Chrome 146 or later, open chrome://flags, search for "Experimental Web Platform features" or "WebMCP," enable it, and relaunch.
2. Register one tool. Pick a single, safe, read-only action on your site — a search or a filter — and wrap it with registerTool.
3. Test with an agent. Use a WebMCP-aware agent or extension to call the tool and confirm the schema and result round-trip cleanly.
4. Expand gradually. Add write actions behind confirmation, annotate read-only tools, and mount or unmount tools as users navigate.

Start small. One well-described tool teaches you more about agent-ready design than a hundred pages of spec.

The Bottom Line

WebMCP is early — it is an origin trial, not a shipping standard, and the API surface will move. But the direction is unmistakable. The web is becoming a place where humans and agents share the same controls, and the sites that publish clean, well-described tools will be the ones that work when a user delegates a task instead of doing it by hand.

At Noqta, we already build agent-ready experiences into the products we ship. If you want your website to be ready for the agentic web — not scraped by it — that work starts now. Talk to us about making your site agent-ready.