菜单
Build a high-quality MCP server that exposes a service or API to an LLM through well-designed tools. Use when asked to create, scaffold, or add an MCP server, wrap an API as MCP tools, or expose a service to Claude/agents. Writes files, so it runs only when invoked explicitly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Accessibility and screen-reader support, built in from the start rather than bolted on. Claude treats a11y as an afterthought and reaches for clickable divs, skips alt text and labels, and removes focus rings. Use when building or editing any UI, page, or interactive component. Covers semantic HTML before ARIA, real buttons and links, accessible names, keyboard operability and focus management, headings and landmarks, contrast and motion, and how to actually test it. Most of it is free if you use the right element.
Service structure conventions for this codebase: routing, layering, and where code lives. Use whenever writing or modifying a service's server entry, route definitions, handlers, or adapters. Loads inline so it shapes structure as code is written.
Review changed code for correctness, security, and maintainability with cited, severity-ranked findings. Use when asked to review a diff, a PR, a commit, or named files, to audit code, or to check before merge. Runs isolated and read-only, reports findings, does not edit.
Scaffold a new microservice that follows the project's server/handlers/adapters architecture. Use when asked to create, scaffold, or add a new service or package. Writes files and may create a git branch, so it runs only when invoked explicitly.
Where CSS should live. Claude defaults to dumping a giant <style> block or scattering style="..." attributes instead of putting styles in a .css file and linking it. Use when building or editing a web page or component, or whenever about to write a style attribute or an embedded style block. Covers defaulting to an external stylesheet, why inline style attributes are a trap, and the few cases where inline is actually correct (dynamic values via custom properties, critical CSS, single-file artifacts, email).
Common pitfalls that are slow to troubleshoot and that tend to get "fixed" by going in circles, because the error message points nowhere near the actual cause. Use before and during git, project, and WSL work, checking a repo is initialized and node_modules is ignored, putting WSL projects on the right filesystem, opening a browser from WSL for auth, normalizing line endings, and matching import case. Check the layer here first instead of debugging the wrong one.
| name | mcp-builder |
| description | Build a high-quality MCP server that exposes a service or API to an LLM through well-designed tools. Use when asked to create, scaffold, or add an MCP server, wrap an API as MCP tools, or expose a service to Claude/agents. Writes files, so it runs only when invoked explicitly. |
| when_to_use | - User asks to build, scaffold, or add an MCP server - User wants to wrap an API, service, or database as MCP tools - User says "MCP server", "expose this as tools", "make this callable by an agent" - Do NOT auto-run; this writes files |
| disable-model-invocation | true |
| allowed-tools | Read, Write, Edit, Bash |
An MCP server is judged by one thing: whether an LLM can use its tools to finish real tasks. Tool count, endpoint coverage, and cleverness are means, not the goal. Build for the agent that will call it.
1. Understand the target. Read the service's API or schema first. Identify the handful of tasks a user actually wants done through it, not every endpoint. A wrapper that mirrors 60 REST routes one-to-one is worse than 8 tools shaped around real workflows.
2. Design the tools. This is where quality is won or lost.
verb_noun, scoped by service, for example github_create_issue, orders_find_by_customer. The name should tell the model when to reach for it.readOnlyHint, destructiveHint, or idempotentHint so the client can reason about safety.3. Implement. Shared infrastructure first (client, auth, pagination, error handling), then the tools on top. If the server touches a database, it follows the same kit rules as everything else: one shared client, data access through the adapter, StrictDB if installed otherwise the native driver, never Mongoose.
4. Test with evaluations. Write 10 realistic, multi-step questions a user would ask, then verify an LLM can answer each using only the tools. Solve each yourself first so you know the right answer. Failing evals point at a missing tool, a vague description, or output the model can't parse, fix those, not the eval.
src/
server.ts transport + registration, thin
client.ts the upstream API/service client (the one place it's touched)
tools/ one file per tool or tight tool group
schemas/ input/output schemas (zod)
evals/
evals.json the 10 questions and verified answers
Keep server.ts thin, the same discipline as api-conventions: it wires transport and registers tools, nothing more. Tool logic lives in tools/, upstream calls in client.ts. No file over 300 lines.