The State of WebMCP: July 2026 · Spronta

⌘K Sign in Start free

← Blog Research<br>The State of WebMCP: July 2026<br>July 23, 2026<br>· by Sean Ryan<br>WebMCP in July 2026 is a standard with everything except users. The spec has Google and Microsoft engineers as editors, a live origin trial in Chrome, a Lighthouse audit category waiting for it, and a draft the editors updated two days ago. It also has close to zero deployment on real websites, and not one mainstream AI agent that calls the tools.

This is a long read, so settle in. We’ve pulled together the spec history, browser status, agent support, measured adoption, the ecosystem around the standard, and what we think you should do while that gap stays open. Every claim links to its source, and the full list sits at the end.

The short version

WebMCP lets a web page register typed JavaScript functions that browser AI agents can call, instead of forcing agents to scrape the DOM or click around with computer vision.

The spec is a W3C Community Group draft co-edited by Google and Microsoft. It isn’t on the standards track yet.

Chrome is running a public origin trial from Chrome 149 through 156. Edge ships support behind a flag. Firefox and Safari are watching.

Site adoption is close to zero, and no mainstream agent consumes the tools yet. Google says Gemini in Chrome will be the first.

The API moved from navigator.modelContext to document.modelContext in the 21 July spec draft, and Chrome 150 deprecates the old location. Early adopters already carry migration debt.

Lighthouse gained agentic-browsing audits in May. They sit at “Not Applicable” on most sites today, which is why the next twelve months are the window.

What WebMCP is

An AI agent that wants to book a table on your site today has two options. It can parse your DOM and guess which button does what, or it can take screenshots and click coordinates. Both are slow, brittle and expensive, and both break the day you ship a redesign.

WebMCP gives the page a third option: tell the agent what it can do. A site registers tools in JavaScript, each with a name, a natural-language description and a JSON schema for inputs. The browser exposes those tools to whatever agent is driving, the agent calls them like functions, and your existing frontend code does the work.

const modelContext = document.modelContext ?? navigator.modelContext;

await modelContext.registerTool({<br>name: "search-products",<br>description: "Search the product catalogue and return matching items",<br>inputSchema: {<br>type: "object",<br>properties: {<br>query: { type: "string", description: "Search phrase" },<br>maxResults: { type: "number" }<br>},<br>required: ["query"]<br>},<br>execute: async ({ query, maxResults = 10 }) => {<br>const results = await searchCatalogue(query, maxResults);<br>return { content: [{ type: "text", text: JSON.stringify(results) }] };<br>});<br>You’ll need that feature-detection line at the top. The spec moved the API from navigator to document to reflect that tools belong to a specific page, and Chrome deprecated navigator.modelContext in Chrome 150 while the origin trial still ships it. Framework maintainers are mid-migration; Angular has an open issue tracking the move. If you’re implementing this month, you’re writing the fallback.

Three design decisions matter more than the syntax:

The browser is the middleman. The page never speaks MCP directly. As Microsoft’s Patrick Brosset clarified, WebMCP borrows only MCP’s tool primitives; the browser handles protocol and transport.

Tools run in the page, as the user. An agent calling your tools inherits the logged-in session, which is what makes them useful and what makes them dangerous. More on that below.

A declarative variant is coming for forms. The explainer describes HTML attributes that annotate existing forms so agents can fill them without custom JavaScript. The spec section for it is still marked TODO, but Lighthouse already audits the attributes, which tells you where Google expects this to land.

How we got here

WebMCP has two parents. The scrappy one is MCP-B, Alex Nahas’s 2025 open-source project that put MCP servers inside the browser tab and proved sites could expose tools to extensions. The institutional one arrived on 28 August 2025, when Patrick Brosset proposed WebMCP from the Microsoft Edge team, and Google joined as co-author shortly after.

From there the standard moved at browser-vendor speed, which for once was fast:

DateEvent28 Aug 2025Microsoft proposes WebMCP; Google co-authors the explainer10 Feb 2026First W3C Draft Community Group Report; Chrome 146 Canary ships a preview behind a flag20 Mar 2026Third-party validator tooling appears in the Chrome Web Store~May 2026Lighthouse adds agentic-browsing audits18–19 May 2026Google I/O: public origin trial announced, running Chrome 149 through 156Jun 2026Edge 147 ships experimental support behind a flag21 Jul 2026Spec draft moves the API to document.modelContext; Chrome 150 deprecates the navigator location<br>The editors today are...