接 GitHub、Jira、Slack，如果每个端点都在 Agent 内重写 schema、handler、分页和错误处理，工具系统会再次变成集成代码仓库。
MCP 的价值是让外部进程以统一协议声明和执行工具。对 Hermes 的核心循环来说，它们最终仍是 registry 中的普通工具。
这篇只回答一个问题：Agent 怎样复用社区已有工具，而不是为每个外部 API 重写一套 handler？
Hermes 给出的答案是：Hermes 作为 MCP client 发现外部 server 的工具，白名单过滤并加命名前缀，再注册进同一 registry；核心循环无需区分内置与外部工具。
统一的不是 API，而是发现和调用方式
GitHub 与 Jira 的业务接口仍然不同，MCP 并没有消除这些差异。它统一的是 Agent 如何发现工具 schema、如何发起调用以及如何通过 stdio 或 HTTP 传输结果。
Hermes 启动 server、获取工具列表，再为每个工具建立转发 handler。模型仍看到普通工具定义，不需要理解背后进程的技术栈。
进入 registry 前必须过滤和命名
一个 server 可能暴露五十个工具。全部注册会增加 schema token，也会让模型选择困难。Hermes 支持 include 白名单，把能力引入变成显式范围选择。
工具名增加 mcp_
外部进程隔离了运行时，也扩大了信任边界
MCP server 可以由 Node.js 或其他运行时实现，崩溃时不必拖垮 Agent 主进程。连接失败与运行中断线可以重试，恢复逻辑集中在连接管理层。
隔离不等于可信。外部进程看到哪些环境变量必须严格控制，不能为了方便把 LLM 密钥一起传入。它只应获得完成自身业务所需的 token。
同步注册表与异步协议之间需要桥
Hermes 的 registry.dispatch 是同步接口，MCP SDK 使用异步连接。系统通过后台事件循环维护连接，再把同步 handler 的调用转发过去。
这层桥接让核心循环保持不变，但产品运行状态仍应能暴露 server 是否在线、启用了哪些工具以及最近一次失败。
一个 MCP 工具如何进入 Agent
启动阶段，Hermes 读取 MCP server 配置，通过 stdio 或 HTTP 建立连接，再调用 list_tools 获取能力清单。系统先执行 include 白名单过滤，然后为工具加上 mcp_<server>_ 前缀，最后注册进已有 registry。
模型选择某个 MCP 工具后，核心循环仍然调用 registry.dispatch。对应 handler 把同步调用转交给后台事件循环，由 MCP client 执行 call_tool，再把外部 server 的结果转换成文本返回。
从模型视角看，这条链路与内置工具一致；从运维视角看，它多了外部进程、连接状态、重试和凭据边界。两种视角都成立，不能因为模型侧透明，就忽略运行侧新增的故障点。
因此，MCP 接入的完整验收应覆盖 发现成功、工具范围正确、命名无冲突、实际调用可用、秘密最小暴露，而不只是确认 server 进程已经启动。
三个容易走偏的地方
- 把主模型 API key 传给外部 MCP server，扩大秘密暴露范围。
- 不做白名单过滤，把大量无关工具一次性注册给模型。
- 忽略命名冲突和断线状态，调用时才发现能力不可用。
产品经理可以怎样评审
评审这项能力，可以先检查三条：
- MCP 接入成功不等于 server 启动成功，还要确认工具范围、命名和实际调用。
- 外部工具应遵循最小权限，只获取完成任务必需的环境变量。
- 工具越多不代表 Agent 越强，选择负担和上下文成本同样需要预算。
本文只讨论 Hermes 作为 MCP client 使用外部工具的路径，不延伸到协议全部能力。