WebMCP Solves Deployment. It Doesn't Solve Governance.

WebMCP shipped in Chrome 146 Canary two weeks ago. We've been building on top of Anthropic's MCP since the protocol launched, and we've watched the WebMCP spec develop through the W3C process. We have some thoughts on what it changes - and what it doesn't.

The short version: WebMCP makes it dramatically easier to expose agent-facing tools on the web. It inherits the browser's existing auth. It requires no new backend infrastructure. For deployment and authentication, the problem is largely solved.

For governance and observability, the problem is just beginning.

What WebMCP actually changes

Before WebMCP, adding MCP tools to a web product meant standing up a dedicated backend MCP server. New infrastructure, new deployment pipeline, new auth surface to manage. For teams already running MCP servers, it's manageable. For teams that just want agents to interact with their existing web app, it's significant friction.

WebMCP removes that friction. You add navigator.modelContext.registerTool() to your frontend JavaScript. Your existing Vercel deployment, your existing nginx config, your existing CDN - none of it needs to change. The tools run in the browser. The browser's session handles auth automatically.

This is the correct design. Alex Nahas and the MCP-B team understood that the authentication problem for browser-based agent interactions isn't solved by more OAuth infrastructure - it's solved by reusing what's already there. Every user of your web app is already authenticated. WebMCP lets agents inherit that authentication without any additional work.

On deployment and auth: genuinely solved. The spec made the right calls.

What the spec leaves out

Here's what happens when an AI agent calls a WebMCP tool on your production website today:

The tool executes. Your application logic runs. A response goes back to the agent.

And unless you've instrumented it yourself, that's all you know.

You don't know which agent invoked it. You don't know if the same tool was called 5,000 times in the past hour by an automated pipeline. You don't know if a tool call failed silently because the agent passed malformed parameters. You don't know if your checkout tool is being called in sequences that look nothing like human purchase behavior. You don't know which tools are driving the most agent-initiated conversions, or which tools have latency that's breaking agent workflows.

This isn't a criticism of the WebMCP spec. Protocol specifications define how tools are declared, discovered, and invoked. What happens around that invocation - observability, governance, policy enforcement - is explicitly out of scope for the protocol layer. It has to be.

But someone has to build it.

We've seen this before with backend MCP

When we started building LeanMCP, the most common conversation we had with teams adopting Anthropic's MCP was some version of: "We got the basic tool calling working in a weekend. Then we spent three weeks figuring out auth, and we're still not sure our logging covers what we actually need to see."

The MCP SDK gives you the protocol. It doesn't give you production infrastructure. Auth, multi-tenancy, observability, rate limiting, audit trails - these are full problems that deserve full solutions, not things you bolt on after the fact when something goes wrong in production.

That's exactly what LeanMCP addresses for backend MCP servers. A single @Authenticated decorator integrates with Cognito, Auth0, Supabase, or Firebase. Multi-tenancy with per-user isolation is built in. Logging and observability are on by default. You focus on the tool logic; LeanMCP handles the infrastructure around it.

// This is all you write
@Tool({ description: 'Get user orders' })
@Authenticated(authProvider)
async getUserOrders(input: OrderInput, context: AuthContext) {
  // context.userId and context.tenantId are already verified
  return await db.orders.findByUser(context.userId);
}

Auth, tenancy isolation, audit logging, session management - handled. Not by you, by the framework.

WebMCP brings the same fundamental gap to the browser layer.

What WebMCP observability actually requires

Having built production observability for backend MCP servers, here's what we know you need to see for browser-based tool calls:

Invocation telemetry. Every tool call needs: timestamp, tool name, success/failure, execution duration, agent identifier where available, session context. This is the raw event stream. Everything else derives from it.

Behavioral sequence analysis. A single addToCart call tells you little. searchProducts → addToCart → checkout executed 200 times in 10 minutes by a single agent pipeline tells you something completely different. You need the sequence, not just individual events.

Parameter validation visibility. When an agent passes malformed parameters to your tool's execute() function, does it fail silently or does that failure surface somewhere useful? Right now, mostly the former.

Rate limiting at the tool level. Standard HTTP rate limiting doesn't apply to WebMCP tools - they execute inside the browser page. If an agent pipeline starts hammering a tool, you need to shed load at the tool level, not the network level.

Policy enforcement. Which agents should be able to call which tools? Enterprise deployments will need to define this. The WebMCP spec provides requestUserInteraction for user confirmation on sensitive actions. The broader policy layer - allow/deny rules, confirmation requirements, audit trails for compliance - needs to be built above the spec.

Aggregate analytics. Which tools are highest traffic? Which have the most failures? Which have latency that suggests they're breaking agent workflows? This is the dashboard view - not event-level monitoring but aggregate intelligence about how the agent ecosystem interacts with your product.

What we're building

We're extending LeanMCP's observability layer to cover WebMCP tool calls.

The design goal is the same as our backend approach: zero changes to your existing tool code. You add one import. The observer wraps navigator.modelContext, intercepts tool registrations and executions, and streams telemetry to the LeanMCP dashboard.

import '@mcp-b/global';
import { LeanMCPObserver } from '@leanmcp/webmcp-observer';

LeanMCPObserver.init({
  projectId: 'your-project-id',
  governance: {
    rateLimit: { calls: 100, window: '1m' },
    requireConfirmation: ['checkout', 'deleteAccount'],
  }
});

// Your existing tools - unchanged
navigator.modelContext.registerTool({
  name: "addToCart",
  description: "Add a product to the cart",
  // ... automatically observed and governed
});

The observer sits above the @mcp-b/global polyfill and will work with the native Chrome implementation as it matures. We're building it to be compatible with both.

We're also working toward integration with your existing observability stack. The telemetry data belongs to you. If you're already running Datadog, Grafana, or any other observability platform, the WebMCP data should flow there alongside everything else.

A note on what we're not building

Worth being direct about scope.

We're not building a WebMCP deployment platform. The web already solved this. Your existing hosting handles WebMCP tools without modification. Any company trying to sell you a "WebMCP hosting" product is solving a problem that doesn't exist.

We're not forking or replacing @mcp-b/global. Alex Nahas and the MCP-B team built the right abstraction for cross-browser WebMCP support. We build on top of it. Our observer wraps it, it doesn't replace it.

We're not building a walled garden. The observability data you collect through LeanMCP is yours. Export it wherever you need it.

An invitation to MCP-B

We've been following the MCP-B project since before it became the WebMCP W3C spec. The work Alex Nahas and the team have done to bring browser-native agent interactions from an internal Amazon tool to a W3C standard is significant, and the polyfill that makes WebMCP available across browsers today is exactly the right interim solution.

We'd like to work together on the observability and governance layer. Concretely, we want to make sure the LeanMCP observer integrates cleanly with the @mcp-b/global polyfill API, that instrumentation hooks are available where the polyfill needs to expose them, and that the two projects are designed to work together rather than around each other.

If you're on the MCP-B team and want to talk through the technical integration: team@leanmcp.com.

The timing matters

WebMCP is in Chrome 146 Canary today. Stable Chrome support is realistically mid-to-late 2026. The window between now and then is the right time to get governance infrastructure right.

The teams that wait until WebMCP is in stable Chrome to think about observability will be retrofitting it into production systems under pressure. The teams that have it in place before then will have visibility from day one.

We saw the same dynamic play out with backend MCP adoption. The teams that built on LeanMCP from the start spent their time on product logic. The teams that built custom MCP infrastructure spent their time on auth and observability problems.

WebMCP is a better protocol for browser-based agent interactions than anything that existed before it. It deserves production-grade infrastructure. That's what we're building.

Get involved

If you're adding WebMCP tools to your product and want early access to the observability layer as we build it, join the waitlist at leanmcp.com or reach out directly at team@leanmcp.com.

If you're on the MCP-B team, we want to coordinate on the technical integration. Same email.

If you want to follow the build, the WebMCP observer module will be developed in the open: github.com/LeanMCP/leanmcp-sdk.

LeanMCP is an open-source TypeScript SDK for building production MCP servers. Built-in auth (Cognito, Auth0, Supabase, Firebase), multi-tenancy, elicitation, and observability for backend MCP deployments - with WebMCP governance coming next.

GitHub: github.com/LeanMCP/leanmcp-sdk · Discord: discord.com/invite/DsRcA3GwPy · X: @LeanMCP