Scaffold the MCP server. Keep your tools.
Describe your tools and get a typed TypeScript MCP server: the current McpServer API, zod input schemas, stdio or Streamable HTTP, plus a README and a zip download. Everything is assembled in your browser.
Server
Announced to the client during initialisation, and used as the visible title.
Lowercase, URL-safe, optional @scope/. Used by package.json and the npx command.
Tools
Every tool becomes one server.registerTool() call. Parameters become zod schemas with .describe() and .optional().
Validation
0Generated files
The zip is built locally by JSZip; no file ever leaves the page.
A scaffold is a first draft, not a server
This generator writes the five files every TypeScript MCP server starts with, wired to the API the SDK actually exposes today: McpServer plus registerTool(). What it cannot write is the only part that matters — what your tools do. Every handler returns placeholder data with a TODO comment, and the guide below explains the three choices you still have to make before the server is worth running: the transport, the shape of each tool's result, and the version pins.
Treat the output the way you would treat a colleague's pull request: read it, question it, then own it. The SDK moves quickly and package versions in a scaffold are stale the day after they are written.
stdio or Streamable HTTP
stdio is the right default for a tool that lives on the same machine as the client. The client launches your process, speaks JSON-RPC over stdin/stdout, and stops it when the session ends. There is no port to expose, no authentication to design and nothing to deploy — which is also why a stdio server must never print to stdout: console.log corrupts the protocol stream. Log to stderr instead, which is why the generated code uses console.error.
Streamable HTTP is the transport for a server that has to run remotely or be shared by several clients. The generated variant creates a stateless transport with sessionIdGenerator: undefined and answers every request on one Node HTTP server. Stateless is deliberate: it survives restarts and horizontal scaling without a session store. The moment it is reachable from anywhere other than localhost you own authentication, rate limiting and origin checks yourself — the MCP spec expects that, the SDK will not do it for you.
Designing the tool surface
An agent chooses tools from their names and descriptions alone, before it ever sees your code. A description that says "gets data" is a tool the model will call wrongly and then blame on you. Say what the tool returns, in what units, and what happens on failure. Keep parameter descriptions just as concrete: "City name, e.g. Madrid" beats "the city".
Prefer a handful of sharp tools over one mega-tool with a mode parameter. Each parameter you add is another thing the model can get wrong, and required parameters make a call fail outright while optional ones invite hallucinated values. Mark a parameter optional only when the server genuinely has a sensible default for it.
Results are content blocks. Returning { content: [{ type: "text", text: ... }] } is the portable choice, and serialising structured data as JSON in a text block keeps it readable for the model and for a human reading the transcript. If a tool can fail in an expected way — a city that does not exist — return isError: true with an explanatory message instead of throwing, so the model can recover.
Frequently Asked Questions
Which SDK API does the generated code use?
The high-level McpServer class with server.registerTool(name, { title, description, inputSchema }, handler), where inputSchema is a plain object of zod schemas. That is the API that carries a human-readable title and an optional output schema. The older server.tool() form and the low-level Server class are deliberately not used: they still work, but they are not what new servers should be written against.
Why does the handler return a placeholder instead of throwing?
Because a scaffold that does not compile is worse than one that lies. Every handler returns a well-formed content block with the parsed input echoed back, so you can run the server and see the round trip work before you write a single line of real logic. Then replace the body — and only the body.
Are the dependency versions in package.json current?
They were current when this generator was written, and they are semver ranges rather than pins, but you should still check the registry before installing. The SDK has changed its zod peer range more than once, and a mismatch there produces confusing type errors rather than a clear message.
Can I test the server without a full MCP client?
Yes. The generated README includes an inspect script that runs the official MCP Inspector against the built server. It gives you the tool list, a form per tool, and the raw JSON-RPC traffic — which is usually enough to catch a wrong schema before any client touches it.
Is anything uploaded when I generate or download?
No. The files are string templates filled in by JavaScript in this page, and the zip is produced in memory by JSZip. There is no backend, no account and no telemetry from this tool.
Related tools
cURL to code converter · WCAG contrast checker · All MousyTools
Hecho por MousyDev
Creo herramientas web que respetan tu privacidad: tus datos se procesan en tu propio navegador y nunca pasan por mis servidores.