Draft:WebMCP

• Comment: If the sources are accessible, please link them. Greenman (talk) 22:55, 21 June 2026 (UTC)

---

The Web Model Context Protocol (WebMCP) is a proposed web standard and browser API that allows a web page to expose its functionality to artificial intelligence (AI) agents as structured, callable "tools", instead of requiring an agent to infer how the page works by scraping its DOM or analysing screenshots. It was developed jointly by engineers at Google and Microsoft and is incubated in the World Wide Web Consortium (W3C) Web Machine Learning Community Group; it is not a ratified standard.

WebMCP applies the tool-calling concept of the Model Context Protocol (MCP) to the client side of the browser, and despite the name it does not use MCP's JSON-RPC transport. Google shipped an early preview in Chrome 146 in February 2026 and began a public origin trial in Chrome 149 in June 2026. Reception among other browser vendors has been mixed: WebKit has published a position of opposition, while Mozilla has proposed a neutral position.

Background

Before WebMCP, AI agents acting on web pages relied mainly on DOM parsing and simulated user input, or on passing screenshots to multimodal models and inferring where to click. Both approaches are brittle, because a layout change or a delayed asset can break an automation sequence, and both are costly, because each screenshot or DOM dump consumes a large share of a model's context window.

Microsoft's Edge team publicly introduced the joint proposal in August 2025, and the work moved into the W3C Web Machine Learning Community Group. Precursor work included MCP-B, a browser extension by Amazon engineer Alex Nahas that ran MCP inside the browser so that tool calls could reuse a user's existing single sign-on session; Nahas later joined the community group work. An unrelated 2025 preprint by D. Perera describes a different client-side proposal also styled "webMCP", which is sometimes conflated with the Google and Microsoft specification.

Architecture and implementation

WebMCP defines two API surfaces.

• Declarative API: developers annotate existing HTML forms with attributes such as toolname and tooldescription, and the browser derives a JSON Schema describing the form's inputs. Where a field has no explicit annotation, Chrome falls back to the associated <label> element and then to aria-description.
• Imperative API: developers register tools programmatically through the modelContext interface, supplying a name, a natural-language description, an input schema and an execute callback. Tools can be registered or removed as page state changes.

Because a tool call runs the page's own client-side logic and returns structured data, a single call can replace a long sequence of agent interactions; one early implementer of a polyfill for Chrome DevTools reported an approximately 90% reduction in token usage. The specification states that headless and fully autonomous scenarios are non-goals, and it is framed around cooperative, human-in-the-loop browsing.

The specification also sets budgets for tool metadata, including limits on the length of tool names, descriptions, parameter descriptions and tool output.

Browser implementation status

As of August 2026, WebMCP is progressing through Google Chrome's feature launch process and is tracked on the Chrome Platform Status dashboard.

Stage	Chrome milestone
Dev trial (behind chrome://flags)	Chrome 146 (February 2026)
Origin trial (opt-in for developers)	Chrome 149 to 156
Shipping (stable, on by default)	Chrome 157 (estimated)

The dev trial in Chrome 146 was announced in February 2026 and required enabling a flag. The origin trial, which allows sites to opt in without a flag, opened with Chrome 149 in June 2026. The shipping milestone is an estimate and is subject to change. No other browser engine has announced an implementation timeline.

Relationship to MCP

WebMCP is a complement to, rather than a replacement for, the Model Context Protocol. MCP is a server-side protocol that connects AI platforms to hosted services, whereas WebMCP runs entirely in the browser tab and inherits the user's existing session state and credentials. A single organisation may therefore operate a back-end MCP server for service-to-service automation while also exposing WebMCP tools on its consumer-facing site. Commentators have also contrasted WebMCP with Microsoft's server-side NLWeb project, which gives sites a natural-language interface from the back end.

Ecosystem and adoption

Following the Chrome 146 preview, developers began cataloguing WebMCP-enabled sites and tooling. The W3C Web Machine Learning Community Group maintains an "Awesome WebMCP" list on GitHub, and Google Chrome Labs maintains a parallel list of demos and implementations. Independent directories also emerged, including webmcp.com, which catalogs live websites exposing WebMCP tools and allows AI agents to discover site capabilities prior to navigation. The wider ecosystem includes polyfills and packages that translate WebMCP tool registrations into JSON-RPC for existing MCP clients.

Search marketing commentators have described WebMCP as a potential new discovery layer, comparable in role to structured data markup, and have advised site owners to plan for agent-driven traffic. Early interest has been strongest in sectors with multi-step workflows such as e-commerce and travel booking.

Reception and criticism

Browser vendor positions

In May 2026 the specification's authors requested formal positions from other browser projects. WebKit responded that it is opposed to the proposal. Reviewer Mike Wyrzykowski argued that where a site's actions are hard for an agent to use, the gap should be closed in shared platform layers such as HTML and ARIA, so that users, assistive technology and agents all benefit, rather than by adding a parallel agent-facing layer. He also argued that a typed schema constrains the shape of an argument but not the meaning an agent must infer, so brittleness moves from the DOM into tool descriptions, and that making agent-driven interaction separately addressable allows sites to give agents capabilities withheld from the human interface, or the reverse. The response further noted unresolved cross-origin security questions, the absence of a consent model for consequential actions, and a risk the specification itself describes as a pipeline from personalisation to fingerprinting.

Mozilla's reviewer, Benjamin VanderSloot, proposed a neutral position. He credited WebMCP with giving automated browsers a clear signal of available actions and relieving developers of designing one interface for both humans and agents, but warned that in an adversarial setting a site could advertise tools that do not match the human experience, in order to trap agents, deliver prompt injection invisible to users, or harvest data from tool inputs. He also called the name misleading, since no MCP is actually involved, and suggested that a name such as "Website Tool API" would be clearer.

The W3C Technical Architecture Group opened an early design review of the proposal, which as of August 2026 remains open and is labelled as lacking multi-stakeholder support.

Security and privacy

The specification's authors acknowledge that large language models are susceptible to indirect prompt injection and recommend annotation hints, including an untrustedContentHint for externally sourced payloads and a readOnlyHint for non-mutating operations, to help an agent decide when human confirmation is required.

Academic work has examined the resulting attack surface. A 2026 preprint by Lee and colleagues describes "mid-session tool injection", in which third-party scripts alter the set of tools visible to an agent during an active session, either by hijacking tool registration or by framing a tool's role through its metadata. The authors report working demonstrations against WebMCP and recommend binding tool identity to its origin, enforcing lifecycle consistency, isolating third-party tools and logging tool registration and invocation.

Implementation defects have also appeared. Google's Chrome 150 stable release in July 2026 patched CVE-2026-16806, a high-severity use-after-free vulnerability in WebMCP.

Accessibility

Writing in InfoWorld, Navya Agarwal argued that the accessibility tree already provides a machine-readable interface that solved discovery decades ago, and that WebMCP addresses the remaining gap of execution by describing what an action accepts and what it changes. He noted that the same HTML quality that accessibility requires is now the primary input to a site's agent tool contract, so component patterns that destroy semantics degrade both. Critics have observed that the specification states it is not designed for consumption by assistive technology, which they argue risks a fork in which agents receive richer semantics than screen-reader users.

See also

• Model Context Protocol
• Agent2Agent
• Semantic Web
• World Wide Web Consortium