Start free
← Blog

Research

The State of WebMCP: July 2026

· by

A web page exposing three typed tools to a browser AI agent, illustrating the WebMCP protocol

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

  1. 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.
  2. The spec is a W3C Community Group draft co-edited by Google and Microsoft. It isn’t on the standards track yet.
  3. Chrome is running a public origin trial from Chrome 149 through 156. Edge ships support behind a flag. Firefox and Safari are watching.
  4. Site adoption is close to zero, and no mainstream agent consumes the tools yet. Google says Gemini in Chrome will be the first.
  5. 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.
  6. 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({
  name: "search-products",
  description: "Search the product catalogue and return matching items",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Search phrase" },
      maxResults: { type: "number" }
    },
    required: ["query"]
  },
  execute: async ({ query, maxResults = 10 }) => {
    const results = await searchCatalogue(query, maxResults);
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
});

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

Timeline of WebMCP from the MCP-B prototype in mid-2025 to the July 2026 spec draft

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:

DateEvent
28 Aug 2025Microsoft proposes WebMCP; Google co-authors the explainer
10 Feb 2026First W3C Draft Community Group Report; Chrome 146 Canary ships a preview behind a flag
20 Mar 2026Third-party validator tooling appears in the Chrome Web Store
~May 2026Lighthouse adds agentic-browsing audits
18–19 May 2026Google I/O: public origin trial announced, running Chrome 149 through 156
Jun 2026Edge 147 ships experimental support behind a flag
21 Jul 2026Spec draft moves the API to document.modelContext; Chrome 150 deprecates the navigator location

The editors today are Brandon Walderman (Microsoft), Khushal Sagar and Dominic Farolino (Google). Anthropic created MCP itself and hasn’t said anything public about WebMCP in the eleven months since the proposal appeared.

Supply and demand, out of sync

A protocol needs two sides. Sites must register tools, and agents must call them. In July 2026 the supply side is warming up while the demand side hasn’t arrived.

Supply side versus demand side: browsers shipping WebMCP against agents that actually call the tools

Browsers are ahead. Chrome’s origin trial means any site can register a token and expose tools on production traffic today. Edge’s support sits behind a flag, and Microsoft co-authoring the spec makes deeper Edge integration a matter of when. Firefox and Safari sit in the discussion threads without commitments, which matters less than it sounds while the consuming agents are all Chromium-adjacent anyway.

Agents are behind. As of the most recent independent audit in May, no mainstream agent client calls modelContext tools. Claude, ChatGPT Agent, Perplexity and Gemini all still read pages the old way. Google says Gemini in Chrome will consume WebMCP tools, and when it ships it’ll be the first mainstream consumer and the reference implementation for everyone else.

Compare the server-side protocol it borrows from. MCP proper is thriving: roughly 97 million monthly SDK downloads, thousands of servers, and a specification release candidate due 28 July. Buyers already pay for agent-to-tool infrastructure at scale; the browser leg is the part still waiting for proof.

Adoption, measured honestly

No vendor or analyst publishes a measured adoption number, so writers reach for “approximately zero” and they’re right. freeCodeCamp titled its implementation guide “Shipping a 0% Adoption Standard”.

What exists today:

  • Named pilots. At I/O, Google listed Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart and Target as origin-trial participants. Logos of that size signal intent. Deployment is a separate step none of them has confirmed.
  • A checker cottage industry. webmcp-checker.com launched within days of the Chrome 146 preview, a 19-point validator extension followed in March, and at least three more single-page checkers ship the same audit. Checker tools now outnumber known implementations.
  • Serious libraries, thin platforms. The WebMCP-org npm packages (@mcp-b/react-webmcp, @mcp-b/global, transports) descend from the MCP-B work and are maintained. React hooks from MCPCat track the spec. CMS-level support is weaker: one widely promoted WordPress plugin’s product page now redirects to a domain listed for sale at $32,000.
  • Our own crawls agree. We’re wiring WebMCP detection into Spronta’s rendered crawls, and across the sites we’ve checked so far, registered tools round to zero outside demos and the checker sites themselves. We’ll publish proper numbers from the crawl corpus as a running adoption index.

Every published projection puts on-by-default Chrome in late 2026 and meaningful adoption in 2027. Standards with a two-sided bootstrapping problem wait for a default to flip, and Google controls both sides of this one.

Lighthouse is the quiet forcing function

Since May, Lighthouse ships an agentic-browsing category with three WebMCP audits, and most SEO teams haven’t noticed.

AuditWhat it checksToday
webmcp-registered-toolsInventory of tools the page exposesInformational
webmcp-form-coverageForms missing declarative tool attributesInformational, expected to become a warning
webmcp-schema-validityMalformed tool schemas and unnamed inputsCan fail

On a site with no WebMCP the audits report “Not Applicable” and cost you nothing today. SEO teams treat Lighthouse as a to-do list, though, so the day form-coverage turns into a warning, “add WebMCP attributes to our forms” lands in a thousand sprint backlogs at once. You can do that work on your own schedule this year, or in the scramble after the audit flips.

Security is the sleeper issue

WebMCP tools execute in the page with the user’s session. The spec gates access behind a permissions policy and secure contexts, added requestUserInteraction() so tools can force a human confirmation, and Chrome publishes tool security guidance. Those gates cover the browser’s side of the problem, and none of them stops a deceived model from calling a legitimate tool.

A WebMCP tool hands an intent-level API to a language model that reads untrusted content. Practitioners who’ve implemented WebMCP write about the attack surface in familiar terms: prompt-injected agents calling real tools with real session state, tool descriptions that lie to the model, and confused-deputy chains across sites, since agents can carry context from one tab into another.

The practical rules are the ones API designers already know. Expose the narrowest tools you can, require confirmation on anything with side effects, never trust tool inputs, and log every call. Treat “add to basket” differently from “change shipping address”. A WebMCP tool is a public endpoint; review it like one.

What changed in July, specifically

Posts like this age fast, so the July-specific facts, dated:

  1. 21 July: the spec draft relocated the API to document.modelContext. Chrome 150 deprecates navigator.modelContext; the origin trial still serves it. Tutorials published before July show the deprecated form.
  2. 28 July: the upstream MCP spec cuts a release candidate, the protocol’s first RC process. WebMCP’s primitives track MCP, so churn upstream reaches the browser eventually.
  3. Ongoing: the Chrome 149–156 origin trial window keeps ticking. Trials end; this one closes around the same time analysts project stable-channel enablement, late 2026.
  4. Still missing: any announcement of a shipped mainstream agent that calls the tools. Watch for the Gemini-in-Chrome ship date; that announcement resets every timeline in this post.

What you should do about it

We run a crawler for a living, so our bias is measurement first. With that disclosed:

The agent-ready stack: readable content, queryable data, actionable tools

Think in three layers. Agent readiness is a stack, and WebMCP is only the top of it. The base is readable: clean markup, working llms.txt, content that survives without JavaScript, no accidental bot blocks. The middle is queryable: structured data an agent can fetch without parsing your marketing pages, whether that’s a hosted MCP server or clean feeds. The top is actionable: WebMCP tools for search, forms and transactions.

If agent traffic already converts for you, join the origin trial now. Ship one or two tools where structure beats scraping by the widest margin: site search, availability lookups, a lead form. Write the document.modelContext fallback, keep schemas boring, and put a human confirmation on anything that spends money.

If you run a normal B2B marketing site, you’ve got a year of runway and no reason to waste it rebuilding. Spend it on the boring layers: fix what blocks agents today, annotate your forms when the declarative spec lands, and re-run Lighthouse each Chrome release so the audit flip never surprises you. We’re adding these checks to Spronta’s crawls so a report can answer “are we agent-ready”.

Either way, instrument. The question worth answering this year: when agents show up, will you see them? Bot analytics, server logs and crawl monitoring answer it. The teams that measured AI crawler traffic in 2024 caught the citation wave early, and the same move is available here for the cost of a log query.

Where this goes

Our read, hedged where honesty requires it: WebMCP graduates from origin trial to Chrome stable within a couple of releases of Gemini in Chrome consuming tools, because Google controls both sides of that handshake and has no reason to ship them apart. Publisher adoption follows the first public case study where registered tools moved a conversion metric, and travel or commerce produces it, because those pilots are already running. Anthropic and OpenAI wait until the trial proves out; reading a page’s declared tools costs less than screenshotting it, so their support will land in a changelog rather than a keynote.

The counter-scenario deserves respect too: origin trials do die. If Gemini integration slips into 2027, publishers get no reason to register tools, the audits stay “Not Applicable”, and WebMCP joins Web Intents in the museum of browser APIs that arrived before their users. The difference this time is that the consuming agent and the browser share an owner. We wouldn’t bet against a protocol whose bootstrapping problem is one company’s internal roadmap.

Zero adoption, a live origin trial and an audit category waiting in Lighthouse add up to a window that closes when Gemini in Chrome ships. Spend it on the layers agents already read.

Sources and further reading

Frequently asked questions

What is WebMCP?

WebMCP (Web Model Context Protocol) is a proposed web standard that lets a page register typed JavaScript tools which browser AI agents can call directly, instead of scraping the DOM or driving the page with computer vision. A site describes each tool with a name, a natural-language description and a JSON schema, and the browser exposes those tools to the agent.

Is WebMCP a W3C standard?

No. WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, edited by engineers from Google and Microsoft. It isn't on the W3C standards track, and the API surface is still changing between drafts.

Which browsers support WebMCP in July 2026?

Chrome runs a public origin trial from Chrome 149 to Chrome 156, so sites can test WebMCP on production traffic. Edge ships experimental support behind a flag. Firefox and Safari participate in spec discussions but haven't committed to implementation.

Do any AI agents use WebMCP today?

No mainstream agent calls WebMCP tools yet. Claude, ChatGPT Agent, Perplexity and Gemini still read pages through the DOM or screenshots. Google says Gemini in Chrome will consume WebMCP tools, which would make it the first mainstream client.

What is the difference between WebMCP and MCP?

MCP is a client-server protocol for connecting AI applications to external tools, and it's widely adopted. WebMCP borrows MCP's tool primitives but runs inside the browser: the page registers tools in JavaScript and the browser handles protocol and transport. A site can offer both a hosted MCP server for headless agents and WebMCP tools for agents that browse.

Should I add WebMCP to my website now?

Measure before you build. Join the origin trial if agent traffic already matters to your business, start with one or two high-value tools such as search or a lead form, and treat every tool as a security boundary. For most sites the near-term win is making content readable and queryable for agents, then adding WebMCP tools as consuming agents ship.