Next.js MCP vs WebMCP: which one does your app need?

Search "Next.js MCP" and you get three unrelated technologies wearing the same four letters. Next.js 16 has a built-in MCP server. Vercel maintains a package for hosting MCP servers in Next.js. And since August, Vercel's storefront templates register WebMCP tools. People arrive at our scanner having installed the first when they wanted the third, so here is the map.

The three, side by side

1. The Next.js MCP server: for the agent writing your code

Next.js 16 runs an MCP endpoint inside the dev server. Add one entry to .mcp.json and a coding agent can ask the running app for its current errors, its route table, the source file behind a Server Action ID, and version-accurate docs from your installed Next.js. It is excellent, and it has nothing to do with your users. Nothing from it is deployed.

// .mcp.json  (dev-time only; nothing ships to users)
{
  "mcpServers": {
    "next-devtools": { "command": "npx", "args": ["-y", "next-devtools-mcp@latest"] }
  }
}

If you read "Next.js now supports MCP" and pictured shoppers' assistants using your site, this is the headline that misled you. It is a developer productivity feature. Use it while you build the other two.

2. mcp-handler: your app as an MCP server

Vercel's mcp-handler turns a route handler into a full MCP server that any MCP client can connect to over HTTP. This is the right tool when the caller is not on your website: an enterprise's internal agent, a ChatGPT connector, a partner's automation. You define tools with Zod schemas, you handle authentication yourself, and the result is an API with a standard shape.

// app/api/mcp/[transport]/route.ts   (a classic MCP server hosted in Next.js)
import { createMcpHandler } from "mcp-handler";
import { z } from "zod";

const handler = createMcpHandler((server) => {
  server.registerTool("get_pricing", {
    description: "Return the current plans and prices.",
    inputSchema: { currency: z.enum(["USD", "EUR"]).optional() }
  }, async ({ currency }) => ({ content: [{ type: "text", text: JSON.stringify(await pricing(currency)) }] }));
});

export { handler as GET, handler as POST };

The cost is the same as any API: you build and secure an auth layer, you document it, and you expose one more surface to the internet. For a public tool like pricing that is fine. For "add this to the user's cart" it means implementing identity for machines, which is the exact problem WebMCP was created to avoid.

3. WebMCP: your page as a tool server, for the agent already on it

WebMCP flips the direction. Instead of an agent connecting to your server, your page hands the agent that is already rendering it a set of typed tools. The agent acts as the user, with the user's cookies, in the user's tab, and the user can watch. There is no auth to build because the session already exists. In Next.js the tools are registered from a Client Component and backed by Server Actions, which we walk through in the Next.js WebMCP guide.

// components/webmcp-tools.tsx   (runs in the visitor's browser)
"use client";
import { useWebMCP } from "use-webmcp-tool";
import { getPricing } from "@/lib/webmcp/actions";

export function WebMCPTools() {
  useWebMCP({
    name: "get_pricing",
    description: "Return the current plans and prices, in the currency this visitor is browsing in.",
    inputSchema: { type: "object", properties: {}, additionalProperties: false },
    annotations: { readOnlyHint: true },
    execute: getPricing
  });
  return null;
}

Who calls it today: Chrome 149 to 156 with an origin-trial token (Gemini in Chrome support is announced), Edge 150 in its own trial, the ChatGPT desktop app's browser natively, and extension-based agents on any browser through the MCP-B polyfill. Cloudflare Radar's May 2026 scan of the top 200,000 domains found none with WebMCP tools, which tells you how early it is and how cheap the differentiation still is.

Which one do you need?

• You want Cursor or Claude Code to stop guessing about your app while you build. Next.js MCP server. Ten minutes, no deploy.
• You want agents that never visit your site to use your data or actions. mcp-handler. Budget for auth, rate limits and docs, like any API.
• You want the assistant a visitor is already using to complete tasks on your site. WebMCP. Four to seven tools that wrap what the site already does.
• You sell things. WebMCP first. Add-to-cart in the user's own session is the use case every vendor demoed, and Shopify ships it on every storefront already.

When you want both

The two production options are complementary, and the good news is they share a backend. The four-step action pattern from the Server Actions guide (validate, call one data function, shape a small result, return it) is the same function an mcp-handler tool should call. Write the capability once in lib/, expose it to browser agents through WebMCP with the session as identity, and expose the public, read-only subset to remote agents through mcp-handler with an API key. Keep the consequential tools (checkout, cancellation, messaging) on the WebMCP side only, where a human is watching and a confirm step is natural.

One thing neither MCP gives you is discoverability. An agent that reads before it acts still needs server-rendered content, JSON-LD, an llms.txt, and crawler access, and that is where most Next.js apps actually lose points. The free scan checks all of it in fifteen seconds, and the WebMCP vs MCP vs llms.txt comparison covers the whole stack. For a plan specific to your site, book a free strategy call.

Sources

• Next.js: Enabling the Next.js MCP server for coding agents
• vercel/mcp-handler
• Vercel Commerce: WebMCP tools PR
• Chrome: WebMCP compared with MCP
• OpenAI: site tools in ChatGPT