MCP Server Boilerplate Generator (TypeScript / Python)
Convert Anthropic's Model Context Protocol (MCP) Server into TypeScript / Python skeleton code by simply defining tools / resources / prompts in a structured form. Ready to use with MCP clients in Claude Desktop / Claude Code / Cursor (stdio transport format).
⚠ MCP SDK is evolving rapidly. Generated code targets TypeScript SDK ^1.0 / Python SDK >=1.0 assumed. For latest API changes, see
modelcontextprotocol.io
⚡ Presets (1-click skeleton)
🔧 Tools (functions LLM can call)
📚 Resources (read-only data sources)
💬 Prompts (reusable templates)
💡 Setup steps
- Download all files via "All zip"
- Extract and run 「dependency installation」(npm install / pip install -r requirements.txt)
- Add 「Claude config」 to ~/Library/Application Support/Claude/claude_desktop_config.json
- Restart Claude Desktop — server appears in tools
📖 Where people get stuck
Define your tools, resources and prompts in the form and it emits a Model Context Protocol server skeleton in TypeScript or Python, using the stdio transport, in a shape you can register directly with an MCP client such as Claude Desktop, Claude Code or Cursor. Everything runs in the browser. What it generates is the skeleton only — you still write the body of each tool. And the places where MCP work gets stuck are usually not inside the code but at the boundary between client and server: process startup, standard input and output, and environment variables. Those three are what follows.
| Case | What happens | What to do |
|---|---|---|
| One stray line on stdout breaks everything | With the stdio transport, standard output is the protocol channel itself — it assumes that nothing but JSON-RPC messages flows through it. So a single console.log() or print() injects foreign text into the middle of a frame and breaks the parser on the client side. What makes this awkward is that the resulting error message is completely unrelated to the cause — you get "the server could not connect", "unexpected token", or "disconnected", none of which point anywhere useful. And your own console.log is not the only possible source: a warning a dependency prints at startup, a package manager update notice, or output from your shell initialization script all flow into the same channel. |
Send every log line to standard error. Use console.error() in TypeScript, and print(..., file=sys.stderr) or logging.basicConfig(stream=sys.stderr) in Python — stderr is not used by the protocol, so you can write as much as you like, and it still shows up in the client-side logs. On a team, forbid console.log with a linter (the ESLint rule no-console with allow: ['error', 'warn']) — the most common pattern by far is someone adding one while debugging and committing it by accident. Learning the isolation step is worth it too: start the server directly in a terminal and look at whether anything other than JSON appears on stdout — whatever shows up there is your cause. |
| The description is effectively the prompt | The only material the model has for deciding whether to call a tool and what arguments to pass is the tool name, the description and the per-parameter descriptions — it never sees your implementation. So a description along the lines of "retrieves data" leaves the model unable to judge when to call it, so it goes uncalled when needed and called when irrelevant. A second failure is tool count: line up twenty tools with similar names and the model starts choosing wrongly. And the return value is part of the design too — returning a huge JSON blob verbatim burns through the context and leaves the model unable to find the part that mattered. The quality of an MCP server is determined by its words more than by its code. | Write the description in terms of when to use it and when not to, rather than what it does. Something like "use when the user asks about the delivery status of a specific order; only when the order ID is known; do not use for product search" — the more explicitly you state the boundaries, the more accurate the selection becomes. Put format examples in the parameter descriptions — writing "an ISO 8601 date, for example 2025-03-04" all but eliminates format mistakes. Keep tools few and their names mutually distinct: do not ship both get_user and fetch_user. Return a summary and let a second call fetch the detail when it is actually needed — building in paging and a limit from the start saves you from rebuilding later. |
| It runs in the terminal but will not start from the client | An MCP client starts your server as a child process, and that process has a different environment from your terminal. When launched from a GUI application, .bashrc and .zshrc are not read and PATH is minimal. As a result, the PATH entries injected by nvm, pyenv, asdf or volta are absent, and node or python itself cannot be found — the error is a single line reading spawn ENOENT. Environment variables are not inherited either, so a server you validated after exporting an API key will fail authentication when the client starts it. The working directory is not where you expect either — a config file you read by relative path will not be found. |
Put the absolute path of the interpreter in your client configuration. Take the output of which node or which python3 and use it as the command — if you use a version manager, this is essentially mandatory. Pass environment variables explicitly through the env key of the client config ("env": {"API_KEY": "..."} ) — and if your server reads a .env, make that path absolute too. When reading files, anchor them to __dirname in TypeScript or Path(__file__).parent in Python rather than depending on the working directory. And when something breaks, open the client log first — everything you wrote to stderr is collected there, and the cause is usually on the first line. |
An MCP server is a program running with your privileges. It can read and write files, reach the network and run commands — and what decides whether to invoke it is a model that is reading text from outside. Which means that content the model read can indirectly steer a tool call, the shape of attack known as prompt injection. Do not expose destructive operations as tools — the principle is that irreversible actions such as deleting, sending, paying or deploying should have a human confirmation in the loop. Splitting read-only tools and writing tools into separate servers is effective as well. On the implementation side, always normalize path arguments and verify that they resolve inside an allowed directory so that a run of ../ cannot escape it, and pass command arguments as an array. Finally, the MCP SDKs are updated actively — treat the generated code as a starting point and check the current API at modelcontextprotocol.io.
📖 How to Use
-
1
Pick preset or build from scratchPick preset (Filesystem / GitHub / SQL) or manually add tools/resources/prompts
-
2
Pick language + settingsTypeScript or Python; stdio or HTTP
-
3
Download zip → runDownload zip, install deps, add snippet to Claude config
❓ Frequently Asked Questions
What is MCP?
stdio vs HTTP?
Tools vs Resources vs Prompts?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.