MCP Server Developer Starter

Who this pack is for

You've used MCP servers in Claude Code, Cursor, or Codex CLI for a while. Now you want to build one — wrap your internal API, your private CRM, your custom tool — so any MCP-speaking agent can call it. This pack is the producer-side starter; if you only want to install existing servers, see the MCP Server Stack pack instead.

The ten picks here cover the full loop: pick an SDK in the language you already write, scaffold with a higher-level framework so you skip the boilerplate, debug interactively in MCP Inspector against the live server, then publish to a registry so other developers' agents can discover and install you.

Install in this order

1. MCP Inspector — install this first. It's the official web UI for connecting to any MCP server (stdio or HTTP), listing tools, sending test calls, and inspecting raw JSON-RPC messages. You'll keep it open in a browser tab for the entire build. Trying to debug an MCP server without Inspector is like writing a web app without DevTools.
2. Microsoft MCP — Official TypeScript SDK — the canonical SDK if you live in Node. Defines the Server class, transports (stdio, HTTP), and the typed RequestHandler schemas. Use this when you want full control or you're writing reference samples.
3. MCP Python SDK — the official Python SDK. Same shape as the TS one: Server, stdio_server, request handlers. Pick Python if your tool calls already use Python libraries (data, ML, scraping).
4. FastMCP — Python Framework — the Flask-vs-Werkzeug of MCP. Decorator-based, dramatically less boilerplate. @mcp.tool() on a normal function and you have a server. Use this for 90% of Python MCP servers; drop to the raw SDK only when you need fine-grained transport control.
5. FastMCP — TypeScript Framework — same philosophy on the Node side. server.addTool({ name, parameters, execute }) and you're done. Pairs with the official TS SDK as needed.
6. mcp-go — Build MCP Servers in Go — the Go SDK. Use this when latency or single-binary deploy matters (serverless cold start, embedded in a CLI, Docker scratch image).
7. Build Your Own MCP Server — Step-by-Step Guide — the tutorial you read before your first commit. Covers JSON-RPC framing, tool discovery, error envelopes, and the three transports. Saves you a half-day of reading specs.
8. Claude Official Skill: mcp-builder — Anthropic's official Claude skill for scaffolding MCP servers. Plug into Claude Code, describe the tool you want, and it writes the SDK boilerplate (manifest, request handlers, type stubs). Great for the first server; you'll outgrow it on the third.
9. Smithery — MCP Server Registry & Installer — the de-facto registry. Publishing here gets your server installable via npx smithery install your-server and listed alongside hundreds of others. Required reading for visibility.
10. awesome-mcp-servers — MCP Directory Index — the GitHub-hosted curated index. PR your server in once it's stable. Different audience from Smithery (devs browsing on GitHub vs agents auto-discovering), so do both.

How they fit together

Pick an SDK:    Microsoft TS  ─┐
                MCP Python   ──┼─▶  scaffold with a framework
                mcp-go       ─┘       │
                                      ├─ FastMCP Python
                                      ├─ FastMCP TypeScript
                                      └─ Claude mcp-builder skill
                                              │
                                              ▼
                                       MCP Inspector
                                       (live debug + test calls)
                                              │
                                              ▼
                                       Publish
                                       ├─ Smithery registry
                                       └─ awesome-mcp-servers PR

The four-step loop SDK → framework → Inspector → registry is the entire job. Most failure modes (no agent can find your tool, tool calls hang, schema validation errors) come from skipping Inspector. Don't skip Inspector.

Tradeoffs you'll hit

• Raw SDK vs FastMCP — Raw SDK = 80 lines for a hello-world server, full control over transports and middleware. FastMCP = 12 lines, decorator-based, opinionated. Start with FastMCP; drop to raw SDK only when you hit a wall (custom auth, non-stdio transport you're inventing).
• TypeScript vs Python vs Go — TS has the most reference samples and the largest ecosystem of agent hosts speaking it natively. Python wins when your tool body is already Python (pandas, sklearn, scrapy). Go wins for single-binary deploys and tight latency.
• Smithery vs awesome-mcp-servers — Smithery is machine-readable (agents auto-install). awesome-mcp-servers is human-readable (developers browse on GitHub). Different funnels — submit to both.
• mcp-builder skill vs hand-written — The skill is great for the first server (writes correct boilerplate). It generates patterns you'll want to customize by server three; expect to outgrow it.

Common pitfalls

• stdio transport buffering — never write to stdout for logging. Logs go to stderr; stdout is reserved for JSON-RPC frames. Mixing them silently corrupts every message.
• Tool schema drift — your tool's input schema in the manifest must exactly match what your handler expects. MCP Inspector will surface the mismatch instantly; without it, you'll spend hours wondering why the agent passes query and your handler reads q.
• Long-running tools without progress — MCP supports progress notifications. If your tool takes >5 seconds, emit progress, or the host will assume it hung and time out.
• Forgetting to register on shutdown — handlers that hold resources (DB connections, file locks) need on_shutdown cleanup. Inspector won't catch this; you'll find it in production.
• Submitting to Smithery before the server is stable — version churn breaks installs for every agent that pinned to you. Tag a real v1.0.0 first, then publish.