MCP Builder
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 description = an unused or misused tool.
- Typed, validated inputs — a JSON-Schema for each tool; required vs optional explicit; enums over free strings where possible. Reject bad input with a clear message, don't guess.
- Useful returns & errors — return structured, model-readable results; on failure return an actionable error ("no invoice with id X") not a stack trace. Never crash the server on bad input.
- Least privilege — a tool does one scoped thing; destructive actions are explicit and, where possible, confirmable. Don't expose raw SQL / shell unless that is genuinely the product.
Checklist
Protocol, SDK skeletons, transport, and testing
Concrete server skeletons (TypeScript + Python), stdio vs. HTTP transport choice, resources/prompts (not just
tools), and the test loop (MCP Inspector → real client): references/building.md.
Invariant rules
- Design the tools before writing them — task-shaped, few, clearly described.
- Validate every input — schema-checked; bad input returns an error, never crashes.
- Errors are for the model — actionable text it can recover from, not raw traces.
- Secrets via env only — never hardcode credentials the server needs.
- Prove it with a real client — a server that only "looks right" is untested.
1---2name: mcp-builder3description: Build a Model Context Protocol (MCP) server so an AI client can call your tools/resources: design tool schemas, pick a transport, handle errors, and test it. For exposing an API, database, or service to Claude and other clients.4---56# MCP Builder78<!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside9 Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions10 truncated or dropped, which strips the very keywords a match depends on. -->11Trigger phrases: "MCP server", "build an MCP", "model context protocol", "expose tools to Claude", "MCP tool"1213An MCP server exposes **tools** (actions the model can call), **resources** (data it can read), and **prompts**14(reusable templates) to any MCP client over a standard protocol. The whole job is: **design a small set of clear,15well-described tools, validate their inputs, return useful errors, and prove it works with a real client.** The16protocol is easy; the design of the tools is what makes the server good or useless.1718> **Kit adaptation (local, .claude/):** Stack-agnostic — TypeScript (`@modelcontextprotocol/sdk`) or Python19> (`mcp` / FastMCP) are the maintained SDKs; match the project's language. §4 Prohibitions apply (no AI trace in20> generated code/strings). Secrets (API keys the server needs) go via env, never hardcoded — the kit's secret gates apply.2122## Design first (the tools ARE the product)23- **Few, purposeful tools** — expose *tasks*, not a 1:1 mirror of every API endpoint. "create_invoice" beats "post_v2_billing_documents".24- **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 description = an unused or misused tool.25- **Typed, validated inputs** — a JSON-Schema for each tool; required vs optional explicit; enums over free strings where possible. Reject bad input with a clear message, don't guess.26- **Useful returns & errors** — return structured, model-readable results; on failure return an actionable error ("no invoice with id X") not a stack trace. Never crash the server on bad input.27- **Least privilege** — a tool does one scoped thing; destructive actions are explicit and, where possible, confirmable. Don't expose raw SQL / shell unless that is genuinely the product.2829## Checklist30- [ ] Tools chosen by task, not by mirroring endpoints31- [ ] Each tool has a clear description (what · when · returns) and a JSON-Schema input32- [ ] Inputs validated; bad input → clear error, not a crash33- [ ] Returns are structured and model-readable; errors are actionable34- [ ] Transport chosen (stdio for local, HTTP/SSE for remote) — see references35- [ ] Secrets via env; no hardcoded keys36- [ ] Tested against a real client (Inspector + a live client)3738---3940## Protocol, SDK skeletons, transport, and testing41Concrete server skeletons (TypeScript + Python), stdio vs. HTTP transport choice, resources/prompts (not just42tools), and the test loop (MCP Inspector → real client): **`references/building.md`**.4344## Invariant rules451. **Design the tools before writing them** — task-shaped, few, clearly described.462. **Validate every input** — schema-checked; bad input returns an error, never crashes.473. **Errors are for the model** — actionable text it can recover from, not raw traces.484. **Secrets via env only** — never hardcode credentials the server needs.495. **Prove it with a real client** — a server that only "looks right" is untested.
byerlikaya