What Is WebMCP, and Should You Add It to Client Sites?

Your client's site has a checkout button. This week, an AI agent tried to click it by guessing — the same way every agent guesses at a site that hasn't told it what its buttons do.

What is WebMCP? It's a new browser standard built to close that exact gap. Last week it stopped being just a spec on paper. Now it's something you can wire into a Next.js site. Whether you should wire it into a paying client's site yet is a different question. The honest answer isn't "yes" or "no." It's "depends which part of the stack you mean" — and there's one specific reason for that we'll get to.

What Is WebMCP?

WebMCP is a proposed web platform standard from the Web Machine Learning Community Group. Engineers from both Google and Microsoft are driving the spec. It was first published in August 2025. Since then it has moved fast enough to get real developer tooling behind it.

Here's the idea. Right now, an AI agent visiting your site has to guess. It scans your HTML, guesses which <div> is a "buy now" button, and clicks through your UI like a burglar with a flashlight. WebMCP skips the guessing. Your site registers its own features as structured tools instead. A tool gets a name, like search_products. It gets a plain-English description. It gets a schema that spells out its inputs and outputs. The agent calls the tool directly.

That's the whole pitch in one line: agents go from interpreting your site to calling it.

Here's a detail most explainers skip. "Proposed standard" usually means little, because most proposed standards never ship, and the web is full of abandoned drafts that briefly made the rounds on a newsletter before quietly disappearing. This one reads differently. It has named engineers from two competing browser vendors working on the same spec, in the same repository, rather than one company's side project dressed up as an open standard. That's not a guarantee it lands. But it's a meaningfully stronger signal than most "future of the web" claims get, and it's worth weighing that against how early we still are.

There's also a security catch in this pitch that's easy to miss. We'll get to it once you've seen how the pieces actually fit together.

How It's Different from MCP

If "MCP" sounds familiar, that's because it should. Model Context Protocol is the server-side standard that already connects AI models to outside tools and data. Cursor, Claude Code and Codex all speak it today.

WebMCP takes that same idea and moves it into the browser tab itself.

How WebMCP Actually Works

Per Chrome's own developer documentation, WebMCP rests on three pieces.

• Discovery. A standard way to register a tool, like checkout or filter_results. An agent can find out what your page offers without reading your markup.

• JSON Schemas. Explicit input and output rules for each tool. This cuts down on the agent guessing at a field that doesn't exist.

• State management. A shared picture of what's true on the page right now. This stops an agent calling add_to_cart twice from accidentally checking out twice.

You can define tools two ways. An imperative JavaScript API handles anything dynamic. A declarative API annotates plain HTML form elements instead. Either way, every tool sits behind a tools Permissions Policy. Tools default to same-origin only. A third-party script on your client's site can't quietly register its own tools unless you let it.

What Registering a Tool Actually Looks Like

Reading a spec is one thing. Here's what the imperative API looks like in practice, straight from the WebMCP project's own examples:

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return {
      content: [{ type: "text", text: `Added todo item: "${text}" successfully.` }]
    };
  }
});

That's the whole shape of it. A name. A plain-English description. A schema. A function that does the real work — the same function your button already calls when a person clicks it. document.modelContext.getTools() lets an agent see what's on offer. addEventListener("toolchange", ...) lets your page announce when the tool list changes, say after a user logs in.

The spec's own use cases read like a tour of ordinary client work. Filter products by size and style on a store. Run diagnostics from a settings page. Fill out a multi-step form. None of it is exotic. It's UI work you already build, described once in a schema instead of re-guessed by every agent that visits.

Is WebMCP Actually Live Yet?

Mostly, no. And that matters more than the headlines suggest.

Chrome's own documentation is specific here: WebMCP is available through an origin trial starting at Chrome 149. You can also test it locally behind the chrome://flags/#enable-webmcp-testing flag. It has not shipped as a stable, default-on feature in any browser. There's no public signal yet on Safari or Firefox support.

So when a headline says WebMCP is "here," here's the accurate version. The spec is real. One browser has an opt-in trial for it. The tooling around it is just starting to show up. That's a very different claim from "ship this to production tomorrow."

That gap is exactly where this week's real news sits.

How to Add WebMCP to a Next.js Site Today

On September 18, 2026, Vercel shipped experimental WebMCP support in mcp-handler. That's its open-source package for running an MCP server on Next.js, Nuxt, Svelte and similar frameworks. The release notes put this at version 2.2.0.

Say you already run an MCP server for your project, maybe so a coding agent can query your product catalog. You don't need to build a second, browser-facing system from scratch. You opt existing tools into browser exposure through an experimental_webMcp config object. Then you drop in a script tag that points at your MCP endpoint, with a ?webmcp-script parameter.

Here's the part worth noting for client work. Tools exposed this way get proxied back to your MCP server as authenticated requests. Vercel's own framing: "authenticated tools work without a browser-side OAuth flow." The browser agent doesn't need its own sign-in step to call a tool that touches a logged-in user's session.

That mostly resolves the security catch from earlier. Calls are authenticated server-side. They're same-origin by default. They sit behind a permissions policy you control. What it doesn't resolve is browser support. You'd be building on an origin trial, on one browser, for a spec that's still evolving.

Plan your rollout around that gap. Feature-detect for WebMCP support before you register anything. Keep your normal UI as the only path for every visitor who doesn't have it. Treat the WebMCP bridge as an extra layer, not a required one. No human customer's experience should depend on a browser flag they've never heard of.

There's one more fact worth knowing before you touch a client's production site with any of this, and it has nothing to do with browser support. It's about what happens to the build itself once it leaves your hands — we'll come back to it after the practical question most people actually ask first.

Should You Add It to a Client Site Yet?

Here's the honest split, not the hedge.

Worth trying now, on a side project or staging site:

• You want to learn the pattern before it's a competitive skill to have

• You're building something agent-facing anyway, like a tool or a dashboard

• You already run an MCP server, so the extra cost is one config block and a script tag

Worth holding off on, for a paying client's live site:

• It's Chrome-only, origin-trial-only, with no committed ship date

• A trial or flag can change behavior on you with no warning

• Most client sites don't have agent traffic yet that would justify the risk

The freelancers who win here aren't racing to bolt WebMCP onto every deliverable this month. They're reading the spec now, trying it somewhere low-stakes, and building real knowledge of it before a client asks if their site is "AI-agent ready." That question is coming, even if it isn't standard practice yet.

Picture the actual conversation. A client who runs a mid-size product catalog asks if their site can "work with ChatGPT" like a competitor's apparently does. Today, the honest answer is a scoped one. You can register their search and filter tools behind a feature flag, on staging. You can demo it running in a Chrome origin trial. You can set clear expectations that a full rollout waits on wider browser support. That's a far stronger answer than "not possible" — or a rushed integration pushed straight to their live storefront.

What This Means for What You Hand Over

Every new feature you add to a build is more code that ships to the client before you're paid. WebMCP is no exception. It doesn't matter if it's a slick checkout flow, a custom dashboard, or an experimental browser API wired into a Next.js route.

It's worth saying plainly, since it's easy to lose in a post about a shiny new standard. None of this changes the oldest risk in the delivery model. You build it. You hand it over. The code runs whether the invoice ever clears or not. Adding more surface area to a project doesn't shrink that exposure. It grows what's now sitting on the client's server, fully readable, with nothing tying it to payment.

That's a separate problem from WebMCP. It's the one DevAegis exists for. The delivered build stays encrypted and only decrypts while the project is marked paid. Shipping a more ambitious feature set doesn't have to mean shipping more unprotected value. It's not a fix for anything WebMCP-specific. It's the same protection you'd want on any client build, applied before delivery — not after a client stops answering.

Curious where that fits next to the rest of your delivery process? How to protect your code as a freelancer walks through the mechanics end to end. And the legal shape of a kill switch covers the part most developers get nervous about: disclosure, and why it isn't sabotage.

What Is WebMCP, In One Line

A proposed browser standard, backed by Google and Microsoft engineers, that lets a website expose its own features as tools an AI agent can call directly. It's live today only as a Chrome origin trial. Vercel's mcp-handler now ships the first real developer path to try it on a Next.js site.

Try it somewhere that doesn't matter yet. Learn what it actually does before a client asks.

FAQs

What is WebMCP? WebMCP is a proposed web platform standard, built by the Web Machine Learning Community Group with engineers from Google and Microsoft. It lets a website register its own features — like "add to cart" or "search" — as structured tools an AI agent can call directly. That replaces the agent reading your HTML and clicking through it blind.

Is WebMCP the same as MCP? No. Model Context Protocol (MCP) is a server-side standard that connects an AI model to outside tools and data over a network. WebMCP brings that same tool-calling idea into the browser tab itself, so a webpage can hand tools directly to an agent running in or alongside that browser.

Can I use WebMCP on a live website today? Only experimentally. As of September 2026, Chrome supports WebMCP through an origin trial starting at Chrome 149, or locally behind the chrome://flags/#enable-webmcp-testing flag. It hasn't shipped as a stable, cross-browser feature. Treat it as prototype-stage, not production infrastructure.

Do I need a separate MCP server to add WebMCP to a Next.js site? Not if you already run one. As of mcp-handler version 2.2.0 (September 18, 2026), Vercel's package can expose your existing server-side MCP tools to browser-based agents. It does this through an experimental WebMCP bridge, authenticated without a separate browser OAuth flow.

What can you actually build with WebMCP tools? The spec's own examples are ordinary client-work tasks made agent-callable: filtering a store by size or style, running diagnostics from a settings page, filling out a multi-step form, or checking build status in a developer dashboard. It's existing UI work exposed through a schema — not a new category of feature.