MCP Builder：LLM 工具生态最前沿的工程指南，让 Agent 真正用好外部 API

LLM 军备竞赛打到现在，拼的不只是模型本身——谁能让 Agent 真正调用外部工具，谁就掌握了下一代 AI 的入口。

而这个入口的事实标准，正在快速收敛到一个协议上：MCP（Model Context Protocol）。 Anthropic 在 2025 年底把 MCP 开放出来，现在 Claude Code、Cursor、Gemini CLI、Windsurf 全部原生支持。简单说：MCP 就是 AI 时代的 USB 接口——有了它，AI 能调用任何外部 API、数据库、SaaS 服务。

问题来了：怎么写一个真正好用的 MCP Server？

99% 的开发者会直接去把官方 SDK 文档翻译成中文。但这个方向错了——因为 MCP Server 的质量瓶颈从来不是”会不会写代码”，而是Agent 会怎么用它。API 设计得不好，Agent 用起来就会频繁出错、上下文爆炸、工具调用乱成一锅粥。

MCP Builder 这个 Skill 就是来解决这个问题的。它不是 API 文档的搬运工，而是一套完整的 MCP Server 构建方法论：

• Phase 1：先做深度调研，搞清楚这个 API 对 Agent 来说应该怎么暴露工具——是单个端到端工具，还是多个原子工具？错误信息怎么写才能让 Agent 自动纠错而不是卡死？
• Phase 2：按语言分 Python（FastMCP）和 TypeScript 两套最佳实践，工具注册、输入校验（Pydantic/Zod）、响应格式、错误处理，全给出模板。
• Phase 3：代码 review + 自动化测试，重点检查 DRY、类型安全、文档完整性。
• Phase 4：用 Agent 实测，收集反馈后迭代改进。

最让我觉得有价值的是它强调的“Build for Workflows, Not Just API Endpoints”原则：不要简单把 API 端点包装成工具，而是要设计出 Agent 能完成完整任务的工具集合。典型的例子是：与其暴露 `get_availability(date)` 和 `create_event(date, title)` 两个工具，不如合并成一个 `schedule_event(title, date)`——前者会让 Agent 面临竞态条件和更多上下文消耗，后者才是 Agent 友好的设计。

目前支持 Python（FastMCP）和 TypeScript 两种实现路线。文档里还附了 MCP 协议规范的完整链接、Python SDK 和 TypeScript SDK 的官方 README，以及两份语言专项最佳实践指南。

如果你正在做 LLM 应用开发，或者想让自己的 API 服务能被各种 Agent 调用，这个 Skill 是目前能找到的最完整的工程指南。站在 LLM 工具生态的角度，MCP 很可能就是下一个 Docker——越早掌握构建方法的人，越有先发优势。

GitHub：ComposioHQ/awesome-claude-skills

GitHub: https://github.com/ComposioHQ/awesome-claude-skills/tree/master/mcp-builder