MCP Server Boilerplate GeneratorTypeScript and Python templates, ready to run

The first MCP server you write takes an afternoon. Not because the protocol is hard - it is one of the smaller specs in the AI tooling space - but because the SDK has multiple transport classes, a registerTool API that subtly differs between SDK versions, and a handful of opinionated patterns (stderr fallback, timeout wrapping, JSON-RPC error shape) that are easy to miss when you copy a snippet from a blog post.

The generator above produces the same scaffold that experienced agent builders write by hand. Pick a language, paste the commands you want exposed, and the output includes: correct SDK imports for the version you are actually pulling, a real execFile or asyncio.subprocess call with a 30-second timeout and a stderr fallback, JSON-Schema input objects derived from each command's flags, and a ~/.claude.json snippet wired to the build output.

The fastest path from "I want Claude to be able to run my CLI" to a server that boots cleanly under MCP Inspector is to use the boilerplate generator, not to scaffold it by hand. The generated server compiles on first run because the dependencies and the SDK API are version-matched, and the README has the exact Inspector command embedded.

The most useful MCP servers are thin wrappers around existing command-line tools. The boilerplate the generator emits is designed for exactly that pattern: each tool you declare becomes a registered MCP tool whose handler shells out via execFile (TypeScript) or asyncio.create_subprocess_exec (Python). Output is captured, stderr is folded in as a fallback, and a 30-second timeout prevents a hung command from killing the whole server.

For commands with pipes or redirects - cat foo.json | jq ., grep -r ERROR > out, anything with $() or backticks - the generator flags the line and keeps shell=false by default. The right pattern there is to put the pipeline in a small wrapper script you control and have the MCP server invoke that instead of the raw shell expression. Trusting an LLM to compose pipes against your shell is how you end up with prompt-injection issues.

JSON-Schema input objects come from a heuristic: the generator scans each command for --flag and -f tokens and exposes them as optional string inputs the LLM can override. It is not a full parser - if your CLI uses positional args or complex types, you will want to tighten the schema by hand. The generator stamps everything as optional so a tool call with no arguments still works.

MCP Inspector is the official debugging UI. It speaks the same JSON-RPC protocol Claude Code does, but instead of an LLM picking tools, you click them. That makes it the right tool for two things: verifying a fresh server boots and answers listTools, and reproducing a tool failure you cannot trigger reliably through Claude.

The generated README includes the Inspector command tailored to your language. For TypeScript it is npx @modelcontextprotocol/inspector node dist/server.js; for Python it is npx @modelcontextprotocol/inspector uv run python server.py. Inspector opens at http://localhost:5173. Click a tool, fill in arguments, see the raw response and the JSON-RPC frame.

The fourth tab in the generator output is the exact JSON to drop into ~/.claude.json (or claude_desktop_config.json for the desktop app). It is a mcpServers map keyed by server name, with type, command, and args for stdio, or type: "http" and a URL for HTTP.

Two things to remember when you paste it. First, the args path is a placeholder - replace /absolute/path/to/{server-name}/dist/server.js with the real path on your machine. Second, restart Claude Code after editing the config; the file is read at startup, not watched.

If you are already maintaining a mcpServers block (e.g. you have a sibling tool like a Claude Code MCP config), merge the new entry in instead of replacing the whole map. Claude Code crashes on a malformed JSON file - keep a backup.