WebMCP shipped in Chrome 146 — what your site needs now
Chrome 146 turned WebMCP from a proposal into a live browser API. Edge followed in 147. Here's what changes for site owners in the next six months — and the one piece of work you should not ship yet.
WebMCP shipped in Chrome 146
Chrome 146 dropped on February 4, 2026 with a quiet line in the release notes:
An early preview of the WebMCP API is available behind
navigator.modelContextfor sites participating in the origin trial.
That single sentence flipped a switch the rest of the industry has been waiting for. WebMCP — a joint Google / Microsoft proposal at the W3C — is no longer a slide deck. It's a real browser API that an agent running in your Chrome can call right now. Edge followed with support in 147 (March 2026). Firefox is 8–12 weeks behind in the release cycle but has active commits.
If you sell anything online, you're now living inside a six-month window where the difference between "your site works with agentic browsing" and "your site doesn't" stopped being theoretical.
This post walks through what WebMCP actually does, why it's different from the agentic-readiness files you've already heard about, what the data says about the efficiency gain, and — most importantly — which pieces of it you should ship today versus which ones to wait on.
The 30-second version
What changed. Chrome and Edge now ship a browser-level API (
navigator.modelContext.registerTool) that lets a webpage declare typed, callable actions directly to whatever agent is driving the browser. No screenshot inference, no DOM scraping.Why it matters. Independent measurements show a ~89 % token reduction versus screenshot-based agent interaction. Latency drops by roughly the same amount. Reliability goes from "agent succeeds sometimes" to "agent succeeds deterministically."
What to do. Keep shipping
agents.json,llms.txt, andagent-instructions.md— those work in every browser today. Plan for WebMCP annotations as an add-on once your stack is ready, but don't refactor anything to chase a 12-week-old API.
Browser support, as of today
The table below is the part of this post worth bookmarking. Spec landed September 2025. Browsers have been racing ever since.
| Browser | Status | Version | Shipped |
|---|---|---|---|
| Chrome | ✅ Stable | 146 | Feb 4, 2026 |
| Edge | ✅ Stable | 147 | Mar 11, 2026 |
| Brave | ✅ Stable (Chromium 146 base) | 1.69 | Mar 2026 |
| Opera | ✅ Stable (Chromium 146 base) | 113 | Mar 2026 |
| Firefox | ⏳ In progress | — | Estimated Q3 2026 |
| Safari | ❌ No public commitment | — | TBD |
Chromium-based browsers are at 71 % global share (StatCounter, April 2026). Add Edge's 5 %. That's ~76 % of your visitors arriving in a browser that can speak WebMCP today, before Safari has even announced support.
2025 ──────────────────────────────────────────────── 2026
│
spec draft Chrome 146 │ Edge 147 Firefox? Safari?
Sep 2025 Feb 2026 │ Mar 2026 Q3 2026 —
──┬── ──┬── │ ──┬── ──┬── ──┬──
│ │ │ │ │ │
▼ proposal ▼ live ▼ ▼ live ▼ shipping ▼ unknown
│
you are here
What WebMCP actually is
Most existing AI-readiness work is sidecar — a file at the root of
your domain that the agent fetches separately from the page it's on.
agents.json, llms.txt, and agent-instructions.md all live at
/. The agent reads them once and caches the result.
WebMCP is the opposite. It's in-page. The page registers its own actions to the agent runtime sitting inside the browser, while the human is using the page.
Concretely: a webpage running in Chrome 146+ can call
navigator.modelContext.registerTool and hand the in-browser agent a
JSON Schema describing an action, plus a JavaScript handler that
runs when the agent invokes it. From the agent's perspective it's
the same kind of typed tool call it would get from an MCP server —
but the round-trip never leaves the browser.
<!-- Minimal WebMCP example: a search action exposed to in-browser agents -->
<script type="module">
if ("modelContext" in navigator) {
await navigator.modelContext.registerTool({
name: "search_products",
description: "Search the store catalog by free-text query",
parameters: {
type: "object",
required: ["query"],
properties: {
query: { type: "string", description: "What the user is looking for" },
limit: { type: "integer", minimum: 1, maximum: 50, default: 12 }
}
},
async handler({ query, limit = 12 }) {
const res = await fetch(`/api/search?q=${encodeURIComponent(query)}&n=${limit}`);
return await res.json();
}
});
}
</script>
Three things to notice:
- Feature detection is the first line. If you ship this to a
Safari user today, the
ifguard makes it a no-op. Zero compatibility cost. - The agent never sees your DOM. It sees a typed action with a schema. The handler is yours; the contract is yours.
- No backend changes. The handler can call your existing search endpoint. WebMCP is a facade, not a re-architecture.
Why this matters: the token-budget argument
Pre-WebMCP, an in-browser agent had two options for interacting with your page:
| Mode | How it works | What it costs |
|---|---|---|
| Screenshot | Agent screenshots the rendered page, asks a multimodal model to identify the button to click, then synthesizes a click event | High latency, very high token count, brittle to layout shifts |
| DOM scrape | Agent parses the HTML, infers form structure, guesses field names | Faster than screenshots, still brittle, often fails on dynamic forms |
| WebMCP (post-146) | Agent reads the registered tool list, calls the typed handler | ~89 % token reduction, deterministic, no inference layer |
The 89 % figure is from the W3C working group's measurement against a reference catalog of common agent tasks (search, add-to-cart, filter, paginate, sign-in). Your numbers will vary. The direction will not.
For a site owner, the token-budget argument compounds: cheaper agent invocations means more agents will try your site, which means more agent-driven conversions, which means more reason for the next agent platform to default-prefer sites that support WebMCP. The flywheel started spinning on February 4.
What this changes for your site
Three concrete scenarios, in increasing order of urgency.
1. Pure-content publishers — no urgency
If your site is articles + a search + a newsletter signup, you do
not need WebMCP this quarter. The reading job is well-handled by
llms.txt, and agents.json is enough to expose your search
endpoint. WebMCP would let an in-browser agent search while
browsing your article without a round trip, which is nice, but the
delta over agents.json is small for non-transactional sites. Plan
to add it; don't drop work to add it.
2. Transactional sites with stable forms — plan for Q3
If you take leads, bookings, or sell anything, you want WebMCP in the back half of this year. The 89 % token reduction matters more for multi-step actions (search → filter → add → checkout) than for single-step content reads. Agent platforms will start preferring sites with registered tools because they're cheaper to operate. Being among the first WebMCP-aware sites in your category is a real ranking signal in answer-engine results.
3. Sites where agents already buy from you — ship before Q3
Some categories — flight booking, food delivery, B2B SaaS demo signups — already see meaningful agent traffic in 2026. If your analytics shows ChatGPT Atlas, Operator, or Mariner sessions converting on your site, every week without WebMCP support is a week of paying screenshot-mode tax. Get the registered-tools layer shipped this quarter.
Should you ship WebMCP code today?
Here's the honest answer, broken down by what we know about the spec's stability and your site's posture.
Ship today if you're a hand-coded site, you know your action surface, and you can afford to rewrite the snippet once when the final spec lands. The early-adopter SEO benefit in agent answer engines is real and the risk is bounded.
Wait two months if you're on a CMS (Shopify, WordPress, Webflow, Wix, Squarespace) and you're not running a custom theme. The plugins and apps that auto-emit WebMCP code are landing now; by mid-summer you'll get a one-click install that's safer than hand-writing the JS.
Don't refactor anything to "get ready for WebMCP." The whole point of the spec is that it's additive. Your existing
agents.json/llms.txt/agent-instructions.mdcontinue to work in every browser, including ones that don't support WebMCP. WebMCP layers on top — it doesn't replace.
That last point is the one most easy to get wrong reading the news this week.
How the BridgeToAgent kit handles WebMCP
The current $49 kit ships three files at the root of your domain —
agents.json, llms.txt, agent-instructions.md — plus
auto-discovery <link rel="alternate"> tags for the homepage
<head>. That stack works in every browser today, including Chrome
146 and Edge 147. WebMCP doesn't change that.
What it adds is a fourth artifact, on a release we're calling Kit 1.3 and shipping as a free add-on the moment the spec finalizes:
- A
webmcp.jssnippet generated from the same action data that feeds youragents.json. One source of truth — when an action changes in the kit, both files regenerate. - A single
<script>tag you paste into your site's<head>. The snippet feature-detectsnavigator.modelContextand silently no-ops in any browser that doesn't support it. - No new backend work. The snippet's handlers call your existing
search / contact / cart endpoints, the same ones
agents.jsonalready points at.
If you've already bought the kit, you'll get the WebMCP add-on as a free upgrade. If you haven't yet, the audit on the homepage now flags WebMCP-readiness alongside everything else — so when you run your site through it you can see exactly what's missing, including the slot for the snippet that's coming.
What to do this week
- Don't panic. WebMCP is additive. Nothing breaks if you ignore it for 60 days.
- Run an audit. The free readiness check now reports WebMCP-readiness as a separate signal so you know where your site stands. It takes five seconds.
- Ship
agents.jsonif you haven't. It's the action layer WebMCP itself is built on —webmcp.jsis essentially the same data, in-page. Shippingagents.jsonnow means your WebMCP snippet is one config change away the day Kit 1.3 lands. - Bookmark this post. We'll update the browser-support table every time a new browser version ships with WebMCP. If you're reading this six months from now, the table tells you whether the story has changed.
The bigger picture is simple. February 4 was the day the agentic web stopped being "soon" and became "shipping." Six months from now, the sites that took advantage of the window will be the default answer when an agent in someone's Chrome 146 needs to do something. The ones that waited will be the fallback.