📚 系列导航：上一篇 Hermes Agent 工具系统教程 已经讲清“工具系统与渐进式工具披露”；本篇聚焦 Hermes Agent MCP 配置；下一篇 Hermes Agent Gateway 配置指南 继续学习“Gateway 消息平台与插件机制”。
先给结论：Hermes 同时占了 MCP 的两端。 它既能作为客户端连接外部 MCP Server，也能通过 hermes mcp serve 把自己的会话能力暴露给 Claude Code、Cursor、Codex 等 MCP 客户端。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes MCP 的客户端与服务端方向
MCP 是个连接协议，规定了 agent 和外部工具怎么对话。绝大多数教程只讲一个方向：你的 agent 作为 client，去连一个外部的 MCP Server，把它的工具拿过来用。
这没错，但只说了一半。一个协议有两端，Hermes 两端都占了。
我用一个更生活化的类比。MCP 像 USB-C 接口：你的电脑可以插 U 盘读数据（当 host），也可以插到别的电脑上被当成移动硬盘读（当 device）。Hermes 同时是 host 和 device。它能调外部的 MCP Server，也能把自己变成一个 MCP server，让别的 agent 来调它。
把这两个方向掰开讲，顺带把中间夹着的第三件事—官方审核目录—也讲了。
Hermes 作为 MCP Client 连接外部服务
这是旧版本就有的能力，但底子打得很扎实。源码里读到，它支持三种传输方式（transport），对应三种部署形态的 server。
| 传输方式 | 跑在哪 | 典型场景 |
|---|---|---|
| stdio | 本地子进程 | 本机装的工具,启动一个进程通过标准输入输出对话 |
| HTTP(StreamableHTTP) | 远程服务 | 云端托管的 MCP,比如 Linear 这种自带服务的产品 |
| SSE | 远程服务(流式) | 需要服务端持续推送的长连接场景 |
配置写在 ~/.hermes/config.yaml 的 mcp_servers 里。连上之后，外部 server 的工具会被注册进 Hermes 自己的工具表，模型调它们和调内置工具没有任何区别。这一点很关键—对模型来说，「web_search」和某个外部 MCP 给的工具长得一样，它不需要知道工具是哪来的。
per-server 还能各自配细节：超时时间、这个 server 的工具能不能并发调、要不要带 Bearer 鉴权头、要不要允许 server 反向发起 LLM 请求。这些都是给真实生产环境用的螺丝。
真正讲究的是 OAuth 那一块。Hermes 实现了完整的 MCP OAuth2.1 握手：动态客户端注册（DCR）、PKCE、token 自动刷新全都有。这意味着像 Linear 这种自带 OAuth 的远程 MCP，你本地什么都不用装，agent 第一次调它时自动走授权流程，拿到 token，过期了自动续。这是把「连一个需要登录的外部服务」这件麻烦事，做到了用户基本无感。
Hermes MCP 官方目录与安装入口
旧版本接 MCP 有个隐藏门槛：你得自己上 GitHub 找一个可信的 MCP server，自己读它的文档，自己写 config。找错了、配错了、连到一个有问题的 server，风险全是你的。
新版本补上了这个缺口，做法是搞了一个 Nous 官方审核目录。形态和它的 skill 目录一样：敲 hermes mcp 进一个交互式选择器，挑一个，一键安装，需要的凭据安装时提示你填，自动写进本地的 .env 。
「在目录里=已审核」：进这个官方目录的 MCP，都是经过 PRreview 合进来的。这等于 Nous 替你做了一道可信筛选，你不用再赌一个陌生的 GitHub 仓库安不安全。
这里要按事实说话。我见过有材料讲「MCP 让 Hermes 接入 6000 多个应用」，这个数字在 v0.16.0 的源码和发布说明里我没找到一手出处，不能这么写。准确的口径是两句话：
第一，能力上，Hermes 支持连接任意一个 MCP server（stdio/HTTP/SSE 三种都行），README 的原话是「Connect any MCP server」。理论上整个 MCP 生态它都能接。
Hermes v0.16.0 官方 MCP 目录
| 目录里的 MCP | 连接方式 | 特点 |
|---|---|---|
| Linear | 远程 HTTP + 原生 OAuth 2.1 | 本地零安装,hermes mcp install linear,授权即用 |
| n8n | stdio 桥接(git clone + venv) | 暴露 11 个工具,默认只开 8 个只读的,写操作(激活/停用/读容器日志等)默认裁掉,按需自己开 |
n8n 这个默认配置值得多看一眼。它默认关掉了所有会改东西的工具，只留只读的，你想用写操作得自己手动打开。这是一种「默认最小权限」的设计姿态—先给你看的能力，改的能力你得明确要。这种克制在 agent 工具里不常见。
到了最新版本，这个目录还搬进了浏览器后台面板。enable/disable 直接网页上点，不用再 SSH 登进服务器改 config.yaml。对不想碰命令行的人，这一步挺重要。
Hermes 作为 MCP Server 提供会话能力
这是最容易被忽略、但我觉得最有意思的方向。
敲一行 hermes mcp serve ，Hermes 会起一个 stdio 的 MCP server。这时候它不再是调工具的一方，而是被调的一方。Claude Code、Cursor、Codex 这些本身是 MCP client 的工具，可以反过来把 Hermes 当成一个外部工具来用。
它对外暴露什么能力？源码里数到 10 个工具，围绕「会话」这件事：列出当前所有会话、读某个会话的消息历史、往会话里发消息、轮询新事件、管理审批请求，外加一个列出所有频道的工具。而且这些操作是跨平台的，你在 Telegram、Discord、飞书上连的所有会话，都能通过这一个 MCP 接口统一访问。
翻译成人话：你可以在 Claude Code 里，直接读和回你 Telegram 上和 Hermes 的对话。Hermes 成了一个「会话中枢」，别的 agent 通过 MCP 接进来，就能操作它管着的一堆消息平台。
💡 核心建议
源码注释里有句话很有意思，说这套接口「对标 OpenClaw 的 9 工具 MCP 桥」，Hermes 多给了一个频道列表工具凑成 10 个。这是开源圈互相借鉴的常态—看到对手做得好的接口形态，照着做一个还更全。写书时这种一手细节比空泛的「功能强大」有说服力得多。
Hermes MCP 与原生工具的选择方法
讲完两个方向，得回答一个实际问题：Hermes 里很多外部产品（Spotify、飞书、Home Assistant 这些）是直接写成原生工具的，没走 MCP；而 Linear、n8n 走的是 MCP。同样是接外部服务，凭什么有的原生有的 MCP？我从源码的取舍里，归纳出一条大致的判据。
💡 推荐
用 MCP：①这个服务本身已经提供了官方 MCP Server（比如 Linear 自带远程 MCP，接上就行，何必重写一遍）；②你想接的是「任意」第三方，数量无上限，不可能一个个写原生工具；③工具集会频繁变动，交给 server 那边维护更省心。
不推荐：
用原生工具：①这个集成是 Hermes 想深度打磨、做到极致体验的（Spotify 七个工具覆盖播放/设备/歌单，比 MCP 桥更顺手）；②需要和 Hermes 内部机制紧密耦合（比如飞书文档要配合记忆系统）；③调用频率高、对延迟敏感，少一层 MCP 协议开销。
说到底，MCP 是「广度」的解法，原生工具是「深度」的解法。要接得多、接得杂、接别人已经做好的，用 MCP；要接得精、接得深、要自己掌控体验，写原生工具。Hermes 两条路都留着，我觉得这不是骑墙，是在不同需求上各取所长。
还有一层考虑藏在上一节讲过的 progressive tool disclosure 里。MCP 接多了，几十上百个工具定义会把模型的上下文撑爆。所以 Hermes 对 MCP 工具默认走「按需暴露」—不直接全列给模型，而是让模型先搜索再调用。这也解释了为什么不是所有东西都该塞进 MCP：核心高频的能力做成原生工具常驻，外围长尾的能力走 MCP 按需加载，两套机制配合着用，上下文才不会被工具定义吃光。
下一章我们离开工具层，去看 Hermes 连接的另一个维度：它现在能在二十多个平台上和你对话，而那个把它们缝在一起的 Gateway，本身就是会自己生长的。
常见问题
Hermes Agent 支持哪些 MCP 连接方式？
原稿覆盖本地 stdio、远程 HTTP 和 SSE 三种方式，并说明带 OAuth 的远程服务如何完成授权。实际配置键应以当前官方文档为准。
Hermes Agent 能作为 MCP Server 吗？
可以。Hermes 可以通过 MCP 服务端入口把会话相关能力提供给 Claude Code、Cursor、Codex 等客户端，具体工具数量会随版本变化。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。