How to generate an MCP server

What you get

A complete project, not a snippet. The protocol layer is finished — required headers, error codes, caching metadata, statelessness, discovery — so the only code left to write is the body of each tool.

src/mcp.ts          the protocol — headers, errors, caching, discovery
src/tools.ts        YOUR CODE GOES HERE
src/server.ts       node:http adapter
src/server.test.ts  a test per tool, plus protocol conformance
server.json         ready for registry publishing
package.json
tsconfig.json
README.md

Pick Cloudflare Workers and you get worker.ts and wrangler.toml instead of the node adapter; pick Vercel and you get vercel.json. Choose stdio and you get stdio.ts, which is byte-identical in behaviour to the HTTP path — the same handler behind a different transport.

The project name becomes the folder, the package name and part of the registry identifier. The namespace is the reverse-DNS prefix that proves who published it — io.github.yourname if you will authenticate with GitHub, or your own domain if you will verify it over DNS.

It is worth getting right now: the namespace is what the registry checks you own, and changing it later means republishing under a different identifier.

TypeScript and Python both produce a conformant server. TypeScript has the wider host support; Python runs on the standard library alone, with nothing to install before it starts.

The framework row is the part that surprises people. No framework is the only enabled choice, and the other three are shown disabled with the reason rather than hidden:

• Official SDK, FastMCP, xmcp — every TypeScript option here is built on @modelcontextprotocol/sdk, whose supported-version list stops at 2025-11-25. A server built on it cannot answer a 2026-07-28 client, and no application code changes that.
• The Python SDK does ship the 2026-07-28 surface — but scored three MUST-level failures when we graded it, so it does not meet the bar this generator sets for itself.

Both halves were measured, and the check is re-runnable: if a framework ships support, the tripwire in the repository reports it and the option can be enabled. See the framework comparison for the full measurement.

Streamable HTTP is a server clients connect to over the network. stdio is a local program a client launches as a subprocess — the right choice for something that touches the user's own machine, and it requires the Node target.

Authorization has three levels. None is right for a server exposing nothing sensitive. API key adds a bearer token and a 401 challenge. OAuth 2.1 emits RFC 9728 protected-resource metadata and JWT verification with audience binding — the resource-server half of the OAuth guide.

The host only changes the entry point and its config file. The protocol layer is identical across all three, so switching later means swapping one file rather than rewriting the server.

Each tool needs a name, a description and its parameters. Two things are worth knowing because they are validated rather than silently accepted:

• Parameter names become code. They are destructured into a binding, so a kebab-case name would produce a project that does not compile. The form rejects those, along with reserved words and a handful of names that would shadow something.
• The description is what a model reads when deciding whether to call your tool. It is the highest-leverage text in the whole project — “Get the forecast for a city” beats “weather tool” by a wide margin.

Three outputs, and they suit different moments:

• Download .zip — the project on your machine, nothing sent anywhere.
• Open in StackBlitz — running in the browser in a few seconds, with no local toolchain. TypeScript only: the sandbox is a Node runtime and cannot run Python.
• Push to GitHub — creates a new public repository. Signing in asks for no permissions; repository access is requested only when you click this, and the token is used once and never stored.

With the Cloudflare Workers target, pushing to GitHub also offers a one-click deploy — you authenticate with Cloudflare directly and we never hold a credential.

What to do next

Write your tool bodies in src/tools.ts, run the generated tests, deploy, and then check the deployed URL:

npx createmcps validate https://your-server.example.com/mcp

The generated project is conformant when it leaves here, but a proxy, gateway or platform can change headers on the way out — so the server that matters is the deployed one. How to read the report.

When you are ready to make it discoverable, publish it to the official registry — the server.json in your project is already shaped for it.

FAQ

Related