mcp-builderlisted

# Building an MCP server MCP (Model Context Protocol) lets Claude Code call external tools through a uniform protocol. A server exposes a set of tools; the client (Claude Code) discovers them and calls them with JSON arguments. Good MCP servers are small, named clearly, and return structured errors. ## When to trigger - The user asks to build, scaffold, or extend an MCP server. - A project imports `@modelcontextprotocol/sdk` (JS/TS) or the `mcp` package (Python). - The user wants Claude to talk to a system that does not yet have a tool, and a one-off Bash command is not enough. ## Transport: stdio vs HTTP vs SSE Pick the transport before writing any tools. - **stdio** - default and simplest. The server is a subprocess Claude Code launches; messages go over stdin/stdout. Use this for local-only tools (filesystem, local DB, CLI wrappers). No auth, no ports. - **HTTP** (streamable) - use when the server must be shared across machines, run inside Docker on a remote host, or sit behind auth. More moving parts: you own the port, TLS, and tokens. - **SSE** - older HTTP variant. Avoid for new servers unless a client requires it. Default to stdio. Upgrade to HTTP only when stdio cannot work. ## Tool schema Each tool needs three things: - `name` - kebab-case or snake_case, unique within the server. Short and concrete: `read_invoice`, `list_buckets`. - `description` - the prose Claude sees when deciding whether to call the tool. This is the single most important field. See belo