WebMCP: letting an in-browser AI agent call your tools instead of clicking them

An AI agent operating a website today mostly works blind. It takes a screenshot, guesses where the button is, clicks, screenshots again to see what happened, and repeats. It's expensive (a single screenshot can cost well over a thousand tokens) and brittle (a layout change breaks the guesswork). The agent is reverse-engineering an interface built for human eyes.

WebMCP flips that around. Instead of the agent decoding your page, the page hands the agent a list of things it can do, with typed parameters, as callable tools. It inverts the control: the site declares its capabilities rather than making the agent infer them.

What WebMCP actually is

WebMCP is a browser API, navigator.modelContext, that lets a web page register its own JavaScript functions as tools an in-browser agent can call. The mental model that clicked for me: a page using WebMCP is an MCP server whose tools are implemented in client-side script instead of on a backend. The browser does the protocol work, translating your registered tools into MCP when it talks to the agent. There's no server to run.

The core of the API is small:

navigator.modelContext.registerTool({
  name: "estimate_agent_cost",
  description: "Estimate the monthly USD cost of an LLM agent...",
  inputSchema: { /* JSON Schema for the args */ },
  execute: (args) => calculate(args),   // your existing function
});

Register on mount, unregister on unmount, done. The agent sees a typed tool, calls it with structured arguments, and gets a structured result back, no DOM-scraping in the loop.

Why it's nearly free if your tools are already client-side

Here's the part that made me actually ship it rather than just read about it. This site has a pile of developer tools, calculators and auditors, and their logic already lives in pure, typed functions that the React forms call. An AI agent cost estimate is one calculate(input) call. An MCP tool-schema audit is one auditTools(text) call.

Exposing those over WebMCP is not a rewrite. It's registering a tool whose execute calls the function the form already calls. So I wired up three:

• estimate_agent_cost on the cost calculator,
• audit_mcp_tool_schema on the tool auditor (an agent auditing its own tool definitions is the on-the-nose use case),
• calc_error_budget on the SLO calculator.

The whole thing is a progressive enhancement: it feature-detects navigator.modelContext and does nothing when the API is absent, which today is almost everywhere. It cannot break the normal page. If your product's core actions are already client-side functions, the cost of trying WebMCP is close to zero.

The honest part: it's early

I want to be straight about the maturity, because the hype runs ahead of it:

• It's not a standard. WebMCP is a W3C Community Group draft, explicitly "not a W3C Standard nor on the Standards Track." That's "interested parties wrote something down," not "the web platform committed to this."
• The API is still moving. The older window.agent entry point was deprecated, and a provideContext() method was removed in favor of baking context into each tool's description. Code against it and expect churn.
• Browser support is thin. It first shipped in Chrome behind a flag, then an origin trial, with Gemini-in-Chrome as the agent consuming tools. Edge co-authored the spec but shipping status is murky; Firefox and Safari have no timeline.
• Almost nothing consumes it yet. As of mid-2026, the mainstream agents (Claude, ChatGPT's agent, Gemini, Perplexity) still mostly drive the web by screenshotting and clicking, not by calling navigator.modelContext tools.

So this is an early-mover bet, not table stakes. The reason it's still worth placing is that the downside is a few kilobytes of feature-detected code that no-ops, and the upside is being agent-ready the moment consumption catches up.

WebMCP is not "an MCP server"

Worth clearing up, because the names collide. WebMCP is client-side: tools that live in your page's JavaScript, for an agent running in the same browser. A remote MCP server is server-side: a service (say, a Cloudflare Worker) that any agent anywhere can connect to over HTTPS with auth. They solve different problems and compose fine. If your tools are already client-side, WebMCP is the cheaper first step; a remote server is the move when you want agents that never open your site to reach the same tools.

The takeaway

The expensive, fragile way an agent uses your site today, screenshot then guess, exists only because the site never told the agent what it can do. WebMCP is the page finally saying it out loud, in a typed, callable form. It's early and unstandardized, so treat it as a low-cost experiment rather than infrastructure. But if your product's actions already exist as client-side functions, wiring a few of them up is nearly free, and it puts you ahead of the curve instead of scrambling when browser agents actually start calling. Point one at your own tool schema and let an agent grade it.