BridgeToAgent
Get the kit — $49
All posts
Announcement6 min read

WebMCP Origin Trial — what Chrome 149 changes from the Chrome 146 preview

Google I/O 2026 promoted WebMCP from a Chrome 146 preview flag into a formal W3C-track Origin Trial in Chrome 149. Here's what shifted in the spec between February and May, what stayed the same, and which pieces of the existing kit advice still hold.

BridgeToAgentEditorial team

WebMCP Origin Trial in Chrome 149

At Google I/O on May 19, 2026, Chrome announced that the WebMCP API has been promoted from the preview flag it shipped behind in Chrome 146 into a formal Origin Trial in Chrome 149, on the W3C track.

That's a smaller-sounding sentence than the Chrome 146 announcement in February. It is not a smaller event. The promotion changes what the spec means legally, what site owners can rely on, and what "shipping WebMCP code" now looks like in production. Most of the existing API surface is unchanged — but the contract around it moved meaningfully.

If you read the Chrome 146 post and shipped against the preview, almost everything you wrote still works. If you held back because the preview felt fragile, the Origin Trial is the inflection that justifies revisiting that call. This post is the diff.

The 30-second version

What changed. Chrome 149 (announced May 19, 2026 at Google I/O) promoted WebMCP from a preview-flag implementation into a formal Origin Trial. The spec moved further onto the W3C track and the origin-trial mechanism now applies — sites register for a token, ship it via meta tag or HTTP header, and the API is available to their visitors without users having to enable a flag.

What stayed the same. The core navigator.modelContext API shape is unchanged from Chrome 146. registerTool, the JSON Schema contract, the handler pattern — all still valid. Code written against the preview continues to run.

What's still moving. Origin Trial is not stable spec. The trial window runs roughly two Chrome milestones; signatures and the broader tool-discovery surface are still candidates for revision before the unflagged-default ship.

What this means for BridgeToAgent. agent-instructions.md, agents.json, and llms.txt are unaffected. WebMCP remains an additive layer — the kit's plan for a webmcp.js snippet still stands and the API surface it generates against has not shifted.

From preview flag to Origin Trial — what the promotion actually means

Chrome 146 shipped navigator.modelContext behind a feature-flag preview. Visitors had to enable the flag in chrome://flags, or the site had to assume zero coverage for any user that hadn't. In practice, almost nobody ran the flag. The preview was real but audience-bounded — a developer-facing surface for early adopters, not a deployable production API.

The Origin Trial mechanism is qualitatively different. Per the announcement, sites that want to expose WebMCP to their visitors register at chromestatus.com, receive an origin-bound token, and ship the token to the browser via either:

  • A <meta http-equiv="origin-trial" content="TOKEN_HERE"> tag in the page <head>, or
  • An Origin-Trial: TOKEN_HERE HTTP response header

When Chrome 149+ sees a valid token for a registered origin, the API becomes available to every visitor on that origin without any flag-flipping on the user side. No DevTools setting. No chrome://flags toggle. The site opts in for everyone.

That's the substantive shift. Origin Trials are how Chrome ships in-flight web platform features to production sites with a formal feedback loop back to the spec working group. The trial window typically runs across two stable Chrome milestones, after which the feature either graduates to the default-on web platform or is revised and re-trialled. WebMCP in 149 has entered that cycle.

The W3C-track framing in the I/O announcement is the second half of the change. The Chrome team specifically positioned the trial as running in coordination with the W3C Web Machine Learning Working Group's review process, which is the formal path toward a Recommendation. The preview in 146 didn't carry that signal; the Origin Trial in 149 does.

What changed in the spec between February and May

Per the I/O announcement and the spec diff published alongside it, the changes from the Chrome 146 preview to the Chrome 149 Origin Trial are deliberately small. The Chrome team is signalling stability ahead of the formal trial, not a re-architecture.

The notable diffs:

  • Tool registration surface unchanged. registerTool keeps the same name / description / parameters / handler shape from the preview. JSON Schema remains the parameter contract.
  • Lifecycle hooks added. A new navigator.modelContext.list() surface lets the agent enumerate currently-registered tools, and an explicit unregisterTool(name) is now part of the spec rather than something callers had to handle by re-registering with empty handlers.
  • Permission model formalized. The preview implicitly granted agent access whenever a tool was registered. The Origin Trial introduces a permission field on tool registration with values in the area of auto / confirm / explicit, letting the page declare whether a given action requires user confirmation before the in-browser agent can invoke it. (We're describing the shape per the announcement — exact value strings should be verified against the live spec before shipping.)
  • Origin-Trial token requirement. Production sites must register and ship a token. The preview didn't require this.

What the announcement did not introduce, by design:

  • No new authentication surface beyond the existing browser security model
  • No change to the handler-execution model (same JS handlers, same page-context execution)
  • No change to the agent-side calling convention

If you wrote a registerTool({ name, description, parameters, handler }) call against Chrome 146, that call continues to run on Chrome 149 under the Origin Trial. You'll want to add the trial token and optionally the new permission field, but the existing call site is forward-compatible.

Origin-trial registration — the mechanics

For sites that want to opt in during the trial window:

  1. Visit chromestatus.com and locate the WebMCP Origin Trial listing (live as of the May 19 announcement).
  2. Register the origin you want to trial against. One origin per token; subdomains generally count as distinct origins.
  3. Receive an origin-bound token. The token encodes the origin and an expiry date inside the trial window.
  4. Ship the token via meta tag in the page <head> or via the Origin-Trial response header. Header is generally preferable if your stack supports it — it works for non-HTML responses and doesn't require touching every page template.
  5. When the trial ends, the token expires. If WebMCP graduates to default-on, no further work needed. If the trial is renewed or revised, sites re-register against the next-stage trial.

The trial is free and open. There's no allow-list and no application process beyond the public registration form. That's standard for Chrome Origin Trials.

The one operational note worth flagging: Origin Trials are not a replacement for the Chrome 146 preview flag. Both can coexist during the 149 window — the flag continues to work for developers testing locally, the trial token is what production sites use.

What's still moving — what not to commit to long-term

The Origin Trial is forward progress, not finality. A few things remain candidates for revision before WebMCP becomes a default-on web platform feature:

  • Permission-value strings are part of the new spec but were flagged in the announcement as one of the areas under active working-group review. Don't hardcode the exact strings in long-lived config — keep the layer thin enough that a rename is a one-line change.
  • Tool-discovery semantics beyond a single page (multi-page tool registration, persistent tools across navigation) are still in spec discussion. If you're tempted to build a "global tools" abstraction layer over registerTool, wait.
  • Cross-origin tool exposure (whether an iframe can register tools to the parent's agent) is intentionally out of scope for the 149 trial. Plan for first-party only during the trial window.
  • The permission field name itself may change. The announcement used it; final spec might land on policy or similar. Treat the exact name as a thin facade.

What you can commit to long-term: the navigator.modelContext namespace, the registerTool entry-point name, the JSON-Schema parameter contract, and the handler-runs-in-page-context execution model. The Chrome team and the W3C working group have signalled those four as stable across the trial.

What this means for the BridgeToAgent kit

The kit's plan from the Chrome 146 post still stands:

  • agents.json, llms.txt, and agent-instructions.md are unaffected by the trial promotion. They ship today, work in every browser, and continue to work in Chrome 149 with or without an Origin Trial token. They remain the right first-stage investment for any site.
  • The planned webmcp.js add-on (Kit 1.3) generates against the same registerTool surface that survived from 146 to 149. Adding origin-trial-token support is a one-line addition to the generated snippet, not a re-architecture.
  • The permission-field addition is the only meaningful new surface the kit would need to expose. Defaulting to confirm (or the trial's equivalent name) for any state-changing action and auto for pure reads is the conservative shape; the kit will likely surface this as a per-action toggle in the action editor.

If you bought the kit at any version, the existing files do not need regeneration because of the Chrome 149 announcement. Nothing in agents.json or agent-instructions.md changed. The WebMCP add-on remains the additive Kit 1.3 release and is still on the roadmap for the trial window.

The honest position remains the same as in February: ship the three sidecar files now, plan for WebMCP as additive, don't refactor anything to chase WebMCP, and revisit the snippet layer when the kit releases the generator.

What to do this week

  • Don't panic. Origin Trial != breaking change. Code written against the Chrome 146 preview keeps working under 149.
  • Decide whether to opt into the trial. If you already have WebMCP code shipping and a developer audience, registering at chromestatus.com and adding the token is a clean win — your visitors get the API without flag-flipping. If you don't have WebMCP code yet, the trial isn't urgent.
  • Don't refactor sidecar files. agents.json, llms.txt, agent-instructions.md are unaffected.
  • Bookmark the spec page. The W3C Web Machine Learning Working Group's WebMCP draft is where the next round of changes will land. Watch that, not the Chrome blog, for the substantive spec-side news.

The bigger picture from February still holds. WebMCP is an additive layer that compounds with the agentic-readiness work most sites need to do anyway. The Origin Trial is the milestone where the API becomes production-shippable; the unflagged-default ship is the one after that. We're between those two markers right now, and the kit plan accommodates both.

Related

Keep reading

All posts →