把 Claude Code 接成可调用的 MCP 服务

Claude Code 不只能连接别人的 MCP server，也能把自己的一部分工具开放给其他 MCP client。入口是 claude mcp serve：外部应用启动一个本地子进程，通过标准输入输出发现并调用它暴露的能力。

这篇系列第 8 篇讨论的是连接方向反转后的架构：工具定义怎样复用，调用边界怎样变化，以及为什么接通协议不等于获得完整的交互式 Claude Code。对准备在 IDE 或自动化宿主中接入它的程序员，这些区别比启动命令更重要。

Claude Code 当服务端，究竟开放了什么

前七篇把 Claude Code 放在客户端位置：连接外部服务，发现工具，再让自己的 agent 循环使用这些工具。现在方向倒过来，由另一个应用发现并调用 Claude Code 暴露的工具。

原文用下面两条路径说明变化：

Claude Code as client:
  Claude Code → external MCP server → external tool

Claude Code as server:
  external MCP client → Claude Code MCP server → Claude Code tool

要看的是第二条路径的终点：调用落到 Claude Code 的工具实现。它不能直接证明外部应用获得了完整的 Claude Code 对话流程。

MCP 在这里仍然围绕两个接口工作：tools/list 用于发现能力，tools/call 用于执行调用。客户端与服务端描述的是一条连接中的角色，不是产品永远固定的身份。第 1 篇区分的 host、client、server，也应该放在具体连接里理解。

这让 MCP 的用途多了一种：一个已经支持 MCP 的 IDE 或自动化宿主，可以尝试复用 Claude Code 开放的工具。是否能替代自己的实现，要先看实际开放的工具集合。

为什么同一套工具可以换一个调用入口

Claude Code 内部的工具包含名称、描述、输入 schema 和执行实现。正常对话中，agent 循环把工具定义提供给模型，校验模型生成的参数，再执行选中的工具。

作者检查的源码路径显示，MCP 服务入口可以复用这些结构。收到 tools/list 时，它枚举对外暴露的工具，把输入 schema 转成 JSON Schema；收到 tools/call 时，它定位实现、检查可用性、校验参数、执行工具，再把结果包装成 MCP 响应。

可以复用的是工具定义和执行逻辑，需要重新确认的是调用环境与权限边界。

这也解释了它和第 4 篇的对应关系：此前是把外部 MCP 工具纳入 Claude Code 的工具目录，并加上服务端限定名称；现在则把内部工具定义通过 MCP 向外提供。两个方向都需要让另一组件知道「能做什么、参数是什么、怎样调用」。

对开发工具作者，这个设计有参考价值。业务操作如果已经有明确的参数契约和独立实现，就有机会接入不同调用入口。但原文展示的是 Claude Code 的实现观察，没有提供迁移成本或维护收益的对照数据，不能据此承诺复用一定便宜。

本地接入为什么不能只看启动成功

原文给出的启动命令是：

claude mcp serve

要注意这一行启动的是 stdio MCP server。调用方把 claude 作为本地子进程运行，传入 mcp serve 参数，通过标准输入输出通信；它并没有因此获得一个远程 HTTP 地址。

完整接入还包括启动子进程、完成 MCP 协商、请求 tools/list，然后对返回的工具名称发起 tools/call。进程生命周期和本地环境都是集成的一部分，这与第 3 篇讨论的子进程传输方式相呼应。

真正需要打问号的是权限和交互。作者明确提醒，共用底层工具实现，不代表外部调用继承了交互式会话的上下文、权限或用户确认流程。服务端有自己的运行条件，工具可用性也可能不同。

因此，第 5 篇的权限问题仍然成立：允许某个应用启动这个进程，就是允许它获得一条通向实际操作的调用路径。应该检查客户端配置和工具访问范围，不能因为协议协商成功，就把后续调用都视为安全。

原文没有列出完整的暴露工具清单，也没有交代每类工具的确认行为。这些需要在目标环境中验证。

我的判断

我认为最有价值的地方，是把「官方支持的入口」和「从源码推导的架构结论」分开了。按原文陈述，公开文档已经明确提供 claude mcp serve；内部 schema 转换与工具复用，则来自作者检查的源码路径。

它不是一篇性能实测。原文没有接入耗时、调用成功率，也没有与自建 MCP server 的对照结果。能够支持的结论是这种连接方式存在，并且有复用工具抽象的实现依据。

选择上也要看目的。已有 MCP 宿主，希望使用 Claude Code 实际暴露的能力，可以评估这个入口；如果需要自行稳定控制工具契约和权限交互，自建 MCP server 仍然是应当比较的方案。原文没有证明前者能覆盖后者。

另外，源码观察没有附带明确版本或提交标识，具体实现是否适用于读者安装的版本，文章没说清。接入时应以实际返回结果为准。

能拿来做什么

• 如果正在给 IDE 或本地自动化宿主接入 MCP，先配置启动 claude mcp serve，完成协商并保存 tools/list 的结果，确认所需工具确实存在。
• 为准备使用的工具验证参数校验、正常返回和错误返回，同时记录调用是否需要额外交互，避免按交互式会话的体验推断服务端行为。
• 如果正在设计自己的工具层，可以参考它将名称、描述、输入 schema 与执行实现组织起来的方式，让对话入口和 MCP 入口复用同一操作定义。
• 把子进程启动配置、本地环境和工具访问范围一起纳入接入检查，明确哪个应用能够发起哪些操作，再决定是否扩大使用范围。