WebMCP Explained: What It Is, How It Works, and Why It Changes the Web

On February 10, 2026, Google's André Cipriani Bandarra published a short blog post on Chrome for Developers that introduced an early preview of WebMCP — the Web Model Context Protocol. The premise was deceptively simple: what if websites could tell AI agents exactly what they can do, instead of making agents guess?

That single idea — replacing guesswork with a structured contract between websites and AI — is now on a path to becoming a formal web standard. It has backing from both Google and Microsoft, it's being incubated through the W3C, and its first browser implementation is already live in Chrome Canary.

To understand why this matters, consider what happens today when you ask an AI assistant to book you a flight. The agent takes a screenshot of the airline's website, feeds it to a vision model, tries to figure out which thing on screen is the departure field, types into it, takes another screenshot, looks for the search button, clicks it, takes another screenshot, and so on — dozens of expensive inference calls just to fill out a form. If the airline redesigns its page next week, the whole process breaks.

WebMCP replaces that entire loop with a single function call: searchFlights("AMS", "JFK", "2026-06-15"). The website publishes the function. The agent calls it. Done.

The SEO community reacted immediately. Technical SEO expert Dan Petrovic called it the biggest shift in technical SEO since structured data — and WordLift captured the analogy well: if Schema.org provided the standardized nouns of the web, WebMCP provides the standardized verbs.

What Is WebMCP?

WebMCP stands for Web Model Context Protocol. It's a proposed web standard that allows websites to expose their functionality as structured, callable "tools" that AI agents can invoke directly through the browser.

The specification was jointly authored by engineers from Google and Microsoft — Brandon Walderman, Leo Lee, and Andrew Nolan from Microsoft, and David Bokan, Khushal Sagar, and Hannah Van Opstal from Google. It's being developed through the W3C Web Machine Learning Community Group, the same W3C venue that incubates other browser-level machine learning standards, with the goal of becoming a broadly adopted web standard.

As of February 2026, WebMCP is available behind an experimental flag in Chrome 146 Canary. Developers can access documentation and demos by joining Google's Early Preview Program. Given Microsoft's active role in co-authoring the spec, Edge support is widely expected to follow.

The spec itself describes WebMCP as "a JavaScript interface that allows web developers to expose their web application functionality as 'tools' — JavaScript functions with natural language descriptions and structured schemas that can be invoked by AI agents, browser assistants, and assistive technologies."

That last phrase — assistive technologies — is easy to overlook, but important. Much of what makes the web difficult for AI agents also makes it difficult for screen readers and other accessibility tools. WebMCP's structured tool approach could significantly improve both.

The Problem WebMCP Solves

AI agents interact with websites today using two main approaches, and both are fundamentally limited.

Visual agents take screenshots of web pages, pass them to vision models, and attempt to locate buttons and form fields by analyzing pixels. Every interaction requires a fresh screenshot and a new inference call. A simple product search might take a dozen round-trips. If the site's layout shifts even slightly — a redesign, an A/B test, a different screen size — the agent can fail.

DOM-based agents parse a page's raw HTML and accessibility tree to extract data and trigger events. This is more reliable than pixel analysis, but it still forces the agent to consume large amounts of context window reading through page structure, and it requires the agent to reverse-engineer what each element actually does. A <button> labeled "Go" could mean search, submit, navigate, or delete — the agent has to infer from surrounding context.

Both approaches share the same fundamental flaw: the AI is trying to use a human interface that was never designed for machines. As the WebMCP spec puts it, "even when agents succeed, simple operations often require multiple steps and can be slow or unreliable."

WebMCP offers a third path. Instead of the agent figuring out what a website can do, the website declares its capabilities explicitly — and the agent calls them directly.

How WebMCP Works

WebMCP introduces a new browser API: navigator.modelContext. Through this API, a website registers "tools" — JavaScript functions with natural language descriptions and typed parameter schemas. Taken together, these tool definitions form what's been called the site's Tool Contract: a machine-readable menu of every action an AI agent can perform on that page.

The spec offers two complementary ways to define these tools.

The Declarative API (HTML-Based)

This is the lowest-friction path. Developers add new attributes to their existing HTML forms, and the browser automatically converts them into agent-callable tools. No JavaScript required.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

The toolname and tooldescription attributes are the only additions. The browser reads the form's existing structure — field names, types, validation patterns, required flags — and generates a schema that an AI agent can understand and invoke. For sites that already have well-structured forms, this is remarkably close to a drop-in upgrade.

When an agent invokes a Declarative tool, the browser fires a SubmitEvent with an agentInvoked property set to true. This lets the backend distinguish between human and agent submissions — useful for analytics, rate limiting, or returning data in a format optimized for machines rather than rendered HTML.

The Imperative API (JavaScript-Based)

For interactions that go beyond form submissions — dynamic multi-step workflows, real-time data processing, conditional logic — developers register tools programmatically:

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

This gives full programmatic control. Developers can dynamically add and remove tools based on application state — surfacing different capabilities depending on whether a user is logged in, what page they're on, or what step they've reached in a workflow. Crucially, the handler functions can reuse the same frontend logic that already powers the site's UI. You're not building a separate integration layer; you're exposing what you've already built.

The Browser as Intermediary

One of WebMCP's most consequential design decisions is that the browser mediates all communication between the website and the agent. The website registers tools through navigator.modelContext. The browser surfaces those tools to the agent in whatever format the agent requires. Website and agent never talk directly.

As Patrick Brosset from the Microsoft Edge team explained: "It's the browser that talks to the agent. The spec uses the term 'Model context provider.' Through navigator.modelContext, your webpage provides context — the tools that an AI agent then uses — but it's the browser that does the protocol work for you."

This architecture solves three problems simultaneously.

Authentication is inherited. Tools execute within the browser tab, in the context of the user's existing session. If you're logged into an e-commerce site, the agent has access to the same session — no separate OAuth flows, no API keys, no token management.

The user stays in control. Everything happens within the visible browser tab, so the user can see what the agent is doing. For sensitive actions — purchases, personal data submissions, deletions — the spec includes agent.requestUserInteraction(), which pauses execution and asks the browser to get explicit user confirmation before proceeding.

Platform independence. Whether the visiting agent runs on ChatGPT, Claude, Gemini, or a custom enterprise model, the website's Tool Contract stays the same. The browser normalizes the interaction.

Where WebMCP Came From

WebMCP didn't start at Google or Microsoft. It started with a frustrated engineer at Amazon.

In early 2025, Alex Nahas was building internal AI agents at Amazon using Anthropic's Model Context Protocol (MCP). Amazon had spun up what amounted to one enormous MCP server exposing thousands of tools across its internal services. "You had to disable them with process commands in the connection string," Nahas told Arcade.dev. It was unwieldy, but the real blocker was authentication. MCP's spec had adopted OAuth 2.1, which virtually no Amazon internal service had implemented. Every service had its own auth story, and none of them spoke OAuth.

Then Nahas had an insight: the browser already solved this problem. Amazon employees were signed into every internal service through a federated browser-based authentication experience. If you could run MCP-style tools inside the browser tab, you'd inherit all that authentication for free.

He built MCP-B (Model Context Protocol for Browser) as a proof of concept. It worked. He open-sourced it.

Meanwhile, engineers at Google and Microsoft were independently working on similar problems. The teams connected through the W3C, converged on a unified specification by August 2025, and published it on GitHub. The W3C Web Machine Learning Community Group accepted it as a formal deliverable in September 2025. In February 2026, Google shipped the first browser implementation.

One important nuance: despite the name, WebMCP is not technically MCP. As Nahas explained, he initially pushed to port the full MCP protocol (JSON-RPC and all) to the browser, but the working group chose not to couple too tightly to Anthropic's spec. WebMCP shares MCP's conceptual model — tools with schemas that agents call — but it's a distinct, browser-native standard.

WebMCP vs. MCP vs. NLWeb

The naming creates confusion, so it's worth clarifying how WebMCP fits alongside the other protocols in the AI agent ecosystem.

Anthropic's MCP (Model Context Protocol) is a backend protocol. It connects AI platforms to external services through server-side integrations using JSON-RPC. If you want Claude or ChatGPT to query your company's database, MCP is how you build that connection. It requires dedicated server infrastructure.

Microsoft's NLWeb, announced in May 2025, gives websites a natural language query interface and makes each site act as an MCP server for agents in the broader ecosystem. It operates at the API level — agents talk to the site's backend directly.

WebMCP runs entirely client-side, in the browser. The website registers tools when the page loads. The browser exposes them to visiting agents. No backend infrastructure required. Authentication is inherited from the user's session.

The three are complementary, not competing. A business might use MCP for deep backend integrations, NLWeb for API-level natural language access, and WebMCP for browser-level interactions where the user is present. The key distinction: WebMCP is the only one that lets developers reuse existing frontend code and doesn't require any new server-side infrastructure.

Why It Matters

What makes WebMCP significant is less any single feature than the combination of several properties.

Dramatically lower cost per interaction. A single structured tool call replaces what previously required dozens of back-and-forth interactions involving screenshots, vision model inference, and DOM parsing. Early reports suggest an approximately 67% reduction in computational overhead compared to visual agent approaches. For high-traffic websites handling thousands of agent interactions per day, the cost savings are substantial.

Reliability decoupled from design. Structured function calls don't break when a designer moves a button, renames a CSS class, or runs an A/B test. The Tool Contract provides a stable interface independent of visual layout — which means agents and web designers can evolve independently.

Minimal developer lift. The Declarative API requires adding two HTML attributes to existing forms. No JavaScript, no new endpoints, no API documentation to maintain. For the majority of websites, the path to becoming "agent-ready" is shorter than most SEO optimizations.

Accessibility as a side effect. The same structured tool definitions that help AI agents also help assistive technologies. Screen readers and other accessibility tools face many of the same challenges as AI agents when trying to understand what a web page does, not just what it says. WebMCP could meaningfully improve both.

Industries and Use Cases

Google's early preview documentation highlights several primary use cases, all involving structured, multi-step user workflows.

E-commerce is the most obvious beneficiary. Instead of an AI agent fumbling through product filters, size selectors, and checkout flows, a store exposes tools like searchProducts(query, priceRange, category), addToCart(productId, quantity, size), and checkout(paymentMethod). The entire journey from discovery to purchase becomes a series of clean function calls. For businesses, this could mean significantly higher agent-driven conversion rates.

Travel and hospitality is a natural fit. Flight search, hotel booking, and car rental are structured, multi-parameter transactions that map directly to tool definitions. Google specifically cited travel booking as a primary verified use case.

SaaS products can expose their core workflows to agents. Imagine telling an AI assistant "create a new project board with three columns and invite my team" and having it execute through structured tool calls rather than simulated clicks and keystrokes.

Customer support portals can define tools for ticket creation, status checks, and issue categorization. An agent that can call createTicket(category, urgency, description) directly is far more reliable than one that has to navigate a multi-step support form visually.

The SEO Implications

The SEO community's strong reaction to WebMCP isn't hype — it reflects a structural shift in how websites get discovered and used.

The analogy to Schema.org is useful. When structured data launched, it gave search engines a standardized way to understand what content means. Websites that adopted it early gained rich snippets, knowledge panel placements, and better search visibility. Those that didn't found themselves at a disadvantage that took years to close.

WebMCP does something parallel, but for a different era. It gives AI agents a standardized way to understand what actions a website supports. As agents become a primary channel through which people interact with the web — booking travel, shopping, managing services — the sites with clear, reliable Tool Contracts will be the ones agents can confidently work with.

This creates a new kind of competitive dynamic. If an AI agent can call bookFlight() directly on one travel site but has to brute-force its way through pixel-scraping on another, the structured option will be faster, cheaper, and less error-prone. Over time, that reliability advantage compounds — agents (and the platforms that host them) will naturally route users toward sites that are easier and cheaper to interact with.

For businesses, WebMCP readiness may become as important as mobile responsiveness was a decade ago. Not overnight, but steadily, as browser support broadens and agent-mediated interactions grow.

How to Get Started

WebMCP is in early preview, which means the window for early adoption is open now.

Audit your site's key workflows. Identify the core user actions — search, booking, checkout, form submissions, account management — that would benefit from being exposed as tools. Start with the highest-value transactions.

Begin with the Declarative API. If you have clean, well-structured HTML forms, adding toolname and tooldescription attributes is the fastest path. This requires no JavaScript and minimal code changes.

Join the Early Preview Program. Google's EPP provides access to full documentation, demos, and testing tools. Sign up through the Chrome for Developers site.

Test in Chrome Canary. Enable the "WebMCP for testing" flag in Chrome 146 Canary. Google's Model Context Tool Inspector provides debugging tools for validating your tool definitions.

Explore the Imperative API for complex workflows that require dynamic tool registration or multi-step logic.

For developers who want to start building before native browser support is widely available, Alex Nahas's MCP-B polyfill (@mcp-b/global) lets you register tools with navigator.modelContext.registerTool() today. It works with existing frontend tool-calling frameworks like CopilotKit, AGUI, and SystintUI. Full documentation is at docs.mcp-b.ai.

The W3C specification is available on GitHub.

What's Next

The spec is still in draft form, but the trajectory is clear.

Formal browser rollout is expected by mid-to-late 2026. Google I/O and Google Cloud Next are the most likely venues for broader announcements. Given Microsoft's co-authorship of the spec, Edge support should follow Chrome's timeline. Patrick Brosset from the Edge team has explicitly signaled continued investment: "On the Edge team, we care about keeping not only the human in the loop, but developers too. That's why we care about WebMCP."

The API continues to evolve. The interface has already moved from the earlier window.agent to window.navigator.modelContext, and features like agent.requestUserInteraction() have been added since the initial August 2025 proposal. The W3C community is actively refining the spec based on real-world testing.

Multimodal support is on the broader MCP ecosystem roadmap. Future protocol versions are expected to handle images, video, and audio — meaning agents won't just read and write, but interpret visual and audio content through the same framework.

Agent-to-agent communication is the next frontier. The current spec focuses on user-to-agent interaction through the browser, but the roadmap includes scenarios where agents delegate tasks to other agents across multiple services and pages.

Frequently Asked Questions

Is WebMCP the same as Anthropic's MCP? No. They share a conceptual model — tools with schemas that agents can call — but WebMCP is a distinct standard. It doesn't use JSON-RPC, runs entirely in the browser (not on backend servers), and was designed specifically for the web platform. The two are complementary: a business might adopt both for different use cases.

Which browsers support WebMCP? As of February 2026, WebMCP is available in Chrome 146 Canary behind the "WebMCP for testing" flag. Edge support is widely anticipated given Microsoft's role in co-authoring the spec. Formal rollout is expected by mid-to-late 2026.

Do I need to rewrite my website? No. The Declarative API lets you add WebMCP support by adding two HTML attributes to existing forms. For sites with clean, well-structured HTML, the changes are minimal. The Imperative API requires JavaScript but can reuse existing frontend logic.

Can AI agents take actions without user permission? Not by design. WebMCP includes agent.requestUserInteraction(), which pauses execution for user confirmation on sensitive actions. The spec is built around the principle that no consequential action should happen without the user's awareness and consent.

Does WebMCP improve accessibility? Potentially, yes. The structured tool definitions that help AI agents understand what a page does can also help screen readers and other assistive technologies. The W3C spec explicitly lists assistive technologies as a target use case alongside AI agents.

How does WebMCP affect SEO? The full picture is still forming, but the structural parallels to Schema.org are clear. As AI agents become a transaction and discovery channel, sites with well-defined Tool Contracts will be easier and cheaper for agents to work with — creating a natural advantage similar to what early structured data adopters experienced in search.

The Bottom Line

For thirty years, the web has been a place designed for human eyes and human hands. Every page, every button, every form assumes a person is on the other end. WebMCP is the first serious, standards-backed effort to make the web natively understandable and actionable by AI agents — without removing the human from the loop.

It's still early. The spec is in draft. The browser support is experimental. But the foundation is solid: two of the world's largest browser vendors collaborating through the W3C, a working implementation already available for testing, and a developer experience simple enough that most sites can start with two HTML attributes.

The businesses that recognized the importance of structured data early gained years of competitive advantage in search. The same window is opening now with WebMCP — and it won't stay open forever.