What Is WebMCP?
The web standard that lets AI agents actually use websites — not just read them.
On February 9, 2026, Google's Chrome team — with Microsoft co-authoring — proposed WebMCP: a browser-native API that gives AI agents a structured way to interact with any website. Instead of guessing how to click buttons and fill forms, websites publish a contract that tells agents exactly what actions are available, what inputs they accept, and how to invoke them. It's live in Chrome 146 behind a flag.
Read
Humans browse static documents
HTTP + HTMLRead + Write
Humans interact with dynamic applications
JavaScript + RESTRead + Write + Act
AI agents invoke structured tools on websites
navigator.modelContextThe Gap Between What AI Promises and What It Delivers
Every major AI assistant can have brilliant conversations. But ask any of them to actually do something on a website — book a flight, schedule an appointment, submit a form — and you hit a wall.
"I found their website. You'll need to book the flight yourself. Here's the link."
Time wasted: 30 seconds of failing silently
"Found 8 flights. The cheapest is $412 round-trip on SkyAlliance, departing 10:30am. Want me to book it?"
Time: 1.2 seconds. Zero guessing. Zero errors.
Medical Portal
A complex application form annotates itself as a submit_application tool — the agent maps data correctly, understanding the difference between a 'full legal name' field and separate 'first/last name' fields.
E-Commerce
A product search form registers as a searchProducts tool with explicit parameter types — the agent doesn't guess at filter meanings; the schema defines exactly what 'size', 'color', and 'priceRange' accept.
Developer Tools
A settings page exposes a run_diagnostics tool — the agent triggers it in one step instead of navigating 5 nested menus.
How WebMCP Works
WebMCP provides a contract between websites and AI agents. The website explicitly publishes its capabilities — what tools exist, what inputs they accept, and what the current page state is. The agent reads the contract, not the DOM.
Discovery
"What tools does this page have?"
A standard way for agents to query which tools a page supports.
Schemas
"What inputs does each tool need?"
Explicit JSON Schema definitions of required and optional inputs and expected output formats.
State
"What's available right now?"
A shared understanding of what tools are available at this moment — tools can appear and disappear as the user navigates.
Path 1: Declarative (HTML)
No JavaScript required
Add attributes to your existing <form> tags. The browser automatically converts them into tools that agents can discover and invoke.
Path 2: Imperative (JavaScript)
Full programmatic control
Register tools via JavaScript with custom execute functions that can do anything your code can do. Dynamic tool availability based on user state.
readOnlyHintThis tool only reads data, never modifies anythingdestructiveHintThis tool deletes or irreversibly changes dataidempotentHintCalling this tool twice has the same effect as onceopenWorldHintThis tool interacts with external systemsrequestUserInteraction()Pauses the agent and asks the human for explicit approval before proceeding — required for purchases, account changes, or any sensitive actionHuman controlThe human is always in control. The agent cannot bypass consent.registerTool()Add a new tool when a page loads or state changesunregisterTool()Remove a tool when it's no longer relevantprovideContext()Update the full set of available tools at onceclearContext()Remove all tools (e.g., on page navigation)Real Code, Real API
Every example uses the correct, official API. The namespace is navigator.modelContext — not navigator.ai. If you find examples elsewhere using different APIs, they are outdated.
1// Feature detection — always check before using
2if (!("modelContext" in navigator)) {
3 console.log("WebMCP not supported in this browser");
4 // Graceful degradation — your site works normally
5} else {
6
7 // Register a flight search tool
8 navigator.modelContext.registerTool({
9 name: "searchFlights",
10 description: "Search for available flights between two airports",
11 inputSchema: {
12 type: "object",
13 properties: {
14 origin: {
15 type: "string",
16 description: "Departure airport IATA code (e.g., 'LHR')"
17 },
18 destination: {
19 type: "string",
20 description: "Arrival airport IATA code"
21 },
22 outboundDate: {
23 type: "string",
24 description: "Departure date in YYYY-MM-DD format"
25 },
26 passengers: {
27 type: "integer",
28 description: "Number of passengers (1-9)",
29 minimum: 1,
30 maximum: 9
31 }
32 },
33 required: ["origin", "destination", "outboundDate", "passengers"]
34 },
35 annotations: {
36 readOnlyHint: true, // Only reads data
37 openWorldHint: true // Queries external systems
38 },
39 execute: async (input) => {
40 const results = await flightAPI.search(input);
41 return {
42 content: [{
43 type: "text",
44 text: JSON.stringify(results)
45 }]
46 };
47 }
48 });
49
50}inputSchema uses standard JSON Schema (not a custom format)
annotations tell the agent this is read-only and queries external systems
execute returns a content array with type and text — not a raw object
Feature detection wraps everything — site works normally without WebMCP
WebMCP in Action
Real scenarios grounded in actual protocol capabilities
"Find me a cheap round-trip to Tokyo in October"
Agent discovers searchFlights tool (via navigator.modelContext)
Agent invokes searchFlights({ origin: "SFO", destination: "NRT", tripType: "round-trip", ... })
Tool annotation: readOnlyHint: true — agent knows this is safe to call
Tool returns: { content: [{ type: "text", text: "[8 flight options...]" }] }
"Found 8 flights. ANA has a round-trip for $687 departing Oct 1 at 11:45am. Want me to book it?"
If user says yes → agent invokes bookFlight tool → requestUserInteraction() fires → user confirms payment → done.
"Find me a blue dress under $150"
Store's search form has toolname="searchProducts" with toolparamdescription attributes
Agent reads auto-generated schema, invokes: { query: "dress", color: "blue", maxPrice: 150 }
toolautosubmit is set — the form submits automatically
Site detects event.submitter.agentInvoked === true and returns structured JSON
"Found 12 blue dresses under $150. The top-rated one is the Aria Wrap Dress at $89 with 4.8 stars."
No JavaScript required on the store's side — pure declarative HTML attributes.
"Schedule me an appointment with Dr. Patel next week"
Agent discovers two tools: checkAvailability (readOnlyHint: true) and scheduleAppointment
Step 1: Agent calls checkAvailability — no consent needed (read-only)
Step 2: Agent shows available options to user
Step 3: Agent calls scheduleAppointment → requestUserInteraction() fires for health data
"Confirmed! Dr. Patel, Tuesday at 2:30pm. You'll receive a confirmation email."
User explicitly confirms in the browser before any appointment is booked.
Dynamic tool management across page states
Search page → provideContext({ tools: [searchFlights] })
Results page → provideContext({ tools: [getDetails, selectFlight] })
Booking page → provideContext({ tools: [fillPassengerInfo, addBaggage] })
Payment page → provideContext({ tools: [submitPayment] })
As the user navigates, the agent always sees exactly which actions are possible at each step.
Old tools are automatically removed — no stale state.
Why WebMCP Matters
WebMCP is to AI agents what HTTP was to web browsers. HTTP gave browsers a standard way to request documents. WebMCP gives agents a standard way to invoke actions.
For Users
Natural language becomes the interface
Before WebMCP: You search, browse, compare, fill forms, click buttons. After WebMCP: You describe what you want. Your AI agent does the rest.
The WebMCP travel demo already shows an agent searching flights, comparing options, and initiating bookings — all from a single natural-language request. The interface layer between you and websites dissolves.
The shift: From "I use websites" to "My agent uses websites for me."
For Businesses
A new competitive dimension
If your competitor's website is WebMCP-ready and yours isn't, AI agents will complete transactions on their site but not yours. When a user says "book me a hotel," the agent will choose the site where it can actually execute.
"Agent SEO" becomes a new discipline. How you name your tools, describe your parameters, and structure your schemas determines whether agents choose YOUR site over a competitor's.
The economic model shifts from ATTENTION to TRANSACTION. Businesses that make themselves easy for agents to use capture a disproportionate share of AI-driven commerce.
For Developers
Every form becomes a function
WebMCP turns the web into a massive function library. Every form is a callable function. Every website is an API. No API key management, no server deployment, no separate documentation — the schema IS the documentation.
The declarative path means existing HTML forms become agent-callable with zero JavaScript. The imperative path gives you full programmatic control. And it's backwards compatible: a WebMCP-enhanced page works exactly the same for human visitors.
Browsers that don't support WebMCP simply ignore the new attributes. Zero degradation.
An Open Standard, Not a Walled Garden
WebMCP is a proposed open web standard — not a proprietary platform. Any browser can implement it. Any AI assistant can use it. The spec is public on GitHub. It builds on existing web primitives (HTML forms, JSON Schema, DOM events). The web has always been most powerful when it's open.
MCP vs WebMCP
MCP (Anthropic) and WebMCP (Google) both connect AI agents with external tools. They operate at different layers of the stack. They're complementary, not competing.
MCP (Anthropic)
Server-side protocol
Think of it as: "An API for AI" (server-side)
WebMCP (Google / Chrome)
Client-side browser API
Think of it as: "An API for AI" (browser-side)
When to use which
Use MCP when
You want AI to access your databases, internal tools, file systems, or server-side functionality.
Use WebMCP when
You want AI to interact with your website the way a user would — searching, browsing, booking, purchasing.
Use both when
You have a full-stack application where agents need both server-side access (MCP) and client-side interaction (WebMCP).
The Full Comparison
How WebMCP stacks up against every alternative approach
| Dimension | WebMCP | MCP (Anthropic) | Screen Scraping | Custom APIs | OpenAPI / REST | llms.txt |
|---|---|---|---|---|---|---|
| Where it runs | Browser (client) | Server | Browser (client) | Server | Server | Static file |
| Backed by | Google + Microsoft | Anthropic | N/A | You | OpenAPI Initiative | Community |
| Reliability | High (structured) | High (structured) | Low (fragile) | High | High | Medium |
| Setup effort | Low-Medium | Medium-High | High | High | High | Low |
| Declarative HTML | Yes | No | No | No | No | N/A |
| User consent | Yes | 🟡Partial | No | 🟡Partial | 🟡Partial | N/A |
| Works with existing sites | Yes | No | 🟡Partial | No | No | Yes |
| Browser maturity | 🟡Partial | N/A | Yes | N/A | N/A | Yes |
| Standardized | 🟡Partial | 🟡Partial | No | No | Yes | 🟡Partial |
| Best for | Web interactions | Server tools | Legacy sites | Custom integrations | Existing APIs | Content access |
Honest note: Screen scraping works TODAY on every website, without any website cooperation. WebMCP requires websites to opt in by adding tools. The value proposition is reliability and structured interaction vs. the universal but fragile nature of scraping. Both will coexist.
Current Status
Here's exactly where WebMCP stands today — no hype, no spin
Available Now
In Progress
Not Yet
Known Limitations
Requires Browsing Context
WebMCP tools only work when a user has the page open in a browser tab. Headless/background access is not supported (Service Worker extension is future work).
Tool Discoverability Is Unsolved
The spec explicitly states: "How exactly can an agent know ahead of time which pages or sites offer relevant tools?" This is an open research problem.
This is exactly the problem WebMCP's Discovery Hub aims to solve.
Complexity for Rich UIs
The spec acknowledges that "some interactions are inherently visual" and complex UI patterns (drag-and-drop, canvas drawing) may not map cleanly to tool invocations.
Adoption Is Zero-Base
No major website has publicly announced WebMCP implementation. First-mover advantage is real, but so is the risk of building for an evolving standard.
Every limitation listed above is an opportunity: no discoverability means tool directories matter. No testing tools means the first tooling wins. No cross-browser means early movers build expertise before the rush.
Get Started with WebMCP
Choose your path based on your role
For Developers
Try it in 5 minutes
Enable the flag
Open Chrome 146+ → chrome://flags → Search for "Web Model Context Protocol" → Enable and restart Chrome
Inspect the demo
Visit travel-demo.bandarra.me → Open DevTools → Install the "Model Context Tool Inspector" extension → See registered tools live
Add your first tool
Pick any form on your site → Add toolname and tooldescription attributes → Add toolparamtitle to each input → Reload — your form is now a WebMCP tool
Go deeper
Read the full specification, explore WebMCP best practices, and get your free Agent Readiness Score to see what else you can optimize
Frequently Asked Questions
Every question we've been asked — with straight answers
Now You Understand WebMCP. Try It on Your Site.
The specification is public, Chrome 146 ships with the API behind a flag, and the declarative approach requires zero JavaScript. You can add WebMCP attributes to an existing form in under five minutes and test it immediately.
Start with one form. See how agents discover and use it.
The scanner checks which of your forms are already agent-compatible and suggests the exact attributes to add.