JIMDRURY.
Jim Drury
Stamped intent plates greet.ts billing.intent sales.intent sliding into bolted /mcp crate on workshop desk
ai

xmcp: is this the framework for building MCPs?

SEP 18, 20265 MIN READ

At VMO2 I needed my Next.js developers to build our MCP servers. Not "go learn a platform". Not another weekend of stdio folklore. Business intents per domain, shipped by people who already think in app/ and route files.

That constraint is the whole post, really. Everything else is just me arguing with download charts.

What xmcp actually is

xmcp is a TypeScript framework from basementstudio. You scaffold with npx create-xmcp-app@latest, drop files under src/tools, src/prompts, and src/resources, and they auto-register the way Next registers routes. Zod schemas, metadata, a default handler. Hot reload while you fiddle. Zero-config deploy to Vercel (xmcp build notices the environment and emits something that serves /mcp).

If that paragraph felt familiar, good. It should.

File routing, but for agent verbs

The mental model is the point. Tool filename becomes the intent.

src/
src/
├── tools/
│   └── greet.ts
├── prompts/
├── resources/
├── middleware.ts   # optional
└── xmcp.config.ts  # optional
src/tools/greet.ts
import { z } from "zod";
import { type InferSchema } from "xmcp";

export const schema = {
  name: z.string().describe("The name of the user to greet"),
};

export const metadata = {
  name: "greet",
  description: "Greet the user",
  annotations: {
    title: "Greet the user",
    readOnlyHint: true,
    destructiveHint: false,
    idempotentHint: true,
  },
};

export default async function greet({ name }: InferSchema<typeof schema>) {
  return `Hello, ${name}!`;
}

A TypeScript dev house already knows this pattern. You're not inventing a new religion. You're putting business intents in files my team can review in a PR.

Why not just mcp-handler?

Nothing wrong with Vercel's mcp-handler. Last week it sat around 1.09 million weekly npm downloads (week of 10-16 Sep 2026). If your MCP wants to live inside a Next app, it's a very reasonable default.

The coupling is the trade. The app and the MCP share a deployable. That's fine when you want it. It's the wrong fit when the MCP should be its own thing: own repo, own preview, own blast radius when someone renames a tool.

An xmcp is for the second case. A little Next-shaped server that is only the agent surface.

Downloads are a terrible DX compass

Other TypeScript options exist. I checked npm the week of 10-16 Sep 2026:

  • xmcp: about 19.5k weekly

  • fastmcp (punkpeye): about 547k weekly (code-first sessions, not file routing)

  • @prefecthq/fastmcp-ts: about 4.1k weekly

Downloads aren't a DX score for a TypeScript dev house. They tell you who shouted loudest, or who got bundled into something else. They don't tell you whether your Next developers can open a PR before lunch.

And then there's Python FastMCP

FastMCP on the Python side is mature. Huge ecosystem. Often "better" if you measure maturity and examples.

The question I keep asking inside VMO2 is simpler: do my Next / TypeScript teams know Python?

If the answer is "sort of, from uni", you're not accelerating domain MCPs. You're starting a second hiring problem. I'll take the less mature TS framework that matches my team over the mature one that forces a language switch for every billing intent.

The agents reading the docs (without the paste buffer)

An xmcp ships a docs MCP at https://xmcp.dev/mcp (Context7-shaped search over xmcp itself). You connect something like npx mcp-remote https://xmcp.dev/mcp and the agent queries docs instead of you playing human clipboard.

I've written enough about copy-paste culture already. This is the boring fix: give the agent a search tool for the framework it's using.

Back to VMO2

The bit that made this click for me wasn't the scaffold. It was the pipeline around it.

We've been building infra and skills where the agents generate sequence diagrams of what websites actually do, feed that into AI context, and mint unique business intents from the real flows. Pair that with an xmcp and the idea gets concrete: an MCP per domain. Virgin Media Sales. O2 eCare Billing. The rest of the catalogue.

Non-prod in about a day each, once the pattern is in people's hands. Not because an xmcp is magic. Because my team already knows file-based routing, Zod, and Vercel, and the framework stops arguing with that.

Thoughts

If your teams need MCPs from a Next.js / TypeScript dev house, stop ranking frameworks by download charts. Rank them by whether a domain MCP looks like a normal PR. For us, that's an xmcp.

Similar Articles