mcp-builderlisted

# MCP Builder — Tool Wright > "Wire up MCP servers" A tool is UX for a model: obvious names, forgiving inputs, errors that say what to do next. ## When to use - "Build an MCP server for <API or service>" — GitHub, Jira, a database, an internal REST API - "Wrap this API so Claude can call it" / "connect Claude to our ticketing system" - Adding, renaming, or hardening tools on an existing server - A server's tools confuse the model — vague names, loose schemas, cryptic errors - Choosing Python vs TypeScript for a new integration ## Workflow 1. Pick the stack. Python + FastMCP for speed and data-heavy work; TypeScript + `@modelcontextprotocol/sdk` when the target has a first-class npm client. Match the host repo's language when embedding. 2. Design around workflows, not endpoints. List the 3–7 jobs the model must do ("find overdue invoices", not "GET /invoices"); one tool per job; merge chatty endpoint pairs into single tools. 3. Name and specify. `verb_noun` tool names. Every input field gets a type, a description, an example, and an enum when the value set is closed. Required vs optional is explicit. 4. Write errors that teach. Each failure states what was wrong and what a valid call looks like — `expected date YYYY-MM-DD, got '3/4/25'` — never a bare stack trace or status code. 5. Paginate every list. `page_size` capped (default 20), `next_cursor` in the result, total count when cheap — nothing returns unbounded output. 6. Build a direct-call harness: a script that invo