04 把 OpenCode 自身暴露为 MCP 服务器 本节摘要:前三节讲了 OpenCode 作为 MCP 客户端(连别人的 server),这一节讲反向用法——把 OpenCode 自己暴露成 MCP server,让别的 Agent(如 Claude Code、Cursor)连进来用它的能力。这展示了 MCP 协议的对称性——同一套协议既可拉(pull)也可推(push),OpenCode 既是客户端也能是服务端。 一、反向用法:让别人连我 到目前为止,我们说的都是「OpenCode 连别人的 MCP server」。
本节摘要:前三节讲了 OpenCode 作为 MCP 客户端(连别人的 server),这一节讲反向用法——把 OpenCode 自己暴露成 MCP server,让别的 Agent(如 Claude Code、Cursor)连进来用它的能力。这展示了 MCP 协议的对称性——同一套协议既可拉(pull)也可推(push),OpenCode 既是客户端也能是服务端。
到目前为止,我们说的都是「OpenCode 连别人的 MCP server」。但 MCP 协议是对称的——OpenCode 也能反过来,把自己暴露成 MCP server,让别人连:
常规(客户端):OpenCode ──连──► 别人的 MCP server(用别人的工具) 反向(服务端):别人的 Agent ──连──► OpenCode(用 OpenCode 的能力)
这种反向用法让 OpenCode 成为「能力提供者」——别的 Agent 可以用 OpenCode 的读写文件、执行命令、搜索等能力,就像 OpenCode 用别的 server 的工具一样。
几个典型场景:
把 OpenCode 暴露成 MCP server 时,暴露的是它的工具能力——读、写、改、搜索、执行命令等。别的 Agent 连进来,看到的就是这些工具,调用方式和连普通 MCP server 一样。
别的 Agent ──连──► OpenCode(MCP server) │ ▼ 看到工具列表 [read, write, edit, grep, glob, bash, ...] │ ▼ 调用某个工具 read({ path: "xxx" }) │ ▼ OpenCode 执行,返回结果
注意:虽然 OpenCode 暴露的是工具,但权限仍然生效——连进来的 Agent 不是「全权限」,它受 OpenCode 权限规则约束(允许/询问/拒绝)。所以「暴露成 server」不等于「敞开后门」,治理一致。
这个反向用法体现了 MCP 协议的对称性——同一套协议既支持客户端角色,也支持服务端角色。这不是两套独立实现,而是同一协议的两个方向:
MCP 协议(一套) │ ├─ 客户端方向:连 server,用工具(OpenCode 平时这样) │ └─ 服务端方向:被连,提供工具(OpenCode 反向这样)
这种对称性让 MCP 生态很灵活——任何参与者既可以是「工具使用者」也可以是「工具提供者」,角色可动态切换。
这里有个值得提的联系:OpenWork(OpenCode 之上的平台)的 meta-MCP(OpenWork 教程第 7 章)某种程度上就是这个思路的延伸——把能力通过 MCP 暴露给任意 Agent。区别是:
后者更抽象、更强大,但思想源头是「把能力通过 MCP 暴露」这个对称模式。
读完第 10 章四节,你掌握了 OpenCode 与 MCP 的完整关系:
| 节 | 讲了什么 |
|---|---|
| 01 三种传输 | stdio / 流式 HTTP / SSE,怎么连 |
| 02 OAuth | 远程 server 的授权流程,认证身份 |
| 03 进注册表 | MCP 工具汇入注册表,受同一权限约束 |
| 04 反向暴露 | OpenCode 自己也能当 MCP server |
核心认知是:MCP 让 OpenCode 突破进程边界,但突破不等于失控——所有外部工具(进的或出的)都走同一套治理(权限/调度/输出边界)。第 11 章我们看 OpenCode 的其他扩展点:插件、技能、斜杠命令。
第 10 章结束。下一章讲 OpenCode 的其他扩展点——插件、技能、斜杠命令。