WebMCP dropped on February 10, 2026. I heard the announcement, opened Chrome Canary, enabled the flag, and typed this in DevTools:

It was real. So I spent the next week going deep — building with it, reading the W3C spec, comparing it to Anthropic's MCP. This is everything I found.

The Problem WebMCP Solves

Before I explain what WebMCP is, let me explain why it needed to exist.

Right now, when an AI agent wants to interact with a website — book a flight, fill a form, submit an order — it works like this:

This is called browser automation and it's how tools like Playwright, browser-use, and most agentic AI work today. It's slow, expensive (every screenshot burns tokens), and incredibly fragile — move a button 5 pixels and the agent breaks.

WebMCP is a completely different approach. Instead of the agent _guessing_ how to interact with your site by looking at screenshots, your website tells the agent exactly what it can do — through structured, callable JavaScript functions.

What WebMCP Actually Is

WebMCP (Web Model Context Protocol) is a new browser-native JavaScript API — a W3C Draft Community Group specification published February 12, 2026, authored by engineers from Google (Khushal Sagar, Dominic Farolino) and Microsoft (Brandon Walderman).

The entire API surface lives on one property:

That's the entry point to everything. When I ran this in Chrome Canary DevTools:

Five methods. That's literally the whole API. Four of them are the ones you'll use as a developer.

The spec's one-line abstract says it best:

> "The WebMCP API enables web applications to provide JavaScript-based tools to AI agents."

The W3C Spec — What It Actually Says

I read the full spec at webmachinelearning.github.io/webmcp so you don't have to. Here's the complete IDL — the canonical definition of every interface:

A few things worth noting from the spec directly:

`[SecureContext]` — WebMCP only works on HTTPS. Plain HTTP sites won't have navigator.modelContext at all. This is intentional security design.

`[SameObject]` — navigator.modelContext always returns the same instance. It's not creating a new object each access.

The spec names Claude and ChatGPT explicitly — under "AI Platform" terminology, the spec lists "OpenAI's ChatGPT, Anthropic's Claude, or Google's Gemini" as intended consumers. That's unusual for a W3C document and tells you this is built specifically for the current generation of AI.

Many sections say "TODO" — the Security section, Accessibility section, and all the implementation step details are currently blank. This is a living document being actively written. The interface is defined; the internals are still being specified.

The Core API — With Real Examples

registerTool() — The Main Event

This is what you'll use 90% of the time. You register a named function with a description and JSON Schema. The agent sees this and knows it can call it.

The spec says registerTool throws an error if:

- A tool with the same name is already registered

- The inputSchema is not valid JSON Schema

So in React, you need cleanup in your useEffect:

provideContext() — Register Everything at Once

When you want to declare your full set of tools in one shot, replacing whatever was there before:

The difference from registerTool: provideContext clears all existing tools first then registers the new list. Use it when you want a clean slate. Use registerTool when you're adding tools incrementally (like in individual React components).

clearContext() — Remove Everything

Useful when the user navigates to a different section of your app where the previous tools no longer make sense.

unregisterTool(name) — Remove One Tool

Takes the name string. This is what you call in React's useEffect cleanup.

requestUserInteraction() — The Hidden Gem

This is the most underreported feature of WebMCP and the one that makes it fundamentally different from headless automation.

The execute callback receives two arguments: (input, client). That client is a ModelContextClient — and it has one method: requestUserInteraction().

It lets your tool pause mid-execution and ask the human to confirm before continuing:

The agent calls the tool. Your execute runs. At the requestUserInteraction line, execution pauses and a native browser dialog appears. The user clicks OK or Cancel. Only then does the agent get a result. The agent has zero ability to bypass this — it's baked into the protocol.

This is how WebMCP implements "human-in-the-loop" at the API level, not as an afterthought.

The readOnlyHint Annotation

The spec defines one annotation today: readOnlyHint. When true, it signals to the agent that calling this tool has no side effects — it only reads data.

This helps agents make smarter decisions — they know they can call read tools liberally but should be cautious (or ask for confirmation) with write tools.

Building a Real Example — Student Enrollment in Next.js

I built this for my project Skillora (an education management SaaS). Here's how I structured WebMCP tools in a Next.js app with a reusable hook.

The Hook

Using It in a Component

When an AI agent visits this page, it can now do the entire enrollment flow in three structured calls — no screenshots, no DOM manipulation, no guessing.

WebMCP vs Anthropic's MCP — The Real Difference

This is where most people get confused. Despite the similar name, these are completely different protocols.

The mental model I use:

> MCP is for agents working alone in the dark.

> WebMCP is for agents working alongside humans in the light.

The Auth Difference Is The Biggest Deal

With a backend MCP server, you have to build OAuth 2.1 from scratch. Every service needs tokens, scopes, refresh logic — it's weeks of work.

With WebMCP, the user is already logged in. The browser session cookie is already there. You just call fetch("/api/enroll", { credentials: "same-origin" }) and auth is handled automatically.

When to Use Which

Use MCP Server when:

- Background automation — nightly reports, bulk operations

- No UI needed — pure data and API operations

- Integration with Claude Desktop, ChatGPT, Cursor

- The operation is fully autonomous with no human confirmation needed

Use WebMCP when:

- User is actively in the browser and AI is assisting them

- You want to reuse your existing frontend auth session

- The operation should update the visible UI

- You need human confirmation at specific steps

Use both (ideal architecture):

How WebMCP Connects to Claude and ChatGPT Today

Since WebMCP tools live in the browser, how do you get Claude Desktop or ChatGPT to call them? This is where MCP-B comes in — a bridge library by Alex Nahas (the same person who co-authored the WebMCP spec).

Setting It Up

Step 1 — Install the polyfill in your app:

Step 2 — Install and start the native server:

Step 3 — Add to Claude Desktop config:

Step 4 — Install the MCP-B Chrome extension from the Chrome Web Store.

Now your WebMCP tools are callable from Claude Desktop. You write one set of tools. Claude, ChatGPT, and any MCP-compatible client can call them.

The Honest Reality Check

WebMCP is genuinely exciting but it's important to be clear-eyed about where it is today:

- Chrome Canary only — not stable Chrome, not Firefox, not Safari

- No cross-browser commitment yet — Mozilla and Apple haven't announced support

- The spec has TODO sections — security and accessibility considerations aren't written yet

- The Chrome built-in AI that will call these tools isn't publicly available yet

- Production timeline — stable Chrome support is probably late 2026 at earliest

But here's why I'm writing about it now rather than waiting: the fundamentals are sound, the spec is real W3C work with Google and Microsoft behind it, and the Chrome Canary implementation is working. If you're building web apps today, understanding WebMCP puts you 6-12 months ahead of when everyone else starts scrambling to add it.

How to Get Started Right Now

1. Apply for the EPP:

Go to developer.chrome.com/blog/webmcp-epp and apply.

2. Download Chrome Canary:

google.com/chrome/canary — installs separately from regular Chrome.

3. Enable the flag:

In Chrome Canary, go to chrome://flags/#webmcp-for-testing and set it to Enabled. Relaunch.

4. Verify it's working:

5. Register your first tool:

Open the Model Context Tool Inspector extension, find say_hello, call it with { "name": "World" }, and watch the alert fire. Your first real WebMCP tool, running in a real browser.

The Big Picture

WebMCP doesn't change what your website does. It adds a second audience for it.

Humans use your UI. Agents use your tools. Same website, same code, same authentication, same business logic. You're not building a separate AI integration — you're making your existing app speak a language that AI agents understand.

The web has done this before. RSS feeds let feed readers consume your content. JSON-LD lets search engines understand your data. Open Graph lets social networks preview your links. Every time the web added a machine-readable layer on top of the human-readable layer, developers who added it early got outsized benefits.

WebMCP is that next layer — for the age of AI agents.

It's early. The spec has TODOs. Chrome Canary is not production. But the direction is clear, the people building it are serious, and the problem it solves is real.

I'm building it into Skillora now. By the time it ships in stable Chrome, it'll already be there.

Resources

- My Demo: webmcp.sobitprasad.com

- GitHub: github.com/sobitp59/webmcp-tuta

- W3C Spec: webmachinelearning.github.io/webmcp

- Chrome EPP: developer.chrome.com/blog/webmcp-epp

- Official Demo: andreinwald.github.io/webmcp-demo

- GoogleChromeLabs Tools: github.com/GoogleChromeLabs/webmcp-tools

- MCP-B (bridge to Claude/ChatGPT): github.com/WebMCP-org

- Awesome WebMCP list: github.com/webmcpnet/awesome-webmcp

- W3C Community Group: github.com/webmachinelearning/webmcp