§17MCP的两个方向
MCP in Two Directions
大多数人理解的MCP是单向的：让自己的agent去调别人的工具。Hermes把这件事做成了双向——它既是一个会逛官方商店一键装插件的客户端，也是一个能被Claude Code、Cursor反过来调用的服务端。同一个协议，两个方向，这是第一版之后最值得讲的变化之一。
先把「方向」这件事说清楚
MCP是个连接协议，规定了agent和外部工具怎么对话。绝大多数教程只讲一个方向：你的agent作为client，去连一个外部的MCP server，把它的工具拿过来用。
这没错，但只说了一半。一个协议有两端，Hermes两端都占了。
我用一个更生活化的类比。MCP像USB-C接口：你的电脑可以插U盘读数据（当host），也可以插到别的电脑上被当成移动硬盘读（当device）。Hermes同时是host和device。它能调外部的MCP server，也能把自己变成一个MCP server，让别的agent来调它。
方向一方向二
调外部server
同一个MCP协议
Hermes当client Hermes当server被别的agent调
把这两个方向掰开讲，顺带把中间夹着的第三件事——官方审核目录——也讲了。
方向一：Hermes作为client去调外部server
这是旧版本就有的能力，但底子打得很扎实。源码里读到，它支持三种传输方式（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 OAuth 2.1握手：动态客户端注册（DCR）、PKCE、token自动刷新全都有。这意味着像Linear这种自带OAuth的远程MCP，你本地什么都不用装，agent第一次调它时自动走授权流程，拿到token，过期了自动续。这是把「连一个需要登录的外部服务」这件麻烦事，做到了用户基本无感。
中间夹着的事：从「自己找」到「官方商店」
旧版本接MCP有个隐藏门槛：你得自己上GitHub找一个可信的MCP server，自己读它的文档，自己写config。
找错了、配错了、连到一个有问题的server，风险全是你的。
新版本补上了这个缺口，做法是搞了一个Nous官方审核目录。形态和它的skill目录一样：敲hermes mcp进一个交互式选择器，挑一个，一键安装，需要的凭据安装时提示你填，自动写进本地的.env 。
「在目录里=已审核」：进这个官方目录的MCP，都是经过PR review合进来的。这等于Nous替你做了一道可信筛选，你不用再赌一个陌生的GitHub仓库安不安全。
这里要按事实说话。我见过有材料讲「MCP让Hermes接入6000多个应用」，这个数字在v0.16.0和v0.22.2的源码和发布说明里我都没找到一手出处，不能这么写。准确的口径是两句话：
第一，能力上，Hermes支持连接任意一个MCP server（stdio/HTTP/SSE三种都行），README的原话是「Connect any MCP server」。理论上整个MCP生态它都能接。
第二，官方审核目录（optional-mcps）的规模。6月写上一版时它只收录了两个：Linear（远程HTTP加原生OAuth）和n8n（一个本地stdio桥，暴露11个工具、默认只开8个只读的）。四个月后，这个目录长到了65个，Airtable、Asana、Atlassian、Cloudflare、Figma、GitHub、Linear、Notion、Sentry、Stripe、Supabase、Vercel都在里面，§08里浏览器面板的MCP页就是它，每个条目一个INSTALL按钮。
当时我专门夸过的那个n8n桥，反倒下架了：已经装了的还能继续用，但目录里不再提供，换成了n8n-official ，直连n8n官方的HTTP接口，浏览器OAuth登录，不需要本地桥，也不需要API key。这个替换的方向和Linear一致：能用对方官方托管的MCP，就不在本地维护一个桥。
装的方式也更省事了。命令行有hermes mcp catalog看目录、hermes mcp install linear装；在对话里直接说「帮我接上Linear的MCP」，它会弹一张设置卡，桌面App里是对话框，命令行里是一个面板。需要登录的走浏览器授权，v0.22还加了设备码登录（hermes mcp login 服务名--flow device ），适合在没有浏览器的服务器上用。
再往上一层，v0.22把桌面App里的MCP页换成了Connectors页：托管的app连接（Linear、Notion这类，在聊天里说一声、浏览器登录一次就能用，不需要Nous账号）和MCP合并成一个列表，同一个服务还能挂多个账号，比如工作和个人各一个。命令行对应hermes connectors ，对话里是/connectors 。
方向二：Hermes把自己暴露成MCP server
这是最容易被忽略、但我觉得最有意思的方向。
敲一行hermes mcp serve ，Hermes会起一个stdio的MCP server。这时候它不再是调工具的一方，而是被调的一方。Claude Code、Cursor、Codex这些本身是MCP client的工具，可以反过来把Hermes当成一个外部工具来用。
它对外暴露什么能力？源码里数到10个工具（v0.22.2还是10个，名单微调过），围绕「会话」这件事：列出当前所有会话、读某个会话的消息历史和附件、往会话里发消息、轮询和等待新事件、查看和回应待审批的请求，外加一个列出所有频道的工具。而且这些操作是跨平台的，你在Telegram、Discord、飞书上连的所有会话，都能通过这一个MCP接口统一访问。
翻译成人话：你可以在Claude Code里，直接读和回你Telegram上和Hermes的对话。Hermes成了一个「会话中枢」，别的agent通过MCP接进来，就能操作它管着的一堆消息平台。
核心建议
源码注释里有句话很有意思，说这套接口「对标OpenClaw的9工具MCP桥」，Hermes多给了一个频道列表工具凑成10个。这是开源圈互相借鉴的常态——看到对手做得好的接口形态，照着做一个还更全。写书时这种一手细节比空泛的「功能强大」有说服力得多。
什么时候用MCP，什么时候用原生工具
讲完两个方向，得回答一个实际问题：Hermes里不少外部产品（飞书这类，还有6月时的Spotify、Home Assistant，现在这两个搬去了插件目录）是直接写成原生工具或插件的，没走MCP；而Linear、n8n走的是MCP。同样是接外部服务，凭什么有的原生有的MCP？
我从源码的取舍里，归纳出一条大致的判据。
| 推荐 | 不推荐 |
|---|---|
| 用MCP：①这个服务本身已经提供了官方MCP server | 用原生工具：①这个集成是Hermes想深度打磨、做到 |
| （比如Linear自带远程MCP，接上就行，何必重写一 | 极致体验的（Spotify七个工具覆盖播放/设备/歌单，比 |
| 遍）；②你想接的是「任意」第三方，数量无上限， | MCP桥更顺手）；②需要和Hermes内部机制紧密耦合 |
| 不可能一个个写原生工具；③工具集会频繁变动，交 | （比如飞书文档要配合记忆系统）；③调用频率高、 |
| 给server那边维护更省心。 | 对延迟敏感，少一层MCP协议开销。 |
说到底，MCP是「广度」的解法，原生工具是「深度」的解法。要接得多、接得杂、接别人已经做好的，用MCP；要接得精、接得深、要自己掌控体验，写原生工具。Hermes两条路都留着，我觉得这不是骑墙，是在不同需求上各取所长。
还有一层考虑藏在上一节讲过的progressive tool disclosure里。MCP接多了，几十上百个工具定义会把模型的上下文撑爆。所以Hermes对MCP工具默认走「按需暴露」——不直接全列给模型，而是让模型先搜索再调用。
这也解释了为什么不是所有东西都该塞进MCP：核心高频的能力做成原生工具常驻，外围长尾的能力走MCP按需加载，两套机制配合着用，上下文才不会被工具定义吃光。
下一章我们离开工具层，去看Hermes连接的另一个维度：它现在能在二十多个平台上和你对话，而那个把它们缝在一起的Gateway，本身就是会自己生长的。