Generate an MCP server
Define your tools, pick a transport and a host, and download a working server that implements the 2026-07-28 specification. The protocol layer is finished — headers, error codes, caching metadata, statelessness — so the only code left to write is what your tools actually do.
First time? Read the walkthrough — what each option changes, why the framework choices are disabled, and what is inside the project you get.
Verified, not asserted
The generated server is compiled, booted and graded by the same validator that runs on /validate: 35 pass · 0 fail · 0 warn. The one excluded rule is MCP-SEC-002, which requires HTTPS — a loopback test server cannot have a certificate. Deploy behind TLS and it passes.
Tools
Parameters
Pushing creates a new public repository and asks GitHub for the public_repo permission at that point. Signing in on its own asks for nothing, and we never store the permission — it is used once, for this push.
What lands in the zip
src/server.ts
The transport. Every rule id is named in a comment next to the code that satisfies it.
src/tools.ts
Your tools, with JSON Schemas built from the parameters you define and a stub per handler.
src/server.test.ts
Protocol conformance tests — the checks most easily broken by an innocent-looking edit.
server.json
Registry manifest, ready for mcp-publisher bar one placeholder URL.
README.md
Real instructions, including why there is no framework dependency.
Dockerfile / vercel.json / wrangler.toml
Whichever your hosting choice needs. The protocol code is identical across all three.
Why the framework options are disabled
Every mainstream TypeScript MCP framework is built on @modelcontextprotocol/sdk, and the SDK's own protocol constants stop at 2025-11-25:
@modelcontextprotocol/sdk@1.30.0 LATEST_PROTOCOL_VERSION = 2025-11-25 SUPPORTED_PROTOCOL_VERSIONS = 2025-11-25 … 2024-10-07 → does NOT include 2026-07-28 fastmcp v4.14.2 sdk ^1.24.3 bounded by SDK xmcp v0.6.13 sdk ^1.26.0 bounded by SDK
So a generated FastMCP server would fail our own validator on most of its rules. We read those numbers from npm rather than from memory, and the options turn on when the SDK does. Full comparison: FastMCP vs xmcp vs the official SDK.
Frequently asked
Why is there no option for the official MCP SDK, FastMCP or xmcp?
Because none of them can serve a 2026-07-28 client yet. @modelcontextprotocol/sdk's own SUPPORTED_PROTOCOL_VERSIONS tops out at 2025-11-25, and FastMCP and xmcp both depend on it, so they inherit that ceiling. A server built on any of them cannot answer server/discover, cannot honour the required Mcp-Method header, and does not emit ttlMs or cacheScope on list results — it would fail most of our own rules. Rather than generate code we would then have to grade as non-compliant, the generator emits dependency-free TypeScript that implements the transport directly. We re-check this from npm rather than from memory; when the SDK ships 2026-07-28, the option appears.
What does “scores 100% on the validator” actually mean?
A script in this repo generates a project, runs npm install and tsc on it, starts it as a real HTTP server, and evaluates it using the same probe modules that grade other people's servers in production — imported directly, not reimplemented. The current result is 35 pass, 0 fail, 0 warn. One rule is excluded and named rather than quietly dropped: MCP-SEC-002 requires HTTPS with a verified certificate chain, which a loopback test server cannot have. Deploy the generated code behind TLS and it passes.
Is the generated code written by an AI?
No. It comes from deterministic templates — the same options always produce byte-identical files, with no clock, no randomness and no network involved. That is a requirement rather than a preference: the claim that generated code passes the validator is only meaningful if the artefact we verified is the artefact you receive.
Are the tools implemented for me?
No, and this is the honest boundary of a scaffolder. You get the full protocol layer — transport, header validation, error codes, caching metadata, statelessness — plus a typed handler stub per tool marked TODO, a JSON Schema built from the parameters you defined, a test suite and a registry manifest. What each tool actually does is your code to write.
Can I publish the result to the MCP registry?
Yes. A valid server.json is included. One field is deliberately left as a placeholder: remotes[0].url, which you must set to your real deployed URL. We don't guess it, because the registry requires the server to actually be reachable at the URL it declares, so an invented one would produce a manifest that fails the moment anyone checks it.
Generated something? Deploy it, then run it through the validator to see the same 79-rule report anyone else gets — including MCP-SEC-002, which only a real deployment can pass.