This document collects community technical notes on the Web Model
Context Protocol (WebMCP) [[WEBMCP-SPEC]], a proposed browser API
that allows web pages to expose JavaScript functions as structured
tools discoverable by AI agents, browser assistants, and assistive
technologies through the navigator.modelContext interface.
The notes cover the origin and standardization history of WebMCP, practical testing and risk guidance for the community, and a critical architectural analysis of how WebMCP relates to — and differs from — the Model Context Protocol (MCP) [[MCP]]. These notes are contributed via the W3C AI Knowledge Representation Community Group to support informed community engagement during the specification's formative period.
These technical notes were prepared within the W3C AI Knowledge Representation Community Group. They are contributed to support community review of the WebMCP specification [[WEBMCP-SPEC]] during its incubation in the W3C Web Machine Learning Community Group [[WEBML-CG]].
This is a discussion document and does not represent consensus of any W3C body. The window for meaningful community input on WebMCP is now — before implementation momentum makes the current design effectively permanent.
On February 10, 2026, Google's Chrome team launched an early
preview of WebMCP — a proposed web standard that allows any
website to expose structured, callable tools to AI agents
through a new browser API called
navigator.modelContext. The specification is a
Draft Community Group Report published by the W3C Web Machine
Learning Community Group [[WEBML-CG]]. It is not a W3C Standard
nor is it on the W3C Standards Track.
WebMCP proposes two APIs. A Declarative API
handles standard actions that can be defined directly in HTML
forms. An Imperative API handles more complex,
dynamic interactions requiring JavaScript execution through
navigator.modelContext.registerTool(). Together
they allow web pages to function as tool servers for AI agents,
running entirely client-side in the browser.
This collection of technical notes is organized as follows:
This document is entirely informative. It contains no normative requirements. The key words MAY, SHOULD, and MUST appearing in quoted text from the WebMCP specification retain their RFC 2119 meaning in that context only.
WebMCP (Web Model Context Protocol) is a proposed JavaScript API that allows web developers to expose 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. As the specification states: "Web pages that use WebMCP can be thought of as Model Context Protocol servers that implement tools in client-side script instead of on the backend." [[WEBMCP-SPEC]]
The specification proposes two APIs. A Declarative API handles
standard actions defined directly in HTML forms. An Imperative
API handles more complex, dynamic interactions requiring
JavaScript execution through
navigator.modelContext.registerTool().
[[WEBMCP-PROPOSAL]]
Critically, WebMCP is not the same thing as the Model Context
Protocol (MCP) [[MCP]], despite sharing a name fragment and
conceptual lineage. MCP is a backend protocol using JSON-RPC
for client-server communication, running on hosted servers,
and connecting AI platforms to external services without
requiring a browser. WebMCP is a frontend, browser-native
API running entirely client-side in JavaScript, using the
browser's postMessage system for communication,
and requiring an active browser session with a human user
present. The specification explicitly declares that headless
browsing, fully autonomous agents, and backend service
integration are out of scope.
The concept traces back to Alex Nahas, a backend engineer at Amazon. When MCP arrived in early 2025, Amazon deployed a large-scale MCP server with thousands of tools. The real problem, however, was authorization: MCP's specification had adopted OAuth 2.1, which internal services had not widely implemented. [[NAHAS-INTERVIEW]]
Nahas realized the browser itself could solve the auth problem — users are already signed in through federated browser sessions. He developed MCP-B (Model Context Protocol for Browsers), a Chrome extension that let websites expose MCP-compatible tools directly through browser JavaScript, using existing authentication and security models. The underlying protocol he called "WebMCP." [[NAHAS-MCP-B]] [[MCP-B]]
Independently, a separate early implementation by Jason McGhee also used the name "WebMCP" for a similar concept — a widget allowing any website to act as an MCP server client-side. McGhee has since deferred to the W3C version. [[MCGHEE-WEBMCP]]
On August 28, 2025, Patrick Brosset of the Microsoft Edge team published a blog post introducing WebMCP as "a proposal to let you, web developers, control how AI agents interact with your web pages," describing it as a joint effort between the Edge and Google teams. [[BROSSET-BLOG]]
In an interview, Kyle Pflug, group product manager for the web platform at Microsoft Edge, confirmed that WebMCP was a joint Microsoft-Google initiative. Pflug noted that Alex Nahas had joined the group, and that the priority for the rest of 2025 was "deeper conversations with web developers" and working toward "an early developer preview in Chromium." [[NEWSTACK-PFLUG]]
The specification was placed in the GitHub repository of the W3C Web Machine Learning Community Group. The draft is dated February 12, 2026 and lists three editors: Brandon Walderman (Microsoft), Khushal Sagar (Google), and Dominic Farolino (Google). [[WEBMCP-SPEC]]
The Web Machine Learning Community Group was originally proposed on October 3, 2018 by Anssi Kostiainen (Intel) to incubate the Web Neural Network API. It has since expanded its charter to include additional deliverables, now listing the "WebMCP API" as a specification deliverable described as "An API for web apps to expose their functionality as tools to AI agents and assistive technologies." [[WEBMCP-CHARTER]]
The CG participant lists include representatives from Google, Microsoft, Intel, Samsung, Apple, Huawei, and others. [[WEBML-CG]]
On February 10, 2026, Google's Andre Cipriani Bandarra
announced the WebMCP Early Preview Program. Access to the
preview is available in Chrome 146 Canary behind the
"WebMCP for testing" flag at chrome://flags.
Early benchmarks reported approximately 67% reduction in computational overhead compared to traditional visual agent-browser interactions. No other browser vendor has announced implementation timelines, though Microsoft's co-authorship suggests Edge support is probable.
The technical merits of WebMCP are not the concern raised here. The concern is procedural.
The specification is described as being incubated by a W3C Community Group. A CG draft carries a specific meaning in W3C process — it is a collaborative, community-driven document subject to group deliberation. Yet the Chrome team shipped a working implementation and launched a public developer program before the specification was mature. The spec contains multiple sections marked TODO. Open issues remain unresolved.
Members of the Web Machine Learning Community Group report learning about WebMCP from external press coverage rather than through the group's own communication channels. This raises the question of whether the CG incubation process served as genuine community deliberation or as a hosting arrangement for a specification driven primarily by two browser vendors.
Open Question: Will the W3C community group process catch up to the Chrome implementation, or will the implementation become the de facto standard regardless of community input?
| Date | Event |
|---|---|
| October 3, 2018 | Web Machine Learning CG proposed at W3C by Anssi Kostiainen (Intel) |
| Early 2025 | MCP gains adoption. Alex Nahas at Amazon encounters OAuth 2.1 authorization problems |
| 2025 | Alex Nahas develops MCP-B Chrome extension; Jason McGhee independently develops early WebMCP widget |
| August 28, 2025 | Patrick Brosset (Microsoft Edge) publishes blog introducing WebMCP as joint Edge-Google proposal |
| Sep–Oct 2025 | Kyle Pflug (Microsoft Edge) confirms joint initiative. Specification placed in webmachinelearning GitHub org |
| Oct–Nov 2025 | Open issues filed on webmachinelearning/webmcp repo by spec editors |
| November 2025 | WebMCP discussed at W3C TPAC 2025 in Kobe, Japan |
| December 12, 2025 | Last recorded update to webmcp repo on GitHub |
| February 10, 2026 | Google launches WebMCP Early Preview Program in Chrome 146 Canary |
| February 12, 2026 | WebMCP specification dated as Draft Community Group Report |
WebMCP allows a website to declare a set of tools — JavaScript functions with structured schemas and natural language descriptions — that AI agents can discover and invoke. The specification targets several categories of use.
E-commerce and transactional sites. A travel
booking site could register tools like
searchFlights(origin, destination, dates),
filterResults(price, stops, airline), and
bookFlight(flightId, passengerDetails). Instead
of an AI agent parsing a complex search interface by reading
pixels or DOM elements, it calls the function directly and
gets structured JSON back.
Productivity and SaaS applications. A project
management tool could expose
createTask(title, assignee, dueDate),
moveCard(cardId, column), and
generateReport(dateRange). Browser-based AI
assistants could help users manage workflows without the
application needing a separate backend MCP server.
Content and media. News sites, mapping services, and other content platforms could register structured search and retrieval tools.
Accessibility. The specification claims WebMCP could benefit assistive technologies by providing structured, semantically meaningful interfaces to website functionality. A screen reader enhanced with agent capabilities could invoke tools directly rather than navigating complex visual layouts. This is a strong claim that deserves rigorous testing.
Form automation and multi-step workflows. Complex processes like insurance applications, government forms, or account setup flows could be exposed as sequences of tool calls, allowing agents to guide users step by step while the site maintains control over validation and data handling.
Reliability. Today's browser agents — whether using visual parsing or DOM inspection — are brittle. A minor CSS change can break a visual agent. WebMCP tools are explicit contracts: the site declares what is available, the agent calls it, the response is structured.
Performance. Visual agents must capture screenshots, send them to a vision model, interpret the response, and generate coordinates. Early benchmarks reported a 67% reduction in computational overhead with WebMCP. Even if optimistic, the architectural advantage is clear.
Developer control. With visual or DOM-based agents, the website has no say in how an agent interacts with it. With WebMCP, the developer explicitly defines the interaction surface, including rate limits, validation, and structured error messages.
Authentication reuse. Because WebMCP runs in the browser session, it inherits whatever authentication the user already has. No OAuth flows, no API keys, no separate credential management.
Standardization. A developer implements tools once and every conformant agent can use them — the "USB-C" argument: one interface, many devices.
The risks identified below are significant, and several are not yet adequately addressed in the specification.
Prompt injection is the most acute risk. WebMCP tools return data to AI agents that then process it in their language model context. A malicious or compromised website could craft tool responses that manipulate the agent's behavior. The specification does not currently define a defense beyond same-origin policy boundaries.
Scope creep of agent permissions. WebMCP is designed for human-in-the-loop workflows, with headless browsing explicitly out of scope. But the technical mechanism does not inherently enforce this. The specification SHOULD define what "human in the loop" means technically, not just philosophically.
Consent and transparency. When a user visits a site that registers WebMCP tools, the current design provides no visible indicator. Compare this to camera, microphone, and location permissions, where the user explicitly grants access.
Competitive dynamics. WebMCP gives first-mover advantage to sites that implement tools early. Smaller sites that do not implement WebMCP may become invisible to agent-mediated browsing.
Data leakage through tool schemas. The natural language descriptions and parameter schemas reveal information about a site's internal architecture and business logic. The specification does not address whether tool schemas should be treated as sensitive information.
Abuse and rate limiting. Agents can invoke tools at machine speed. The specification mentions rate limiting as a consideration but does not define a standard mechanism.
Cross-site tool chaining. If an agent can invoke tools on multiple open tabs, it could chain actions across sites in ways no individual site anticipated. The security boundaries for cross-site tool interaction are not yet defined.
For those with access to Chrome 146 Canary, the following areas need community evaluation. Each SHOULD generate feedback for the W3C community group.
Declarative API with real HTML forms. Register tools that wrap existing form actions and verify that validation, error handling, and submission behavior match what a human user would experience. Try edge cases: forms with CAPTCHAs, multi-step forms, session state.
Imperative API with dynamic content. Register tools that interact with JavaScript-heavy applications. Evaluate whether tool calls can reliably interact with application state.
Authentication boundaries. Log into a site, register tools, then observe behavior when the session expires, the user logs out in another tab, or cookies are cleared.
Tool discovery and enumeration. If multiple sites in different tabs register tools, how does the agent disambiguate? What happens with name collisions?
Accessibility integration. Evaluate whether WebMCP tools provide genuinely better access than existing ARIA roles and landmarks. Test with screen readers, switch access devices, and voice control.
Prompt injection resilience. Craft tool responses containing instruction-like text and observe whether the consuming agent's behavior is affected. This is critical safety research.
Performance claims. Measure actual latency and token usage for equivalent tasks via WebMCP versus visual agent interaction.
Failure modes. What happens when a tool throws an error, returns unexpected types, hangs, or the page navigates away mid-call?
File a GitHub issue at github.com/webmachinelearning/webmcp/issues with a clear title, reproducible steps, and a specific recommendation.
Join the W3C Web Machine Learning Community Group at w3.org/community/webmachinelearning/. Community Groups are free and open.
If findings relate to security or privacy, file issues with clear severity assessments and request completion of the W3C security and privacy self-review questionnaire if not yet done.
A persistent claim in the WebMCP ecosystem is that WebMCP turns a website into an MCP server. The W3C specification repository itself states that web pages using WebMCP "can be thought of as Model Context Protocol servers that implement tools in client-side script instead of on the backend." [[WEBMCP-SPEC]]
Early independent implementations by Jason McGhee [[MCGHEE-WEBMCP]] and Alex Nahas (MCP-B) [[NAHAS-MCP-B]] literally did function as MCP servers, bridging browser JavaScript to MCP clients through localhost websocket connections. The framing is understandable. It is also architecturally misleading.
The Model Context Protocol [[MCP]] and WebMCP share a conceptual ancestor: both define "tools" as functions with natural language descriptions and structured schemas that AI agents can discover and invoke. That is where the meaningful similarity ends.
| Dimension | MCP (Backend Protocol) | WebMCP (Browser API) |
|---|---|---|
| Transport | JSON-RPC 2.0 over stdio, HTTP/SSE, or Streamable HTTP | Browser postMessage system |
| Execution context | Controlled backend: containers, VMs, serverless functions | Browser JavaScript engine, same context as the web page |
| Authentication | OAuth 2.1 or custom API key schemes | Inherited from browser session (cookies, federated login) |
| Trust direction | AI platform (client) connects to known, registered servers | Any website the user visits can register tools |
| Operational mode | Automated, headless, continuous, concurrent | Active browser tab, human user present, headless excluded |
| Human presence | Not required | Explicitly required |
When a developer hears "your website becomes an MCP server," they import a set of assumptions from the MCP architecture. Every one of these assumptions is wrong for WebMCP.
Transport. MCP uses JSON-RPC 2.0, a
well-specified request-response protocol. WebMCP uses
postMessage, the browser's cross-origin
communication mechanism. Code written for one transport does
not work with the other.
Execution context. An MCP server runs in a controlled backend environment. WebMCP tools run in the browser's JavaScript engine, subject to its security sandbox but also its constraints: single-threaded execution, same-origin policy, and the full surface area of client-side attack vectors.
Authentication. MCP uses OAuth 2.1. WebMCP inherits the browser session — elegant for usability but providing no protocol-level guarantees.
Trust direction. In MCP, the platform decides which servers to trust. In WebMCP, any visited website can register tools, and the current specification provides no visible indicator to the user.
Security reviewers who approach WebMCP as "MCP in the browser" will evaluate it against MCP's threat model — which assumes a controlled backend environment. WebMCP's actual threat model involves client-side JavaScript execution, browser-based trust boundaries, and web security concerns including cross-site scripting and prompt injection.
Developers may expect protocol-level interoperability — that WebMCP tool definitions could be used interchangeably with MCP server tool definitions. They cannot. The tool schema format may be similar, but the transport, discovery, and invocation mechanisms are incompatible.
Standards participants may underestimate the scope of new specification work required. WebMCP is not an adaptation of MCP to a new environment. It is a new browser API that borrows one concept (the tool abstraction) from MCP and implements everything else differently. It needs its own security review, privacy analysis, accessibility evaluation, and consent model.
WebMCP is a proposed browser API — specifically, a new
interface on navigator.modelContext — that allows
web pages to declare JavaScript functions as tools that
browser-based AI agents can discover and invoke. It uses the
browser's existing communication, security, and session
management infrastructure rather than introducing a new
protocol.
The design has real strengths. Authentication reuse eliminates one of the hardest problems in AI-service integration. Client-side execution means no backend infrastructure is needed. The human-in-the-loop requirement provides a natural consent and oversight mechanism — if implemented correctly.
Suggested Clarification: The W3C specification and its README SHOULD explicitly state that WebMCP is not an implementation of the Model Context Protocol and does not use the MCP wire protocol. It borrows the "tool" abstraction but implements discovery, registration, invocation, and communication through browser-native mechanisms that are architecturally distinct from MCP.
None of this is an argument against WebMCP or against MCP. A company might maintain an MCP server for direct API integrations with AI platforms and simultaneously implement WebMCP tools on its consumer-facing website for browser-based agent interaction. The two are complementary, not competing, and not identical. Recognizing the distinction is necessary for evaluating each on its own merits.
When an AI agent wants to interact with a website — book a flight, fill a form, check a price — it currently has two options: screen scraping (fragile, slow, breaks on layout changes) or backend API (requires server engineering). WebMCP is a third option: the website itself tells the agent what it can do, directly in the browser.
WebMCP makes any website into an AI-friendly service with no backend needed. The website's existing JavaScript code does the work. The AI agent just needs to know what tools are available.
| Actor | Role |
|---|---|
| Agent | An autonomous AI assistant (e.g., Claude, ChatGPT, Gemini) that calls the tools websites expose |
| Browser's Agent | An agent built into the browser itself (e.g., Chrome's built-in AI assistant) |
| Web Developer | The person who builds the website and registers WebMCP tools |
| User | The human at the browser. WebMCP is designed for "user-present" interactions |
| What | Where It Runs | What It Does |
|---|---|---|
| MCP | On a server (backend) | The original protocol. Applications expose tools to AI models through a backend server. [[MCP]] |
| WebMCP | In the browser (frontend) | Adapts MCP concepts for the web. Websites expose tools through JavaScript. No backend needed. [[WEBMCP-SPEC]] |
| MCP-B | Browser extension + JS library | A bridge / polyfill. Makes navigator.modelContext work today before browsers add native support. [[MCP-B]] |
The entry point is navigator.modelContext, a
new property on the browser's navigator object
(alongside existing features like
navigator.geolocation). It provides four methods:
provideContext(options) — registers a complete
set of tools at once, replacing any previous registrations.
clearContext() — removes all registered tools.
registerTool(tool) — adds a single tool to
the existing set without removing others.
unregisterTool(name) — removes one specific
tool by name.
Every registered tool has these parts:
name — a unique identifier (e.g.,
"searchProducts"). The agent uses this to
call the tool.
description — natural language explanation
of what the tool does, written for AI consumption.
inputSchema — a JSON Schema describing
expected inputs.
execute — the JavaScript function that runs
when the agent invokes the tool.
annotations (optional) — metadata such as
readOnlyHint: true to indicate the tool only
reads data.
// Register a tool that searches products on an e-commerce site
navigator.modelContext.registerTool({
name: 'searchProducts',
description: 'Search for products by keyword, category, or price range',
inputSchema: {
type: 'object',
properties: {
query: { type: 'string', description: 'Search keywords' },
maxPrice: { type: 'number', description: 'Maximum price filter' }
},
required: ['query']
},
annotations: { readOnlyHint: true },
async execute(input, client) {
const results = await searchAPI(input.query, input.maxPrice);
return { products: results };
}
});
When an agent calls a tool, the execute
function receives a client object with a
requestUserInteraction() method. This pauses
execution and asks the user for confirmation before
proceeding with consequential actions — the human-in-the-loop
mechanism.
WebMCP security rests on three layers:
origin isolation (each site's tools are
sandboxed to its own origin),
HTTPS requirement (SecureContext
— no WebMCP on unencrypted HTTP), and
user-present design (human in the loop via
requestUserInteraction()).
Currently, any website can register any number of tools the moment a user visits it. An AI agent can immediately discover those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"
| Browser Capability | Permission Model |
|---|---|
| Camera / Microphone | Browser prompts: "Allow / Block" |
| Location (GPS) | Browser prompts: "Allow / Block" |
| Notifications | Browser prompts: "Allow / Block" |
| WebMCP tools | Currently: no prompt. Tools are silently registered and discoverable. |
Open Question: Does the spec team envision a permission layer for tool discovery, or is the intended architecture that the AI client handles this at its own level? Both approaches are valid — the intended design matters for implementers and for user trust.
| Term | Plain Language |
|---|---|
| API | Rules for how software talks to other software. WebMCP is an API defining how websites talk to AI agents. |
| Client-side / Frontend | Code that runs in the user's browser. WebMCP tools run client-side. |
| DOM | The browser's internal representation of a web page. |
| JSON Schema | A standard way to describe the shape of data. Tools use it to declare expected inputs. |
| Navigator | A built-in browser object for browser features. WebMCP adds navigator.modelContext. |
| Origin | A website's identity: protocol + domain + port. The foundation of web security and WebMCP security. |
| Polyfill | Temporary code providing a feature before browsers add native support. MCP-B is a polyfill for WebMCP. |
| Promise | A way to handle asynchronous operations. Tool execute functions return Promises. |
| SecureContext | Means the feature only works on HTTPS pages. A security requirement for WebMCP. |
| Tool Poisoning | A security attack where malicious tools use misleading descriptions to trick agents. |
| Transport | The mechanism for sending messages. MCP uses JSON-RPC; WebMCP uses browser postMessage. |
| WebIDL | The formal language used to write web API specifications — the blueprint language for browser APIs. |
| Wire Protocol | The format of messages between systems. MCP-B translates between WebMCP's browser format and MCP's wire protocol. |
Join the W3C Web Machine Learning Community Group. W3C Community Groups are open to all. No W3C Membership is required and there is no fee. Join at: w3.org/community/webmachinelearning/
File issues and contribute via GitHub. The spec repo is at: github.com/webmachinelearning/webmcp
Test the Chrome implementation. The early
preview is available in Chrome 146 Canary by enabling the
"WebMCP for testing" flag at chrome://flags.
Engage with the AI Agent Protocol Community Group. The WebML CG charter identifies coordination with this separate CG for agent interoperability concerns.
| Resource | URL |
|---|---|
| WebMCP Specification | webmachinelearning.github.io/webmcp/ |
| WebMCP Proposal / Explainer | github.com/webmachinelearning/webmcp/.../proposal.md |
| WebMCP GitHub Repo | github.com/webmachinelearning/webmcp |
| Open Issues | github.com/webmachinelearning/webmcp/issues |
| WebML CG Charter | webmachinelearning.github.io/charter/ |
| WebML CG Home | w3.org/community/webmachinelearning/ |
| MCP-B Documentation | docs.mcp-b.ai/introduction |
| WebMCP-org GitHub | github.com/WebMCP-org |