WebMCP is a proposed web standard, incubated in the W3C Web Machine Learning Community Group, that lets a website register tools for AI agents. Each tool has a name, a plain-language description, and a JSON schema for its inputs. An agent working in the browser can call those tools directly instead of reading the page and guessing which buttons to press.

Which browsers support WebMCP?

As of November 2026, Chrome runs a WebMCP origin trial that started in Chrome 149, and the spec's implementation status lists an Edge origin trial from Edge 150, experimental support in Brave's Leo AI chat, and support in the ChatGPT desktop app. Mozilla's standards position is neutral and WebKit's is oppose, so Firefox and Safari do not support it.

When does the Chrome WebMCP origin trial end?

Chrome's origin trial was originally set to end with Chrome 156 in November 2026. It has since been extended to Chrome 162, with an end date of March 30, 2027. Sites in the trial need a renewed token to keep tools working for regular Chrome visitors.

Is WebMCP the same as MCP?

No. A Model Context Protocol (MCP) server runs on a server and an AI client connects to it. WebMCP tools are registered by a web page and run inside the visitor's own browser tab, using the session the visitor is already signed into. A site can use both, and one practical pattern is having the page's WebMCP layer call the site's existing MCP server.

Should you use navigator.modelContext or document.modelContext?

Use document.modelContext. The spec moved the API from navigator to document in May 2026, and Chrome's imperative API documentation registers tools on document.modelContext. Code and tutorials that use navigator.modelContext or provideContext() are out of date.

What Is WebMCP? Lessons From 3 Live Sites

Most AI agents still use a website the way a new employee uses a stranger's computer: they look at the screen, guess which button does what, and hope the form does not change before they finish. WebMCP is an attempt to fix that by letting the website hand the agent a menu.

Egmer shipped WebMCP tools on three production websites in August 2026: egmermarketing.com, VisibilityFAQ, and a headless Shopify store. All three still register their full tool sets in regular Chrome as of November 11, 2026. This post covers what WebMCP is, where support stands right now, and the five traps that cost the most time getting there.

What Is WebMCP?

WebMCP is a proposed web standard that lets a page register tools for AI agents. Each tool carries a name, a plain-language description, and a JSON schema for its inputs. An agent working in the browser can list those tools and call one directly, instead of reading the page and simulating clicks.

The spec is incubated in the W3C Web Machine Learning Community Group, with work coming from Google and Microsoft. Two things make it different from a normal API:

It runs in the visitor's own tab. The tool executes in the page's JavaScript, with the session the person is already signed into. There is no separate server process for the agent to connect to.
It is built for a human in the loop. The agent and the person are on the same page at the same time. That shapes how good tools are written, which comes up again in the traps below.

Here is the smallest useful shape of a tool, using the current API:

document.modelContext.registerTool({
  name: "check_service_area",
  description:
    "Says if the business serves a city.",
  inputSchema: {
    type: "object",
    properties: {
      city: { type: "string" }
    },
    required: ["city"]
  },
  execute: ({ city }) =>
    lookUpServiceArea(city)
});

WebMCP vs MCP

The names are close enough to cause confusion. A Model Context Protocol (MCP) server runs on a server, and an AI client connects to it from outside. WebMCP tools are registered by a web page and live only while that page is open in someone's browser.

	MCP server	WebMCP
Where it runs	A server	The visitor's browser tab
Who connects	An AI client	An agent in the browser
Signed-in session	Separate auth	The visitor's own
Can see the page	No	Yes

They are not rivals. One of the most useful patterns below has the WebMCP layer call a site's existing MCP server.

Did You Know?

Chrome's WebMCP origin trial was originally scheduled to end with Chrome 156 in November 2026. According to Chrome's origin trial registry, it has been extended through Chrome 162, ending March 30, 2027, and the Chrome Platform Status entry gives the reason as "OT feedback has suggested improvements to the API, which we are implementing." Plenty of articles still quote the November date. If your tools went quiet in regular Chrome, check your token's expiry first.

Where WebMCP Support Stands in November 2026

Secondary coverage of WebMCP has been unreliable, so everything below comes from primary sources checked on November 11, 2026.

Chrome: origin trial since Chrome 149, announced in the WebMCP origin trial post. Chrome Platform Status lists the feature as Proposed, with no ship milestone entered.
Edge: origin trial from Edge 150, per the spec's implementation status.
ChatGPT: OpenAI's site tools documentation says site tools are "ChatGPT's implementation of the proposed WebMCP standard" and run in the built-in browser of the ChatGPT desktop app.
Brave: experimental support in Leo AI chat, per the implementation status.
Gemini in Chrome: Google said at I/O in May that Gemini in Chrome "will soon support WebMCP APIs" (Chrome at I/O 2026). No later announcement says it has shipped.
Firefox and Safari: Mozilla's standards position is neutral, and WebKit's standards position is oppose, citing security, privacy, and API design concerns.

Google's I/O post showed nine brands experimenting with WebMCP: Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target.

One more moving part: the spec removed the declarative API (tool attributes on HTML forms) on October 8, 2026 and moved it to a separate explainer, while Chrome's docs and ChatGPT still describe form attributes. The imperative JavaScript API is the stable ground today.

Insider Tip from Tyler and Melissa: Map the Whole Funnel First

The first version of Egmer's tool set covered only the middle of the funnel: services, FAQs, service area, contact details, and a tool to book a call. An agent helping someone who was interested but not ready to talk had exactly one action available, the biggest commitment on the site. Every free resource Egmer had built was invisible to it.

Before writing a single tool, list what an agent should be able to offer someone who is not ready to buy. If the answer is only "book a call," the tool set is not finished. Egmer's now includes a tool that returns the free resources, and its service tool tells the agent to suggest those first for anyone still deciding.

Three Patterns That Worked

Each of the three sites needed a different approach, and each is reusable.

Read from the site's own data files. On egmermarketing.com, the core tools read from the same files that build the pages: company details, services, and the published FAQs. An agent's answer cannot drift from what the page says, because there is only one source.
Bridge to an existing MCP server. The Shopify store already ran an MCP server. Its WebMCP layer fetches the server's tool list, registers each tool with the browser, and passes calls through. Any tool added to the server reaches browser agents with no extra work.
Proxy the site's own API routes. VisibilityFAQ has no MCP server, but its forms already post to API routes. Its five tools call those same routes, so an agent request runs the same generation, email, and contact steps as a typed one. Never write a second version of a form just for agents.

The Five Traps

1. Old tutorials use the old API

The spec moved the API from navigator to document in May 2026, and provideContext() was removed back in March. A lot of published code still uses both. Chrome's imperative API docs register tools on document.modelContext, and a tool is removed by aborting the AbortSignal passed at registration. Feature-detect on document.modelContext and render nothing when it is missing, which today is every browser outside the trials.

Teardown matters in a single-page app. Without an abort on unmount, client-side navigation registers the same tools twice.

2. The origin trial form has a box that silently breaks a meta tag

Chrome's origin trial registration form offers third-party matching. A third-party token only works when it is delivered from an external script file, and it does nothing in a meta tag. If you serve the token in a meta tag, as most sites do, leave that box unchecked.

Two related details. Tokens are per origin, so a token for one domain does nothing on another. And check which way your www redirect runs before registering, because the token has to match the origin visitors actually land on. You can confirm a token before using it: base64 decode it and read the origin, feature, and expiry in the payload.

3. Registration order can take the whole tool layer down

The bridge pattern's first version fetched the server's tool list first and returned early if the list came back empty. When the server was slow or erroring, the page registered nothing, including the tools that need no server at all.

Register the tools that live in the page first, unconditionally. Then try the server list inside a try and catch and add whatever arrives. Use Promise.allSettled for registration so one rejected tool cannot take the rest with it.

A related lesson: if every browser tool also exists on the server, WebMCP adds reach but no new capability. The reason to run it in the page is what a server cannot see, like the visitor's cart, the page they are on, or state held in their browser storage. The store's useful tools were the ones that read and fill the cart.

4. Tools freeze whatever they close over

A tool registers once and runs much later. Anything its execute function closes over is captured at registration time, so a cart tool written the obvious way answers from the cart as it was when the page loaded. Read live state through a ref that updates on every render.

Even a ref is not enough right after a change. After awaiting an add to cart, reading the ref still returned the old cart, because React had not re-rendered yet. The fix was having the mutation return the updated state and reporting that.

5. Your QA can pass while nothing is registered

Two test bugs passed for days on a site that was broken:

An async predicate in waitForFunction never waits. It returns a Promise, a Promise is always truthy, and the wait resolves on the first poll. Poll with page.evaluate instead, which actually awaits.
.every() on an empty array returns true. A check that every tool has a description passes when there are zero tools. Always assert the expected count too.

A third version of the same mistake showed up in monitoring. A health check that stopped polling at the first non-zero tool count reported a healthy site as broken, because local tools registered a second before the bridged ones. Check for the expected count, and wait until the count stops climbing.

Write Tools for the Person on the Page

Because the visitor is present, two rules held up on all three sites:

Actions navigate, they do not submit. Egmer's booking tool opens the booking page and its result says plainly that nothing has been booked. The store's cart tools can fill a cart and hand over the checkout link, and no tool completes a purchase.
Put consequences in the description. The agent reads the description before it decides to call the tool. If a tool emails someone or adds them to a list, say so there and tell the agent to get the person's agreement, then state what actually happened in the result.

VisibilityFAQ adds one more: when a tool produces something, show it on the page. Otherwise the agent gets an answer the person on screen never sees.

How to Measure It

Search Console will not show WebMCP activity. Its AI reports measure search features citing your content, while WebMCP is an agent acting inside a browser session. The honest measure is your own analytics event fired from each tool's execute, marked as a non-interaction event so agent calls do not distort engagement numbers.

For a quick manual check, Chrome DevTools has a WebMCP panel under Application that lists registered tools and shows tool calls as they happen.

How Egmer Approaches It

WebMCP is still a proposed standard, and the API has changed more than once this year. Egmer runs it on its own sites to learn where it breaks before recommending it to anyone else. The groundwork that pays off either way is the same groundwork AI search rewards: clear page structure, real forms, accurate business details, and an accessibility-first build. A site with that foundation can add a tool layer later without a rebuild.

If you run a small business and want the plain-English version of what agents mean for your website, read AI agents for small business. For how AI search finds and cites businesses today, start with SEO, AEO, and GEO explained and three things your website needs for AI search.

Want to know where your own site stands? A Goggles On Business Chat walks through what your website tells people and AI tools about your business today, and what is worth fixing first.

Goggles On, Let's Ride!

What Is WebMCP? Five Traps From Shipping It on Three Live Sites