mcp-builderlisted

# MCP Builder <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "MCP server", "build an MCP", "model context protocol", "expose tools to Claude", "MCP tool" An MCP server exposes **tools** (actions the model can call), **resources** (data it can read), and **prompts** (reusable templates) to any MCP client over a standard protocol. The whole job is: **design a small set of clear, well-described tools, validate their inputs, return useful errors, and prove it works with a real client.** The protocol is easy; the design of the tools is what makes the server good or useless. > **Kit adaptation (local, .claude/):** Stack-agnostic — TypeScript (`@modelcontextprotocol/sdk`) or Python > (`mcp` / FastMCP) are the maintained SDKs; match the project's language. §4 Prohibitions apply (no AI trace in > generated code/strings). Secrets (API keys the server needs) go via env, never hardcoded — the kit's secret gates apply. ## Design first (the tools ARE the product) - **Few, purposeful tools** — expose *tasks*, not a 1:1 mirror of every API endpoint. "create_invoice" beats "post_v2_billing_documents". - **The description is the interface** — the model routes on it. Say what it does, when to use it, and what it returns, in plain language. A vague