Zuplo
Blog
Model Context Protocol

WebMCP: How Websites Will Expose Tools to AI Agents

Martyn DaviesMartyn Davies
March 13, 2026
6 min read

WebMCP is a proposed W3C standard that lets websites declare their capabilities as structured tools that AI agents can call directly in the browser.

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 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:

Javascriptjavascript
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. 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.

Zuplo MCP Server Handler

Turn your existing API routes into MCP tools with auth and rate limiting built in.

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