The State of WebMCP

Where the spec stands

Google shipped document.modelContext as a public origin trial starting in Chrome 149 (May 2026), running through Chrome 156. Microsoft runs its own origin trial in Edge, starting with Edge 150 and ending November 17, 2026, and announced in September that its implementation is ready for testing. That's the only place the native API exists today, everywhere else the community WebMCP polyfill fills the gap by reimplementing the same interface in JavaScript.

The spec itself kept moving over the summer. Tools can now carry annotations that tell an agent how careful to be (readOnlyHint, consequentialHint, untrustedContentHint, and a debugging flag for developer tools). The declarative API, which turns an ordinary <form> into a tool with a few attributes, works in Chrome. And from Chrome 156 the toolactivated and toolcancel events fire on document.modelContext instead of window, so code listening for them needs to check both.

An origin trial is explicitly experimental: Chrome can extend it, ship it as a standard permanent feature, change the API shape, or drop it, and has done all four with other origin trials in the past. Building on the polyfill today means your tools work everywhere regardless of which of those happens.

Full browser-by-browser breakdown →

The ecosystem so far

The polyfill

The mcp-b/webmcp polyfill is the de facto compatibility layer right now, it's what makes WebMCP usable on non-Chrome browsers and pre-149 Chrome today instead of waiting on the trial.

Lighthouse scoring

Lighthouse 13.4's agentic-browsing category gives site owners a concrete, automatable way to check WebMCP compliance, six equally-weighted audits covering tool registration, schema validity, form coverage, accessibility tree structure, layout stability, and llms.txt.

Managed tooling

Platforms like Aigentably exist because hand-writing registerTool() calls, schema validation, origin scoping, and cross-browser fallbacks for every page of a site is real work. Expect more tooling here as adoption grows, not less.

Where the other browsers stand

Safari (WebKit): opposed

WebKit closed its standards-position review with a formal "oppose", flagging concerns from API design and duplication to privacy, security and use cases. Native WebMCP in Safari is not coming any time soon.

Firefox (Mozilla): neutral

Mozilla closed its standards-position review as neutral: not against it, not committing to it. No implementation has been announced.

Edge: its own origin trial

Edge runs its own trial from Edge 150 until November 17, 2026, separate from Chrome's, with samples in Microsoft's webmcp-labs repository. Microsoft also co-edits the spec.

Adoption and security, so far

Announcements have run well ahead of deployment. Spronta's July 2026 look at the ecosystem found that registered tools "round to zero outside demos and the checker sites themselves", and noted that no vendor or analyst publishes a measured adoption number yet. That is the honest baseline: a site that ships tools now is early, not late.

Security research has started too. A June 2026 paper, WebMCP Tool Surface Poisoning, shows how a third-party script on a page can hijack or reframe tools while an agent is using them. And in July Google fixed CVE-2026-16806, a high-severity use-after-free in Chrome's WebMCP implementation (fixed in 150.0.7871.186). Neither is a reason to wait, but both are reasons to treat tools as security-relevant surface. What this means for your site →

What's still genuinely open

Being direct about what we don't know matters more here than pretending certainty:

• Does the origin trial graduate? Origin trials are trials. Chrome hasn't committed to shipping WebMCP as a permanent, unflagged API past Chrome 156.
• Does it ever reach Safari and Firefox? WebKit opposes it and Mozilla is neutral, so neither has committed to implementing document.modelContext natively. The polyfill is doing that work in the meantime, indefinitely if native support never arrives there.
• Does it become a ranking signal? Core Web Vitals followed the pattern of "Google measures it, then it starts to matter for visibility." Lighthouse now measures agentic browsing. Whether that pattern repeats is a bet, not a fact.
• Which AI agents actually query it in production? An agent has to check document.modelContext for it to matter at all. Agent vendors' own adoption timelines are largely undisclosed.
• Who gets to see a page's tools? The spec still leaves open how far tools should be exposed across frames and to which agents. The runtime attacks above make that question more pressing, not less.

What to do about it now

You don't need to wait for these questions to resolve. The polyfill means tools you register today work in every major browser right now, native support in Chrome/Edge is a bonus, not a prerequisite. If the origin trial doesn't graduate or other vendors never adopt it, you've lost nothing, the polyfill keeps working. If it does become the standard, you're already there.

The practical first step is small: pick two or three actions on your site an agent would plausibly want to take, e.g. searching, adding to cart, checking status, and expose them as WebMCP tools. See what happens.

Related reading