mcp-handler adds experimental WebMCP support for in-browser agents

Vercel has added experimental support for WebMCP to mcp-handler, its library for building Model Context Protocol servers. According to the Vercel blog, the change lets a site expose its existing MCP tools to agents running in the browser by adding a single script tag, rather than building a separate integration for web-based clients.

WebMCP is a proposed web standard for exposing tools to in-browser agents. The model, as Vercel presents it, is that a page declares the capabilities it offers, and an agent operating on that page can discover and call them — extending the tooling pattern MCP established for servers and desktop clients out to the web itself.

How the integration works

Opting in is done per tool. Developers pass an experimental_webMcp object to createMcpHandler and list the names of the tools they want exposed — in Vercel's example, roll_dice. Only the named tools become available to the page; anything else registered on the server stays private.

The page then loads a script served by the MCP endpoint itself, requested with the ?webmcp-script query parameter. In the setup Vercel shows, a tag pointing at /api/mcp?webmcp-script is enough. Once loaded, the script registers the opted-in tools with the page and proxies every call back to the MCP server.

That proxying is the detail Vercel emphasizes most. Calls are forwarded as the signed-in user, which means tools that depend on server-side authentication keep working without a browser-side OAuth flow. The browser never has to negotiate tokens or credentials — the MCP server already knows who is making the request.

The feature ships in mcp-handler version 2.2.0. Vercel labels it experimental, and the experimental_ prefix on the configuration key signals that the API may still change as the underlying standard develops.

Why it matters

Most MCP deployments today target clients outside the browser — IDEs, desktop applications, or server-to-server integrations. This release gives the same tools a second surface with almost no additional code, which substantially lowers the cost of experimenting with browser-based agents.

The authentication model is arguably the more significant part. Wiring OAuth into a browser agent is one of the harder problems in this space, and proxying calls through the user's existing signed-in session sidesteps it entirely. Sites that already authenticate their visitors get authenticated tools essentially for free, and permissions stay enforced where they already live: on the server.

The release is also a signal about WebMCP itself. A proposed standard only gains traction through implementations, and a server library adopting one — even behind an experimental flag — gives spec authors and other implementers something concrete to test against. If the pattern holds, the web becomes a place where agents invoke declared tools instead of parsing markup, and sites turn into programmatic participants in agent workflows rather than passive documents.

For teams already running mcp-handler, the path to trying it is short: upgrade to 2.2.0, opt one or two tools into experimental_webMcp, and add the script tag to a page.