Summary
Vercel added experimental WebMCP support to mcp-handler, letting a site expose its existing MCP tools to in-browser agents by adding a single script tag. Developers opt tools in via an experimental_webMcp allowlist, and the bridge registers them with the page's WebMCP provider and proxies each call back to the MCP server as the signed-in user — no separate browser-side OAuth flow.
What changed
mcp-handler gained experimental WebMCP support that adds a browser bridge on the existing MCP route (?webmcp-script), registers an explicit allowlist of tools with the page's WebMCP provider (navigator.modelContext / document.modelContext), and proxies tool calls back to the MCP server using the user's existing session.
Why it matters
WebMCP is an emerging proposal for letting in-page agents call a site's tools, and until now wiring it up meant a separate integration. Bridging existing MCP servers to the browser with one script tag lowers the cost of making a site agent-actionable, while the required per-tool allowlist acknowledges the real risk that any script in the page could invoke tools with the user's credentials.
Evidence excerpt
Expose your MCP tools to in-browser agents with a single script tag, no separate OAuth flow required.