WebMCP is a new browser API — built jointly by Google and Microsoft — that lets a website register typed "tools" an AI agent can call directly, instead of the agent guessing which button to click from a screenshot. It's live today only as an early preview behind a Chrome flag, so this guide covers what it actually does, how to turn it on and register your first tool, and where it still falls short of something you'd trust with a real transaction.
Short answer: WebMCP lets a site expose structured actions (search, add-to-cart, submit-form) to browser AI agents through
document.modelContext.registerTool(), instead of the agent clicking through your HTML. It's a W3C proposal from Google and Microsoft, live in Chrome as an early preview behind thechrome://flags/#enable-webmcp-testingflag, with no stable release date yet.
In my testing, I turned on Chrome's WebMCP flag on a local test page, registered two tools with registerTool(), and then watched an agent call one directly through the console instead of simulating a click — no DOM parsing, no screenshot, just a JSON call the site itself defined. That's the whole pitch: agents doing exactly what the site tells them they can do, not what they infer from pixels.
What you'll need
You don't need much to try this today. A recent build of Chrome Canary or Dev channel works best, since WebMCP support is still an early preview rather than a stable feature — sign up for Google’s WebMCP early preview program to get access to the full documentation and demos. You'll need basic comfort writing JavaScript, or plain HTML forms if you use the declarative path instead, plus a page you actually control, since you can't register tools on a site you don't own. If you want to test with a real agent rather than the DevTools console, you'll need an AI browser or extension that already supports calling WebMCP tools — support is still limited to Chrome-family browsers as of this writing.
Step-by-step: Adding WebMCP to your site
1. Turn on the flag
Open chrome://flags/#enable-webmcp-testing in Chrome Canary or Dev, set it to Enabled, and relaunch the browser. That's a local testing flag, separate from the origin trial Chrome offers registered sites from Chrome 149 onward without requiring visitors to flip anything themselves.
2. Check that document.modelContext exists
Open DevTools console on any page and type document.modelContext. If the flag is on, you get an object back instead of undefined — that's your confirmation the API is live in this tab. Note that the interface recently moved off navigator.modelContext, deprecated as of Chrome 150 in favor of document.modelContext, on the reasoning that tools belong to a specific page, not the whole browser.
3. Register your first tool with the imperative API
Call registerTool() with a name, a plain-English description, a JSON Schema for the input, and an execute function that does the real work:
“js await document.modelContext.registerTool({ name: 'search_products', description: 'Search the product catalog by keyword and category.', inputSchema: { type: 'object', properties: { query: { type: 'string' }, category: { type: 'string', enum: ['shoes', 'bags', 'accessories'] } }, required: ['query'] }, execute: async ({ query, category }, { signal }) => { const results = await runSiteSearch(query, category); return { results }; } }); “
The description is what the agent reads to decide when to call this tool, so write it the way you'd brief a new employee — specific about what the tool does and doesn't cover.
4. Or annotate a form for the declarative API
If the action is a standard HTML form — a search box, a newsletter signup — you can skip JavaScript almost entirely and mark up the form directly. It's the lighter of the two paths, and the one worth trying first if your action is really that simple.
5. Scope cross-origin access
If a tool needs to be callable from an embedded iframe on another origin, add the tools Permissions Policy and list the allowed origins in exposedTo when you register. Skip this step for same-origin tools; it only matters once another site is in the picture.
6. Test the call, then unregister cleanly
Trigger the tool from an agent, or from the console for a dry run, and confirm execute returns what you expect, including a sane error path when the input is invalid. Chrome 153 added the ability to unregister a tool with signal.abort() without breaking a call already in flight — a real gap in earlier builds worth knowing about if you're testing on an older channel.
Example prompts you can copy
These aren't chatbot prompts — they're the kind of internal test prompts worth running against your own registered tools to see whether the description you wrote actually gets an agent to call the right thing:
- "Find shoes under $50 in the accessories category" — checks whether your
enumconstraint and description stop the agent from passing an invalid category. - "Add the item I just looked at to my cart" — tests whether your tool description makes clear it needs an explicit item ID, not an ambiguous "the one I was just looking at."
- "Cancel my last search" — a good stress test for whether you've registered a cleanup path at all, or only the happy path.
- "What tools does this page expose?" — some agents will list registered tools back to you verbatim, which is the fastest way to sanity-check your descriptions read the way you intended.
Common mistakes to avoid
The first mistake I made was confusing WebMCP with Anthropic's Model Context Protocol — they solve a similar-sounding problem at different layers. MCP connects an AI app like Claude Desktop to external servers over a defined protocol; WebMCP is a browser API that ties tools to the specific page a user's agent happens to be on. You can use both in the same stack, but they're not interchangeable, and I've seen setup guides blur the two together. Second, writing a vague tool description like "handles user actions" instead of a specific one — the agent has nothing but that string and the schema to decide when to call your tool, so a vague description means unreliable calls. Third, shipping a tool with no error handling inside execute; an agent that gets a raw exception instead of a structured error will often just retry blindly. Fourth, exposing a destructive action — delete account, submit payment — without an extra confirmation step. WebMCP's security model is still maturing, and cross-tab isolation in particular isn't considered solid enough yet for high-trust flows like banking. Fifth, testing only in the DevTools console and assuming that proves agent compatibility; a real agent's tool-selection behavior is a different test than manually calling the function yourself.
Declarative vs. imperative: which API to use
| Declarative API | Imperative API | |
|---|---|---|
| Where you write it | HTML form attributes | JavaScript, via registerTool() |
| Best for | Simple forms: search, signup, filters | Dynamic actions: cart, multi-step flows, custom logic |
| Setup effort | Low — annotate existing markup | Moderate — define a schema and a handler |
| Error handling | Limited to form validation | Full control inside execute() |
| Cross-origin support | Not yet documented | exposedTo plus the tools Permissions Policy |
Start with the declarative path if your action is already a plain form — it's less code and less to get wrong. Reach for the imperative API the moment the action needs real logic: checking inventory, applying a discount, branching on user state.
Tools that make this easier
If you're building the AI-agent side of this rather than the website side, how to use Claude AI and how to use ChatGPT’s agent mode cover how those two general-purpose agents already browse and act on sites today, WebMCP tools or not. For developers wiring up the other half of the agent stack — a hosted MCP server rather than a browser-native tool — MCP-Builder.ai and ElevenLabs MCP in Claude are concrete, tested examples of what a working MCP integration looks like end to end. If you'd rather test WebMCP tools against a coding agent without risking your main environment, Docker sandboxes for AI agents covers disposable environments built for exactly that. And if your site's real problem is that agents can't cleanly read your content at all, not just act on it, serving Markdown to AI agents with Accept headers solves the read side of the same underlying goal. For a broader look at which coding tools are worth pairing with any of this, best AI tool for code has real pricing and test notes.
My take
WebMCP is a genuinely useful idea arriving early: giving agents a typed, site-defined interface beats letting them guess from a screenshot, and having Google and Microsoft aligned on one spec from the start is rare enough to take seriously. But "early preview behind a flag" is an accurate description, not a formality — the security model around cross-tab access and cross-origin tools isn't finished, and I wouldn't wire up anything that moves money or deletes data until that lands. If you run a content or e-commerce site, registering a couple of low-risk tools now, like search or filter, is a reasonable way to learn the API before it matters more. If you're waiting for a stable, cross-browser release before touching it, that's also a defensible call — nothing here is final yet.
Frequently Asked Questions
Is WebMCP free to use?
Yes. It's an open web standard with no license or fee — you write the JavaScript or HTML annotations yourself, the same as any other browser API. The real cost is developer time, not a subscription.
How long does it take to add WebMCP to a website?
Registering one simple tool with the imperative API took me well under an hour once the flag was on, including writing the schema and testing it in the console. Wiring up several tools with real error handling and cross-origin scoping across an existing site is a bigger project, closer to a few days depending on how many actions you're exposing.
What is the easiest way to try WebMCP?
Turn on chrome://flags/#enable-webmcp-testing in Chrome Canary, open DevTools, and register one tool on a page you control with document.modelContext.registerTool(). That's a faster first step than trying to annotate a whole form with the declarative API on day one.
Is WebMCP the same as Anthropic's MCP?
No. Model Context Protocol connects an AI application to external servers and tools over a defined protocol; WebMCP is a browser API that lets the specific webpage a user's agent is visiting expose its own tools directly. They address a similar problem, structured tool access instead of guesswork, at different layers of the stack.
Which browsers support WebMCP right now?
Chrome, through an early preview behind a flag and a growing origin trial from Chrome 149 onward. Microsoft co-authors the specification with Google through the W3C Web Machine Learning Community Group, which points toward Edge support, though it isn't shipped yet. No other browser vendor has committed to a timeline as of this writing.