WebMCP (Web Model Context Protocol)

WebMCP (Web Model Context Protocol) is a browser-native standard that lets a website declare a set of callable tools, functions with a name, a description, and a JSON Schema for their inputs, that an AI agent running inside the user’s browser session can discover and invoke directly. Instead of an agent taking a screenshot, guessing which pixel is the “Add to Cart” button, and clicking it, the page itself says: here is a function called add_item_to_cart, here is what it needs, call it and I’ll tell you what happened. It matters because it flips the current agentic-browsing model on its head. Today’s browser agents (Claude’s computer use, OpenAI’s Operator-style agents, Perplexity’s Comet) mostly work by treating a webpage as a picture or a DOM tree to be parsed and reverse-engineered every single time. WebMCP lets the site hand the agent a stable, versioned API instead, the same shift Model Context Protocol made for connecting an LLM to a database or file system, applied to the open web.

Why the Web Needed This

Browser-using agents have gotten good at perceiving pages (reading screenshots, parsing accessibility trees) but they are still fundamentally guessing at intent and structure. A checkout flow that a human recognizes instantly (this input is the promo code, this button finalizes the order) is, to an agent parsing raw HTML, an undifferentiated pile of <div>s and <button>s with no semantic guarantee that a class named btn-primary means “submit” this month and not next month after a redesign. That fragility shows up as slow, expensive agent runs (multiple screenshot round-trips per step) and brittle failures the moment a site changes its markup.

The web already solved an adjacent problem for search engines with structured data (schema.org, JSON-LD): give the crawler explicit semantics instead of making it infer them. WebMCP is the same move for actions rather than content: a page doesn’t just describe itself, it exposes verbs an agent can call.

flowchart LR
    A[Browser agent task:<br/>'reorder my usual coffee']:::process --> B{Site exposes<br/>navigator.modelContext?}:::process
    B -->|Yes| C[Agent calls<br/>registered tool directly]:::output
    B -->|No| D[Agent screenshots page,<br/>parses DOM, guesses selectors]:::data
    C --> E[Structured result returned,<br/>no pixel parsing needed]:::output
    D --> F[Slower, brittle,<br/>breaks on redesign]:::data

    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;

How the API Works

The core of WebMCP is deliberately small. A page registers a tool with navigator.modelContext.registerTool() (the W3C draft moved this getter from Navigator to Document in May 2026, so document.modelContext is the direction the spec is heading, with navigator.modelContext kept around during the transition for compatibility). Each tool declaration has three parts:

• name: a short, machine-readable identifier (search_flights, apply_coupon, submit_support_ticket).
• description: a plain-language sentence telling an LLM-driven agent what the tool does and when to use it, this is the string the agent’s model actually reads to decide whether to call the tool.
• inputSchema: a JSON Schema describing the parameters, mirroring exactly how MCP tool definitions and OpenAI/Anthropic function-calling schemas already work, so the same mental model transfers.

The execute function runs in the page’s own JavaScript context. That’s the key architectural decision: the tool executes with the page’s existing session, cookies, and auth state, an agent calling add_item_to_cart doesn’t need a separate API key or backend integration, it’s driving the same client-side code a human’s click would have triggered. This also means the site retains full control: it can validate inputs, rate-limit calls, or refuse an action exactly as it would refuse a malformed form submission.

// A travel site exposes flight search as a callable tool
// instead of requiring an agent to fill in a form and click "Search".
document.modelContext.registerTool({
  name: "search_flights",
  description: "Search available flights between two airports on a given date.",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string", description: "IATA airport code, e.g. 'SFO'" },
      destination: { type: "string", description: "IATA airport code, e.g. 'JFK'" },
      date: { type: "string", format: "date" }
    },
    required: ["origin", "destination", "date"]
  },
  async execute({ origin, destination, date }) {
    const results = await flightSearchAPI.query({ origin, destination, date });
    return { content: [{ type: "text", text: JSON.stringify(results.slice(0, 5)) }] };
  }
});

On the agent side, a browser-embedded assistant (or an extension acting as one) enumerates whatever tools the current page has registered, includes their names, descriptions, and schemas as available functions in the model’s context window, and lets the model decide which to call, exactly the same tool-calling loop a developer would write against MCP or a provider’s function-calling API, just scoped to “whatever this one tab currently exposes.”

Relationship to MCP and A2A

It’s easy to conflate WebMCP with Model Context Protocol because they share a name and a philosophy, but they solve different halves of the same problem:

They’re complementary rather than competing: an agent might use MCP to pull structured data from a company’s internal CRM server, and WebMCP to actually complete a purchase on a public storefront that has no API relationship with the agent’s operator at all. Similarly, Agent2Agent Protocol (A2A) governs how two separate agents delegate work to each other; WebMCP governs how one agent talks to a webpage. A single agentic browsing session could plausibly touch all three: A2A to hand a sub-task to a specialist booking agent, that agent uses WebMCP to interact with the airline’s site, and MCP to log the completed itinerary into the user’s internal trip-tracking tool.

Standardization Status and Browser Support

WebMCP was first announced by Google’s Chrome team in February 2026 and shipped an early preview of navigator.modelContext in Chrome 146 that same month. It’s being developed openly through the W3C Web Machine Learning Community Group, with Google and Microsoft as the initial co-authors and Mozilla and Apple participating in spec discussions, the kind of multi-vendor buy-in that (unlike some past browser-only experiments) gives it a real shot at becoming an actual cross-browser standard rather than a Chrome-only feature. Chrome 149 opened a broader origin trial in May 2026 for registered developers to test the API against real traffic.

The spec itself is still moving: the May 27, 2026 draft relocated the entry point from navigator.modelContext to document.modelContext, reflecting a maturing view that “model context” is a property of the document being rendered, not of the navigator/browser instance. Sites building against WebMCP today should expect this kind of churn and treat early implementations as a preview, not a stable target, consistent with the technical notes’ own framing of the current spec as a working draft.

Why This Matters for SEO and Site Owners

Search and discovery are shifting from “does a crawler index my page” to “can an agent complete a task on my page,” and WebMCP is the mechanism by which that shift becomes concrete rather than aspirational. A site with well-described, correctly scoped tools gives an agent a fast, reliable path to a conversion (a booking, a purchase, a support ticket) instead of a slow, error-prone one built on screenshot parsing. Conversely, a site with no registered tools doesn’t disappear from agentic browsing, it just becomes the slow path: the agent falls back to vision-based interaction, which is more likely to misclick, more likely to time out, and more expensive per token for whoever is paying for that agent’s inference. In practice this makes tool descriptions the new meta-description: the plain-English description field on each registered tool is the string an LLM actually reads when deciding whether and how to use your site, which puts it squarely in the same “write for the model reading you” category as llms.txt and other emerging agent-facing SEO surfaces.

What’s New (2025-2026)

WebMCP moved fast for a browser standard. It went from a February 2026 announcement to a shipping Chrome preview in the same month, to a broader origin trial by May, with the W3C draft already undergoing a structural revision (the navigator → document move) within its first few months of public life. That pace reflects urgency on the browser vendors’ side: agentic browsing products (Comet, Operator-style agents, Claude’s computer use in browser contexts) were already shipping and relying entirely on brittle vision-and-DOM heuristics, so there was real pressure to standardize an action-exposure layer before every vendor rolled its own incompatible variant. The parallel emergence of the Agent2Agent protocol (donated to the Linux Foundation) and MCP’s rapid adoption (reportedly over 10,000 public MCP servers by 2026) shows the broader pattern: 2025-2026 was the period the agentic web grew an actual protocol stack, tool access (MCP), agent-to-agent delegation (A2A), and now agent-to-website action (WebMCP), instead of leaving every layer to ad hoc scraping and prompting.

Security and Trust Considerations

Because a WebMCP tool’s execute function runs with the page’s own session and permissions, the security model is closer to “what can this webpage’s JavaScript already do” than “what can an external API key do.” That’s reassuring in one sense (no new credential-leak surface beyond what XSS could already achieve) and concerning in another: a malicious or compromised site could register a tool with an innocuous-sounding name and description that actually performs a harmful action, a variant of prompt injection where the injected instruction lives in a tool’s metadata rather than in visible page text. Responsible implementations are expected to have the browser (not just the site) mediate tool calls, showing the user what an agent is about to do before high-stakes actions like payments execute, similar to how computer use agents are typically gated behind explicit user confirmation for sensitive steps. As the spec matures past its current working-draft status, expect permissioning, rate limits, and disclosure requirements around tool registration to be an active area of the standardization discussion rather than an afterthought.

// A storefront exposes "add to cart" as a first-class tool,
// so an in-page agent can act without parsing button labels or DOM structure.
navigator.modelContext.registerTool({
  name: "add_item_to_cart",
  description: "Add a product to the current shopping cart by SKU and quantity.",
  inputSchema: {
    type: "object",
    properties: {
      sku: { type: "string", description: "Product SKU, e.g. 'SKU-4821'" },
      quantity: { type: "integer", minimum: 1, default: 1 }
    },
    required: ["sku"]
  },
  async execute({ sku, quantity = 1 }) {
    const product = await store.findBySku(sku);
    if (!product) {
      return { content: [{ type: "text", text: `No product found for ${sku}` }], isError: true };
    }
    cart.add(product, quantity);
    return {
      content: [{ type: "text", text: `Added ${quantity} x ${product.name} to cart. New total: ${cart.total()}` }]
    };
  }
});