Vercel lets in-page AI agents call your site's tools as the user

Code from Vercel changelog: WebMCP support in mcp-handler: import { createMcpHandler } fr…
Code: Vercel changelog, "WebMCP support in mcp-handler"

Summary

Sites using Vercel's MCP library can now give chosen server tools to AI agents running inside the browser, and those agents act with the visitor's logged-in session. The feature is experimental and only works in browsers that support WebMCP.

Treat the tool list as a security decision. Any script on the page can call what is exposed, so start with read-only tools and accept bridged calls only when they carry a same-origin session cookie.

Vercel’s mcp-handler 2.2.0 adds experimental support for WebMCP, according to Vercel’s changelog. mcp-handler is Vercel’s open-source library for hosting Model Context Protocol (MCP) servers. Those servers are the endpoints that AI clients such as Claude Desktop and Cursor connect to when they call a site’s tools. WebMCP is a proposed web standard that lets a page offer tools to AI agents running inside the browser. With the update, a site lists the tools it wants to share in a new experimental_webMcp option and adds one script tag, and an agent on the page can then call those tools.

How the calls are made matters more than the one-line setup. Per the bridge documentation, the script reads the tool list from the site’s MCP endpoint and registers each allowlisted tool with the browser’s WebMCP provider. When an agent calls a tool, the script sends that call back to the server from the page. The request carries the visitor’s session cookies, so the agent acts as the signed-in user without a separate OAuth login. In a browser without a WebMCP provider, the script does nothing.

The allowlist decides what an agent can do as your user

The documentation warns that any script or agent in the page can call registered tools with the user’s credentials. Its advice is to expose only tools that are safe to run on the user’s behalf and to prefer read-only ones. A tool that changes data should get the same scrutiny as a form that submits from the same site. The allowlist only controls what the page sees. The MCP endpoint keeps serving its full tool set to regular MCP clients.

Your authentication setup decides whether the bridge works at all. A server that accepts only bearer tokens through the library’s withMcpAuth wrapper will receive bridged calls with no credentials unless its verifier also accepts session cookies. The documentation calls cookie sessions the natural pairing. It also says never to put access tokens in the generated script.

Only AI agents working inside a live browser page are affected. The documentation does not mention crawlers. Because the script acts only where the browser has a WebMCP provider, the likely consequence is that AI browsers and in-page agents can use it, while training crawlers, AI search bots and fetchers that pull raw HTML cannot. Browser support is still early. The documentation describes WebMCP as a W3C community group proposal under active development, available in Chrome through an origin trial and a local testing flag. The WebMCP API also requires a secure (HTTPS) page and an origin-isolated document. For why sites are being asked to do this at all, see Google telling developers to build sites that AI agents can use.

What to do

If you run an MCP server on mcp-handler and want in-page agents to use it, upgrade to 2.2.0 and take these steps in priority order:

  • Bridge read-only tools first. Keep tools out of the allowlist if they need to update visible UI, invalidate client caches, or ask the user for confirmation. The documentation says to register those in the page itself, because a successful server call does not update the page.
  • Accept cookie sessions only from same-origin requests. The documentation recommends checking Sec-Fetch-Site: same-origin on cookie-authenticated calls and setting required: true. Otherwise a rejected or missing session can fall through to running the tool unauthenticated.
  • Write real tool descriptions. When a description is missing, the bridge falls back to the tool’s title or name, and agents have less to go on when choosing a tool.
  • Add your CSP nonce to the script tag if your site uses a nonce-based Content Security Policy.

The minimal setup, from the changelog and documentation:

// app/api/mcp/route.ts
const handler = createMcpHandler(
  (server) => {
    server.registerTool("roll_dice", /* ... */);
  },
  {
    experimental_webMcp: {
      tools: ["roll_dice"],
    },
  },
);
export { handler as GET, handler as POST };
<script src="/api/mcp?webmcp-script" async></script>

If your site does not run an MCP server, there is nothing to do yet. Neither Vercel’s changelog nor the documentation claims any effect on crawling or rankings.