MCP Builder 技能：照着规范搭出 MCP 服务器

把「给 AI 接一个外部服务」拆成调研、设计、实现、评测四步，不再手写一堆样板。

写一个 MCP 服务器，难的不是调 API，而是想清楚：该暴露哪几个工具、参数怎么命名才不会被模型误用、返回内容要不要精简、失败时该返回错误还是空结果。这些问题官方文档里没有标准答案，大多数人第一版都是把 REST 接口一个个搬过去，结果工具太多、描述含糊，模型反而不会用。mcp-builder 是 anthropics/skills 里的官方技能，干的就是这件事：把建 MCP 服务器的过程拆成四个阶段，每一阶段给出检查清单和常见坑，让产出质量可控。

先定工具边界，而不是把所有接口搬上去

技能的第一步不是写代码，而是让你列清楚「用户会用什么句式提需求」。比如「帮我查一下上周未解决的错误」背后可能是两个工具（列项目、按时间筛问题），而不是把整个 API 的三十个端点全暴露。工具数量越多，模型选错的概率越高，上下文开销也越大。技能会推动你把能力收敛到 5–10 个粒度合适的工具，这一条对实际使用体验的影响远超代码质量。

两套实现路线：Python FastMCP 与 TypeScript SDK

Python 路线基于 FastMCP，用装饰器声明工具，代码量最少，适合快速验证、内部工具、数据脚本类服务。TypeScript 路线基于官方 MCP SDK，类型定义严格、发布到 npm 后跨客户端分发方便，适合要给别人用的服务。技能会把两条路线的项目结构、依赖声明、传输方式（stdio 还是 HTTP）都列出模板，不需要你从空目录开始搭。

工具描述当成产品文案来写

MCP 工具的 description 不是注释，而是模型决定「要不要调它」的唯一依据。技能里给了具体写法：第一句说清楚做什么，第二句说什么时候用、什么时候不要用，参数逐个说明单位与格式，枚举值要列全。反面例子是把接口文档原句贴进去，满是 object、string 这类词，模型看了不知从何下手。按这套规范改一遍，同一个服务器被正确调用的比例会明显上升。

自带评测环节，不靠「感觉能用」验收

技能要求你准备一批真实提问，逐条验证：该调工具的时候调了没有、参数填对了没有、返回结果能不能直接回答问题。这一步在官方文档里容易被跳过，但恰恰是最能暴露问题的地方。比如「查一下这个仓库最近的 issue」可能因为缺少分页参数而只返回十条，用户以为项目很冷清。评测清单跑一遍，这类隐性缺陷基本能抓出来。

使用上手：五步走完

1. 安装技能。npx skills add anthropics/skills --skill mcp-builder，或手动复制 skills/mcp-builder 到 ~/.claude/skills/。
2. 写需求清单。用三句话描述要连的服务、典型用户提问、以及不希望模型做的事（例如不允许删除操作）。
3. 让它输出工具设计。先只要工具列表和每个工具的描述，不写代码；确认边界合理后再进入实现。
4. 选路线实现。内部自用选 FastMCP，要分发选 TypeScript SDK；要求它同时给出 README 里的客户端配置片段。
5. 跑评测再上线。准备 5–10 条真实提问逐条试，记录哪些该调未调、哪些参数错了，回头改描述而不是改代码。

优点与不足

优点是它把经验性的东西变成了清单：工具粒度、描述写法、评测方法，这三块是新手最容易踩坑的地方。Apache-2.0 许可，可以直接改。技能本身不依赖具体业务，任何行业都能用。

不足在于边界：它只管服务器设计与实现，不管部署、不管鉴权、不管多租户隔离。要上生产，你得自己解决托管、密钥管理、限流这几件事。另外官方在仓库里明确写了这些技能是演示用途，实际行为可能与描述有差异，关键环节仍需自己审核代码。

适合谁

• 想把内部系统接给 AI 的后端工程师：比从零读 MCP 规范快很多。
• 已经在用 Claude Code 的开发者：本地工具链类 MCP（数据库、日志、监控）用这套流程半天能出一个可用版本。
• 要做工具分发的团队：TypeScript 路线加 npm 发布，客户端一行配置就能接。

下载与访问

• 仓库地址：https://github.com/anthropics/skills
• 技能目录：https://github.com/anthropics/skills/tree/main/skills/mcp-builder
• MCP 官方规范：https://modelcontextprotocol.io

获取与授权

本文属于「技能」分类的 AI 资源专栏，更多评测见分类页。