---
title: "WebMCP: How Websites Will Expose Tools to AI Agents"
description: "WebMCP is a proposed W3C standard that lets websites declare their capabilities as structured tools that AI agents can call directly in the browser."
canonicalUrl: "https://zuplo.com/blog/2026/03/13/what-is-webmcp"
pageType: "blog"
date: "2026-03-13"
authors: "martyn"
tags: "Model Context Protocol"
image: "https://zuplo.com/og?text=WebMCP%3A%20How%20Websites%20Will%20Expose%20Tools%20to%20AI%20Agents"
---
MCP has given AI agents a standard way to connect to tools and services. Agents
can query databases, call APIs, manage files, interact with SaaS platforms. But
there's a gap in the picture: the browser.

Web applications hold a huge amount of business logic, user state, and
authenticated context that agents can't reach through a traditional MCP server
without rebuilding it all on the backend. Your dashboard, your admin panel, your
internal tools. They already do the things an agent would want to do. There's
just no standard way for an agent to call them.

WebMCP is a
[proposed web standard](https://webmachinelearning.github.io/webmcp/) that
changes that. It lets websites declare their capabilities as structured tools
that agents can call directly, using a browser-native API. Your website becomes
the tool surface. No separate server. No duplicated logic.

## The gap between MCP and the browser

Traditional MCP servers run on the backend. They're separate processes that
agents connect to over HTTP or stdio. That works well for APIs, databases, and
headless services. But it creates an awkward gap for web applications.

Consider an internal dashboard. It already has endpoints for searching records,
updating statuses, running reports. It has auth baked in through SSO and session
cookies. It has role-based access controls. All of that lives in the browser
context. To expose the same capabilities through a traditional MCP server, you'd
need to rebuild the logic server-side, wire up a separate auth layer, and
maintain both in parallel.

Some teams do this. It's the right call when you need agents to access your
service outside a browser context, or when the operations are purely backend.
But for web-based products where the browser _is_ the primary interface, it's a
lot of overhead to give agents access to things the web app already does.

WebMCP proposes a different path: let the website itself declare its
capabilities as structured tools that agents can call directly in the browser.

## How it works

WebMCP adds a new browser API, `navigator.modelContext`, that lets web
developers register tools directly on their pages. There are two approaches:
imperative (JavaScript) and declarative (HTML attributes).

**The imperative API** gives you full control. You register tools as JavaScript
functions with a name, description, input schema, and an execute callback:

```javascript
navigator.modelContext.registerTool({
  name: "search_products",
  description: "Search the product catalog by keyword",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" },
      category: { type: "string" },
    },
  },
  execute: async ({ query, category }) => {
    const results = await catalog.search(query, category);
    return { products: results };
  },
});
```

The tool's `execute` function runs in the browser context. It has access to the
page's state, the user's session, and any client-side logic the app already has.
No separate server needed.

You register tools when relevant components mount and unregister them when they
unmount. On a search results page, the agent sees filter and sort tools. On a
product page, add-to-cart. On checkout, address and payment tools.

The available capabilities change contextually as the agent navigates. This maps
naturally to how component-based apps already think about state.

**The declarative API** works through HTML attributes on forms:

```html
<form
  tool-name="book_table"
  tool-description="Reserve a table at the restaurant"
>
  <input name="party_size" tool-param-description="Number of guests" />
  <input name="date" tool-param-description="Reservation date (YYYY-MM-DD)" />
  <button type="submit">Book</button>
</form>
```

Agents visiting the page discover the tool automatically from the form markup.
No JavaScript required. For static sites, CMS pages, or any scenario where you
just want to make existing forms agent-accessible, this is the path of least
resistance.

## Who's building it

WebMCP is being developed jointly by Google's Chrome team and Microsoft's Edge
team, with editors from both organizations working on the W3C spec. It's
currently a Draft Community Group Report under the W3C Web Machine Learning
Community Group.

The concept has roots in several independent proposals. Microsoft published a
"Web Model Context" explainer. Google's Chrome team proposed "Script Tools."
Alex Nahas built MCP-B, a Chrome extension implementing similar ideas, while
working at Amazon. All three converged into the unified WebMCP proposal now at
the W3C, with Nahas actively involved in the working group.

The timeline from prototype to preview has been fast: MCP-B was built in January
2025, Google and Microsoft published their unified proposal in August 2025, and
the W3C Community Group formally accepted it in September 2025. Chrome 146
shipped an Early Preview in February 2026, with support accessible via
`chrome://flags` by searching for "WebMCP" or "model-context". A polyfill is
available at [docs.mcpb.ai](https://docs.mcpb.ai). Broader stable release across
Chrome and Edge is still ahead.

## Why this matters for API developers

Today, making your service accessible to AI agents means building an MCP server,
which is essentially another API surface. That server needs its own auth, its
own hosting, and its own maintenance lifecycle. For services that are already
consumed through a web interface, that's a lot of duplicated effort.

WebMCP lets the web app itself be the agent interface. The tools run in the
browser, with the user's existing session and permissions. No separate auth
layer. No separate deployment. The agent calls the same functions the UI does.

There's also an efficiency argument. Agents that interact with web apps through
screenshots or DOM scraping are token-hungry and brittle. WebMCP's structured
tool calls have been shown to be 89% more token-efficient than screenshot-based
approaches, which matters both for cost and for reliability at scale.

This doesn't replace traditional MCP servers. Backend operations, headless
workflows, CLI agents, and cross-client tool ecosystems still need server-side
MCP. But for web-based products (dashboards, SaaS tools, internal apps, admin
panels) WebMCP offers a lower-friction path to agent-readiness.

The two approaches are complementary. A product might expose its core API
through a traditional MCP server for programmatic access, and use WebMCP to let
agents interact with its dashboard in the browser. Different access patterns,
same underlying capabilities.

<CalloutDoc
  title="Zuplo MCP Server Handler"
  description="Turn your existing API routes into MCP tools with auth and rate limiting built in."
  href="/docs/handlers/mcp-server"
/>

## A shot in the arm for MCP adoption

MCP has had a complicated reception. The protocol is solid, but the friction of
running and maintaining a separate MCP server has pushed some teams toward
alternatives, particularly CLI-based agent skills, which are simpler to ship and
don't require a persistent server process.

WebMCP doesn't make that tradeoff disappear, but it does open a lane that
CLI-based approaches can't reach: the user's browser session. An agent skill
running in a terminal has no access to the authenticated state in your web app.
It can't interact with your dashboard, your SaaS UI, or anything that lives
behind a login. WebMCP tools can, because they run where that context already
exists.

That's a genuinely different capability, not just a more convenient way to do
what CLIs already do. For teams that dismissed MCP as too much overhead for
their use case, WebMCP lowers the bar significantly: no server to deploy, no
separate auth to wire up, just a few lines of JavaScript on your existing pages.
If MCP adoption has stalled in your organization, this might be the version of
the story that unlocks it.

## Where it stands today

It's still early days for WebMCP. The spec is a W3C Community Group Draft, not a
standard, which means the API surface may change. Browser support is behind
experimental flags.

The security model is further along than it might appear. The current spec
includes same-origin policy enforcement, CSP integration, and an HTTPS
requirement for secure contexts. Sensitive tool calls require human-in-the-loop
confirmation, while read-only tools can be marked to bypass that prompt. There's
also a `SubmitEvent.agentInvoked` flag, so your existing form handlers can tell
whether a submission came from an agent or a human, useful for logging,
auditing, or applying different validation paths. The broader question of
cross-tab data leakage is still under W3C review, but the foundation is more
solid than "still being worked out."

But the trajectory is clear. Google and Microsoft are both committed. The W3C
incubation process gives it a path to standardization. And the underlying
problem, agents needing structured, reliable ways to interact with web apps,
isn't going away.

For developers, the practical takeaway is straightforward: make your tools
discoverable, give them clear schemas, and let agents call them directly.
Whether that's through WebMCP's browser API, a traditional MCP server behind an
API gateway, or both, the web apps that declare their capabilities to agents
will have an advantage over the ones that wait for agents to figure it out on
their own.

Websites are becoming tool surfaces. WebMCP is how the browser plans to make
that happen.

## Further reading

- [WebMCP W3C Draft Spec](https://webmachinelearning.github.io/webmcp/)
- [Chrome Early Preview Program](https://developer.chrome.com/blog/webmcp-epp)
- [MCP-B Polyfill & Docs](https://docs.mcpb.ai)
- [WebMCP GitHub Repository](https://github.com/webmachinelearning/webmcp)