Primary keyword: WebMCP | Long-tail: what is WebMCP, WebMCP vs MCP, WebMCP registerTool example, WebMCP declarative API form, WebMCP security third-party scripts, make your website AI agent ready
Inspired by Akshay Pachaar's WebMCP explainer on X. Different story, different angle, plus what changed in Chrome since.
Sharma Ji runs a sweet shop. Every morning the same thing happens: customers walk in, look at the trays, point at the kaju katli, say "half a kilo," pay, and leave. The shop is built for eyes and fingers. It works.
Now imagine a new kind of customer shows up. It can't walk in. It stands across the street, takes a photo of the shop every two seconds, and tries to work out from the pictures where the counter is, which tray is which, and whether that glowing rectangle is a billing machine or a TV.
Sometimes it guesses right. Sometimes it orders a kilo of the wrong thing. Sometimes the shop repaints the signboard and the customer is lost for a week.
That customer already exists. It's the AI agent that browses by taking screenshots and guessing where to click. WebMCP is the laminated rate card Sharma Ji finally puts on the counter: here is what you can order, here is what I need from you, and here is how to ask.
This post explains what WebMCP is, how the two APIs work, what already changed during Chrome's origin trial, and what a small site should (and shouldn't) do about it today.
What is WebMCP?
WebMCP is a proposed browser standard that lets a web page expose its own actions as structured, callable tools for AI agents. Instead of an agent inferring a "Add to cart" button from pixels or DOM structure, the page registers an action with a name, a plain-language description, and a schema for its inputs. The agent reads the list and calls the tool.
It was created by engineers at Google and Microsoft and is being developed in the W3C Web Machine Learning Community Group. Three earlier efforts converged to get here: a Microsoft explainer, a Chrome proposal, and an independent project called MCP-B, according to Zuplo's history of the spec. The draft was first published in February 2026, per this origin-trial write-up.
The mental model: your website keeps its human layer exactly as it is, and gains a second, machine-readable layer on top. Humans keep the trays. Agents get the rate card.
Is WebMCP the same as MCP?
No. WebMCP is MCP-inspired, not MCP. Server-side MCP connects an agent to a separate server you run. WebMCP runs inside the browser tab, in your page's own JavaScript. A GitHub discussion in the WordPress AI project is blunt about this distinction, and it's worth remembering because the naming causes real confusion. There's a further wrinkle: two unrelated projects both use the name WebMCP, the Chrome/Edge browser API and a separate library that works in any browser today. This article is about the browser API.
Why put the tools in the browser at all?
If server-side MCP already exists, why not just expose an API?
Because of state. The user's login session, the cart, the filters currently applied on screen: all of that lives in the open tab. A server tool would have to rebuild authentication and sync separately. A page-level tool acts inside the session the user already has, which is the core reason the idea exists, as the origin-trial analysis explains. It's also where the security risk comes from, which we'll get to.
Back to the shop: an API is a phone-order line. WebMCP is the counter. The counter already knows who's standing there.
If you've been reading our posts on agent harnessing, you'll recognize the pattern: the model isn't the whole story, the wrapper around it is. WebMCP is the website's half of that wrapper.
How WebMCP works: two ways to write the rate card
1. The imperative API (JavaScript)
You register one tool at a time on the document. Here's an illustrative example for a blog with a search feature. It follows the shape Chrome documents for the origin trial, but treat it as a sketch: I haven't run it against a live browser agent, and the API is still moving.
const controller = new AbortController();
await document.modelContext.registerTool(
{
name: "blog_search",
description: "Search published articles by keyword and return titles and links.",
inputSchema: {
type: "object",
properties: {
query: { type: "string", description: "Keyword or phrase" }
},
required: ["query"]
},
annotations: { readOnlyHint: true },
async execute({ query }) {
const results = await searchArticles(query); // your existing code
return JSON.stringify(results.slice(0, 5));
}
},
{ signal: controller.signal }
);
// Later, when the tool should disappear:
controller.abort();What each part does:
- name and description tell the agent when this tool is the right one.
- inputSchema is JSON Schema, the same contract style server-side MCP uses. It's also your first line of input validation.
- execute runs in client-side JavaScript and does the real work.
- annotations are hints such as read-only versus state-changing, and whether the tool handles untrusted content.
- The AbortSignal is how you remove a tool. There is no separate unregister call in the current docs.
2. The declarative API (plain HTML)
This is the part that should make small-site owners relax. You can turn an existing HTML form into a tool by adding attributes. Chrome's declarative API docs describe toolname and tooldescription on the form element. When an agent calls the tool, the browser brings the form into focus and fills in its fields, and the form stays visible to the user. Remove either attribute and the tool is unregistered.
<form toolname="subscribe_newsletter"
tooldescription="Subscribe an email address to the weekly newsletter.">
<input type="email" name="email" required>
<button type="submit">Subscribe</button>
</form>For submission you get two options: let the user confirm, or add the toolautosubmit attribute so the form submits itself. Chrome also exposes toolactivated and toolcancel events and a :tool-form-active CSS state so your UI can react while an agent is driving the form.
My rule of thumb: declarative for simple, low-risk forms; imperative when you need client-state logic. Anything that spends money or changes data should be the last thing you auto-submit.
What already changed (and why you shouldn't copy February's tutorials)
WebMCP is no longer a pure proposal. Per Chrome's docs, there's an origin trial starting in Chrome 149, so you can enable it on a production domain with a token. But the API has already shifted twice since the draft appeared:
| Then (early draft) | Now (origin trial) |
|---|---|
navigator.modelContext | document.modelContext; the navigator version is deprecated as of Chrome 150 |
provideContext() replaces the whole tool list | registerTool() adds one tool at a time |
clearContext() to remove | abort the AbortSignal you registered with |
| Duplicate names overwrite | Duplicate names throw an error |
All of this is from the DEV Community origin-trial breakdown. The practical lesson: if a tutorial uses navigator.modelContext and provideContext, it's describing a version that's already gone. A fair amount of the content ranking for this topic right now is stale.
Browser support is also narrow. At the moment it's a Chromium-only origin trial. Microsoft co-authors the spec, but I couldn't find a public ship date for Edge, so don't plan around one.
The security story: why provideContext died
This is the most instructive part, and it's a story worth telling at a whiteboard.
Early on, provideContext let a page declare its entire tool list in one call, replacing whatever existed. Convenient. But a real web page runs many scripts: yours, plus analytics, ad tags, chat widgets. If any third-party script could call that one method, it could swap out your checkout tool for its own and quietly sit in the middle of every agent-user exchange, as laid out in the issue that led to its removal. The spec moved to add-one-at-a-time registration that refuses duplicate names.
In shop terms: someone slipped a fake rate card over Sharma Ji's real one, with a different UPI QR code on it.
The takeaways for anyone building with this:
- Namespace your tool names so collisions are errors you notice, not overwrites you don't.
- Annotate honestly. Mark read-only tools as read-only, and flag tools that handle user-generated or externally sourced content as untrusted.
- Expose tools only to origins you trust. Chrome's docs say this plainly.
- Respect the size limits. Descriptions are capped at around 500 characters, parameter descriptions at 150, and tool output at about 1.5K, according to the same breakdown.
- Don't assume the standard protects you. Chrome's own documentation acknowledges that safety can't be guaranteed inside an LLM. Annotations and origin rules reduce risk; they don't remove it.
If you're thinking about the governance side of agents acting on live sites, our piece on AI agent auditing and compliance covers what auditors are starting to ask for.
Should a small site care today?
Honest answer: care, but don't rebuild.
Reasons to pay attention now:
- Agents that browse your site by screenshots are fragile and expensive. A site that offers a clear tool surface is simply easier to use, which is the same logic behind answer engine optimization: make it cheap for machines to understand you correctly.
- The declarative route costs almost nothing if your forms are already clean.
- Sites that treat agents as a real audience early will have fewer surprises later.
Reasons to wait:
- It's an origin trial in one browser family, and the API has changed twice already.
- Anything that moves money deserves a human confirmation step regardless of what the spec allows.
A sensible sequence for a content or SaaS site:
- Audit your forms. Which two or three actions would an agent legitimately perform for a user? Search, subscribe, contact, maybe "add to cart."
- Fix the boring layer first. Clear labels, proper input types, validation. A messy form makes a messy tool. Also keep the page light, because a heavy JavaScript bundle hurts humans and agents alike.
- Annotate one read-only form declaratively on a staging domain and watch what happens in Chrome's tooling.
- Write one imperative read-only tool (search is the obvious candidate) with a tight schema.
- Leave state-changing tools for last, and gate them behind explicit user confirmation.
- Isolate third-party scripts as much as your stack allows, since they're the threat the spec was redesigned around.
If you're building agent-facing products in general, the AI Agent Developer Roadmap on this site covers MCP, sandboxing, and observability, and the sandbox SDK roundup shows the server-side counterpart to all this. And if you're shipping a SaaS and want agents (and humans) to find it, the SaaS directories list is still the simplest distribution step.
WebMCP FAQ
What does WebMCP stand for? Web Model Context Protocol. It's a browser API that lets a page register tools for AI agents.
Who makes WebMCP? Engineers at Google and Microsoft, working through the W3C Web Machine Learning Community Group.
Does WebMCP replace MCP servers? No. They solve different problems: WebMCP runs client-side in the page and shares the user's live session; server-side MCP connects agents to services you host.
Can I use WebMCP in production today? Technically you can enable it through Chrome's origin trial from version 149, but the API is unstable and Chromium-only. Treat it as an experiment.
What's the safest first tool to expose? A read-only one, like search, with a strict input schema and a read-only annotation.
The shop, one more time
Sharma Ji doesn't stop serving customers who walk in. He just stops making the new customer guess. That's the whole idea behind WebMCP: the human experience stays as it is, and the machine gets an honest, structured way in.
The spec is young and it will keep changing, so build small, annotate carefully, and never let a tool spend someone's money without a human saying yes.
Want more builder-focused breakdowns like this? Browse the monthly iHateReading Magazine or the AI topic hub.