WebMCP Browser Support Tracker

WebMCP is moving fast, and support status is one of the most frequently asked — and fastest to go stale — questions about it. This page is meant to be checked, not just read once: bookmark it, and we'll keep it current as browsers ship new milestones. Below is the current state as of this writing, followed by what to watch for next.

Current support at a glance

Because this table describes a fast-moving early-preview feature, treat any specific version number you read — here or elsewhere — as a snapshot, not a permanent fact. Confirm against Chrome's own release notes before making a go/no-go decision for a production launch.

What "origin trial" actually means for you

An origin trial is Chrome's mechanism for shipping an experimental API to real production sites, under a registered token, before it's available to everyone by default. It's a meaningfully different state from a chrome://flags toggle:

• Flags are for local development and testing — they require the person visiting your site to manually enable the feature in their own browser, which makes them useless for anything you want a random visitor's agent to actually use.
• Origin trials let your specific registered domain serve the feature to any visitor using a supported browser version, without that visitor doing anything on their end. This is the mechanism that makes WebMCP usable in production ahead of general availability.
• General availability is the eventual end state, where the API works by default with no token and no flag, the same way fetch() or IntersectionObserver work today.

If you're planning a production WebMCP rollout rather than just experimenting, registering for the origin trial (not just flipping the local flag) is the step that actually matters.

What's not supported yet, even in Chrome

Early preview status means real functional gaps, not just "smaller browser reach." Worth knowing before you architect around WebMCP as if it were a finished, stable platform feature:

• No headless mode. Every WebMCP tool call currently requires a visible browsing context — an actual open tab or webview. This has real implications if any part of your automation strategy assumed agent interactions could run server-side or in a headless browser instance; today, they can't.
• No standardized discoverability mechanism. There's currently no built-in way for an agent client to know a site supports WebMCP tools without first visiting it and checking. This is expected to be addressed as the spec matures, but isn't solved today — which is part of why publishing your tool support through other discoverable channels (structured data, a documented API) still matters even after you've implemented WebMCP tools.
• UI-sync is the developer's responsibility, not the platform's. WebMCP doesn't automatically keep your visible UI in sync with state changes triggered by an agent call — that's on your application code, and it's a common source of bugs in early implementations (see our implementation checklist for the specific pattern to use).

How to build without getting burned by the moving target

Feature-detect, always. Never assume navigator.modelContext exists. Every tool registration should be gated behind a check for the API's presence, both because most of your traffic today is on browsers without support, and because the shape of the API itself could still change before general availability.

Treat WebMCP as additive, not load-bearing. Every flow you build a WebMCP tool for should already work completely without it. This isn't just good practice generally — it's the only viable strategy given that most visitors, for the foreseeable near-term, will be on browsers with no support at all.

Watch the spec repository, not just blog posts. WebMCP is being developed as a W3C Web Machine Learning Community Group draft, with active multi-vendor editing from Google and Microsoft engineers. Blog posts (including this one) are useful for context, but the source of truth for exact API shape and browser milestones is the spec itself and each browser vendor's own release notes.

Have a plan for the divergence period. It's plausible that Chrome and Edge ship compatible-but-not-identical implementations during the early rollout, the way many web platform features have diverged slightly before full standardization. Build your tool registration layer as an abstraction (see the implementation checklist) so a future divergence doesn't mean rewriting every tool call across your app.

What would signal "safe to build on by default"

A few concrete milestones to watch for, any of which would materially change the calculus on when to invest more heavily:

• General availability in Chrome stable, without a flag or origin trial token required
• A committed Edge ship date with an actual version number, not just "expected to follow"
• A public statement of intent from Firefox or Safari — even a non-committal "under consideration" changes the standardization outlook meaningfully, since two-engine support (Chromium-only) versus three-plus-engine support is the usual bar the web platform community uses to judge whether a feature is safe to build a core experience around
• W3C progression beyond Community Group Report toward a standards-track document

None of these have happened as of this writing. That doesn't mean don't build — early, well-scoped WebMCP implementations on your highest-value flows are a legitimate competitive move right now, precisely because most competitors haven't started. It means build with the explicit assumption that the ground will keep shifting under you for a while.

Check where you stand

Browser support tells you where the ecosystem is. Your own implementation tells you where you are. Run a free Agent Readiness scan to see whether your site's current WebMCP tools — if you have any — are correctly structured and discoverable given today's support landscape.

*This tracker is reviewed and updated as browser vendors ship new milestones. If you spot outdated information here, let us know.*