mcp-server-scaffolderlisted

Starting an MCP server from a blog post means inheriting its mistakes — a vague tool description, a loose schema, the wrong transport for where it'll run. This skill scaffolds a **correct, runnable** server skeleton from a one-line description: it picks the SDK and transport for your case, generates a first tool that already follows the naming/schema/description discipline that makes a server usable, and leaves you with the exact commands to test and register it. ## When to use this skill - Starting a brand-new MCP server and you want a runnable skeleton with one good tool, not a pile of boilerplate. - You know *what* the server should expose but want the transport choice, schema shape, and project layout decided correctly up front. - Standing up a server to test an integration idea quickly, with Inspector testing already wired in. ## Instructions 1. **Clarify the capability and where it runs.** From the description, identify the first tool (one job, clearly named) and whether the server runs **local** (stdio) or **remote/shared** (Streamable HTTP). If it's ambiguous, default to stdio for a local prototype and note how to promote it to HTTP later. 2. **Pick the SDK and detect the ecosystem.** Match the project's language: the official Python or TypeScript MCP SDK, or a higher-level framework like [FastMCP](/tools/fastmcp) for Python. Check for an existing project to slot into (package manager, lockfile, conventions) rather than scaffolding in isolation. 3. **Generate the