WebMCP: when your website hands tools to the agent

Last verified: 9 August 2026

The model it replaces

The standard way to make a website usable by an AI agent is to build a second website for machines. You stand up an MCP server. You define tools. You issue API keys. You build an auth flow so the agent can act on a user's behalf. Then you maintain two systems that have to stay in sync.

That works, and most serious integrations still do it. But look at what it costs: the agent operates on a copy of your application's capability, reached through credentials the user had to provision, against state that may not match what they're looking at.

WebMCP inverts it. The page registers its tools directly into the browser. An AI assistant running in that tab — a browser-native assistant, an extension, a sidebar — calls them using the visitor's live session, their existing cookies, and the DOM they're already looking at.

No server. No API key. No auth handoff, because there's nothing to hand off — the user is already logged in.

Why that matters more than it sounds

The authentication point is the whole thing.

Consider what it takes today for an agent to check a customer's order status on your site. You need an API, an authenticated endpoint, a token exchange, a consent flow, and a way for the agent to prove it's acting for that specific customer. That's weeks of work and a permanent security surface.

With WebMCP, the customer is logged into your site in their browser. The agent runs in that context. When it calls your get_order_status tool, it's the customer's session making the call — same as if they'd clicked the button themselves. The authorization question was answered when they logged in.

The second-order effect is that anything a user can do on your site becomes a candidate tool, without a parallel API. Long tail functionality that would never justify an API endpoint becomes agent-accessible for the cost of a tool registration.

How it actually works

The API lives on the document:

document.modelContext.registerTool({
  name: 'get_pricing',
  description: 'Returns current pricing for all plans.',
  inputSchema: { /* JSON Schema */ },
  execute: async (params) => {
    // your logic — runs in the page, with the user's session
    return { content: [{ type: 'text', text: '...' }] }
  }
})

Three things on the current surface: registerTool(tool, options) to register, getTools(options) to enumerate, and an ontoolchange event for when the available set changes.

Chrome also offers a declarative flavor where you annotate HTML forms directly, which covers a lot of common cases without writing JavaScript at all.

Requirements are what you'd expect for something this powerful: a secure context, origin-isolated documents, and a "tools" permissions policy that defaults to ['self'].

A note on churn, because it's the most important practical thing here. This API changed in 2026. It used to live at navigator.modelContext and included a provideContext() method. navigator.modelContext was deprecated in Chrome 150; provideContext() no longer exists in the specification. If you shipped against the earlier surface and never revisited it, your tools are not registering in current Chrome — and nothing errors loudly to tell you. That's the shape of building on an incubating standard: not a reason to avoid it, but a reason to own the maintenance.

Where the standard actually stands

Let's be precise, because a lot of coverage overstates this.

WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group. A Community Group is where ideas incubate. It is not the standards track, and WebMCP has not graduated to a Working Group.

Chrome is running an Origin Trial spanning versions 149 through 156. Chrome stable is currently 151, so the trial is mid-window. It is not shipped to stable.

Microsoft co-authors the specification and the Edge team has publicly committed to collaborating.

WebKit has an open request on its standards-positions repository, filed in May 2026, tagged with concerns about API design, privacy, security, venue, and meaningful user consent. Those are substantive objections, not procedural ones. Safari has not taken a position.

Mozilla has published no position at all.

So: one browser shipping an experiment, one co-authoring, one with logged concerns, one silent. That's genuinely early. Anyone describing WebMCP as an emerging web standard is being generous.

Debugging it

Chrome DevTools has WebMCP inspection built in, under the Application panel. It shows the tools a page has registered, the tools that have been invoked, lets you invoke them manually, and flags schema violations.

You do not need an extension for this. Older guidance — including our own, earlier — pointed at a separate DevTools extension. The functionality moved into the browser.

For local development before the origin trial token is in place, enable chrome://flags/#enable-webmcp-testing.

What we run on this site

We registered WebMCP tools on neuralpartners.ai the week Chrome's documentation went live. Seven tools are registered from a single script in our site footer:

• get_pricing — current pricing across our Neural Core plans
• list_offerings — services tracks, bundles, and platform tiers
• search_intelligence — search our Intelligence articles by topic
• get_company_info — company details and contact information
• navigate_to — navigation to a requested section
• contact — pre-fills our contact form
• start_quote — pre-fills a quote request

We resolved the API migration on 9 August 2026, and we'd rather tell you why than quietly fix it. Our implementation read navigator.modelContext only — the original surface. When Chrome deprecated it in favor of document.modelContext, our registration guard simply returned early and no tools registered at all on newer Chrome. Nothing threw. Nothing logged. The site looked exactly the same. We caught it while fact-checking this very guide, and the fix reads both surfaces, preferring the current one:

var mc = document.modelContext || navigator.modelContext;
if (!mc || typeof mc.registerTool !== 'function') return;

That is the failure mode of an incubating standard in one paragraph: a silent regression, invisible to everyone including the people who shipped it, caught only by going back and checking. If you have WebMCP tools in production and haven't looked since Chrome 150, go look now.

Two design decisions worth stealing.

The form tools never submit. contact and start_quote write a handoff payload to sessionStorage and pre-fill the matching form when the visitor lands on it. The human still clicks the button. An agent that can complete a lead form on someone's behalf without their attention is a spam vector, not a feature — and the first serious abuse of WebMCP will almost certainly be exactly that.

Every tool is read-mostly. Nothing we've registered changes state. That's a deliberate ceiling on blast radius while the security model is still being argued about in public.

You can verify all of this yourself: open this site in Chrome 149 or later and check the Application panel in DevTools.

Should you build on it

Yes, if you can absorb API churn, your use case is read-heavy, and being early has strategic value for you. The work is small — registering a handful of tools is an afternoon, not a quarter.

No, if you need stability, you're planning write operations, or you'd have to justify the maintenance to someone who'll ask why the tools broke. Chrome 150 already broke one generation of implementations — ours included. It will happen again before this reaches a Working Group.

Either way, don't let WebMCP substitute for the work that actually matters. Structured data, a clean llms.txt, a UCP manifest, and a real MCP server serve far more agent traffic than a browser API in origin trial. WebMCP is a strong signal and a genuine capability. It is not the foundation.

What we're watching

Whether it moves from the Community Group to a Working Group — that's the graduation that would make this a real standard rather than an experiment.

Whether WebKit's concerns get addressed. The privacy and consent objections are the substantive ones, and if they don't resolve, WebMCP stays a Chrome feature.

What happens at the end of the Chrome 156 origin trial. That's the decision point.

Whether a permission and consent model emerges that survives contact with adversaries. Right now the security story rests on the origin boundary and a permissions policy. That's a reasonable start and it is not sufficient for write operations at scale.

Sources

WebMCP specification (W3C Web Machine Learning CG) · webmachinelearning/webmcp · Chrome: WebMCP documentation · Chrome: WebMCP imperative API · Chrome DevTools: WebMCP panel · Intent to Experiment: WebMCP · WebKit standards-positions #670