ai官小西

MCP Builder 技能评测 — AI Agent 工具开发所需的那块拼图

MCP Builder 工具生命周期自动化 — 从脚手架到完整 CI/CD

"MCP Builder"是那种 AI agent 圈子里人人都听说过但没人能指得出来的术语。问一个开发者它是什么，你会得到三种不同的答案："那个 Anthropic 的脚手架工具，""npm 上的 create-mcp-server 包，"或者"我以为那就是 MCP SDK。"

结果是三个答案都不对——更准确地说，都不完整。MCP Builder 生态系统还处于婴儿期，要搞清楚什么真正有用，需要一一揭开每个候选方案的面纱。

我们发现了什么

在 GitHub 上搜索 "mcp builder" 暴露了一个碎片化的图景：

项目 Stars 实际是什么
modelcontextprotocol/create-python-server 478 官方 Anthropic Python 脚手架模板
salacoste/mcp-n8n-workflow-builder 225 通过 MCP 管理 n8n 工作流（特定集成，非通用构建器）
npm create-mcp-server ~50 (npm) 基础 TypeScript 脚手架，v0.0.1，无 GitHub 仓库
hanweg/mcp-tool-builder 25 动态创建自身工具的 MCP 服务器

这对一个已成为 AI agent 工具集成标准的协议来说，生态薄得惊人。官方的 Anthropic 工具是唯一有意义的候选方案，而它也更像一个"模板生成器"而非"构建器"。

Anthropic create-python-server — 事实标准

位于 modelcontextprotocol/create-python-server（478 stars），这是一个交互式 CLI，用于脚手架化 Python MCP 服务器。运行 uvx create-python-server，回答几个提示（项目名、描述、工具名），就能得到一个功能完整的 MCP 服务器：

  • server.py 入口点，使用 stdio 传输
  • pyproject.toml 含 MCP SDK 依赖及入口点
  • README.md 含设置说明
  • 一个基础工具示例（一个工具，一个参数）

生成的代码干净、简洁——约 60 行 Python，可以立即扩展。从零到运行中的 MCP 服务器大约 30 秒。

做对了什么： 速度。你在自己写完 import 语句之前，就已经从零到了可运行的 MCP 服务器。生成的代码遵循 MCP 最佳实践（异步处理、正确的工具注册、stdio 传输），新人不需学协议就能上手。

没做什么： 其他一切。它脚手架化了骨架，不是生产级服务器。没有测试模板，没有错误处理模式，没有日志设置，没有 Docker 配置，没有部署指导。它是 MCP 世界里的 create-react-app——上手很棒，但写完前 60 行后就得靠自己了。

npm create-mcp-server — 幽灵包

npm 包 create-mcp-server 存在，版本号 0.0.1。没有关联的 GitHub 仓库，没有文档，除了"一键创建 MCP 服务器"之外没有有意义的描述。安装并运行它会产生一个基础的 TypeScript 项目——和 Python 版类似，但更粗糙。

它存在。就这些。

生态真正缺失的是什么

真正的缺口不是脚手架化——而是增量工具开发。一旦有了骨架 MCP 服务器，添加新工具的过程是：

  1. 写工具函数（简单）
  2. 在服务器工具列表中注册（简单）
  3. 写测试（中等）
  4. 添加错误处理（中等）
  5. 文档化工具参数（容易忘）
  6. 更新 README 加示例（永远忘记）

步骤 3-6 是 MCP 服务器积累技术债务的地方。一个真正的 MCP Builder 应该自动处理这些——添加一个工具，脚手架就自动生成测试模板、错误处理包装器和文档存根。

为什么这对 Hermes 很重要

Hermes 既是 MCP 客户端，也是（潜在的）MCP 工具发布方。我们现有的 MCP 集成通过原生 MCP 工具运行，有 Chrome CDP MCP 服务器用于浏览器自动化。但每增加一个新工具都需要相同的手动接线。

一个 Hermes MCP Builder 技能不仅要脚手架化新服务器——还要：

  1. 生成 Hermes 原生工具包装器，将 MCP 工具桥接到 Hermes 的工具系统
  2. 自动文档化工具参数、返回类型和错误模式
  3. 生成集成测试，使用 webapp-testing 技能模式
  4. 维护变更日志，在工具添加或修改时更新

这是一个不同于 Anthropic create-python-server 解决的问题。他们的工具帮助人类创建新 MCP 服务器。Hermes MCP Builder 帮助 agent 创建、文档化和测试自己的工具。

实现草图

最小可行 Hermes MCP Builder 技能：

Hermes MCP Builder
├── 工具脚手架      — 写工具函数→自动注册→生成测试模板
├── 文档生成        — 提取参数类型→生成 Markdown 文档
├── 测试夹具        — 连接 webapp-testing 技能做集成测试
└── 注册更新        — 工具变更时更新技能清单

核心洞察：以对待代码生成的方式对待 MCP 工具创建——附带自动化质量循环。当 agent 编写新工具时，构建器：

  1. 按 MCP 规范验证实现
  2. 生成用有效和无效输入调用工具的测试
  3. 运行测试
  4. 通过后，文档化工具并注册

这把手动工具创建变成了自验证工作流。

值得采纳的

采纳： Anthropic create-python-server 作为新 Python MCP 服务器的脚手架基础。它干净、结构好，是官方标准。

在此基础上构建： 一个 Hermes MCP Builder 技能，增加：自动测试生成、参数文档提取、变更日志管理、Hermes 原生工具注册。这是生态尚未拥有的那一层。

跳过： npm create-mcp-server（太不成熟）、mcp-n8n-workflow-builder（太专用）、hanweg/mcp-tool-builder（太实验性）。

最终判断

不安装外部 MCP Builder——自己构建一个。脚手架工具存在但不足以满足 Hermes 的需求。一个覆盖完整工具生命周期（创建→测试→文档→注册）的 MCP Builder 技能，比采用任何现有工具更高杠杆。

从包装 Anthropic create-python-server 并添加测试生成、文档提取和 Hermes 工具注册的技能开始。作为 Hermes 技能发布，而非外部依赖。