把 stdio MCP 转成 HTTP MCP：本地服务器也能远程安全调用

stdio 是 MCP 里最常见的传输方式，也是最受限制的一种：它只能作为客户端的本地子进程运行，任何不在同一台机器上的客户端都连不上它。 把 stdio MCP 转成 HTTP MCP，就是让这个本地服务器变成一个带 URL、可鉴权、可远程访问的标准端点——不需要改一行服务器代码。

MCP2Skill 做的就是这件事：它是一个桌面应用，可以导入任意协议的 MCP 服务（stdio、SSE、Streamable HTTP），统一运行，然后对外提供一个统一的 HTTP MCP 网关端点。你还可以给端点启用 API Key 鉴权，把它安全地暴露到外网。这篇文章给出完整的转换步骤。

为什么 stdio MCP 需要转成 HTTP

stdio 传输的工作方式是：客户端把 MCP 服务器作为自己的子进程拉起来，通过标准输入输出（stdin/stdout）通信。这个设计简单可靠，但带来三个绕不开的限制。

1. 只能本机使用

子进程通信的前提是客户端和服务器在同一台机器上。你的 filesystem MCP、本地数据库 MCP、跑在内网脚本上的 MCP，对于另一台电脑上的客户端、云端 Agent 或 CI 环境来说完全不可见。stdio 没有 URL，没有端口，没有"远程"这个概念。

2. 每个客户端各自拉起一份进程

谁连接 stdio 服务器，谁就要自己启动它。三个客户端用同一个 filesystem 服务器，内存里就有三个独立的进程。服务器升级时，每个客户端还要各自重启一遍。

3. 密钥散落在各客户端配置里

stdio 服务器的 API Key 通过环境变量注入，落在每个客户端的配置文件里。轮换一次密钥，你要找齐所有副本；想看这个服务器被谁调用了什么，没有任何集中的日志可言。

HTTP 传输则反过来：服务器是一个有 URL 的常驻进程，任何能到达这个 URL 的客户端都能连——而"谁能到达"就可以用鉴权来控制。这正是 MCP 官方规范把 Streamable HTTP 作为推荐 HTTP 传输、并把授权机制（OAuth 2.1 子集）只定义在 HTTP 传输上的原因：网络边界才是做安全边界的地方。

"stdio 转 HTTP"到底转了什么

转换的本质是传输层翻译，不是重写服务器。网关在中间同时扮演两个角色：对上游的 stdio 服务器来说，它是一个 MCP 客户端——拉起子进程、通过 stdin/stdout 对话；对你的 AI 客户端来说，它是一个 HTTP MCP 服务器——暴露 URL、处理鉴权、返回工具列表。

                          MCP2Skill 网关（桌面应用）
  Claude Code   ─┐        ┌────────────────────┐        ┌─► filesystem MCP   (stdio 子进程)
  Cursor        ─┼─ HTTP ─►  传输翻译 + 鉴权    ──stdio─┼─► github MCP        (stdio 子进程)
  云端 Agent    ─┘  一个URL └────────────────────┘  原样  └─► 内部 API MCP     (SSE/HTTP 原样转发)

这个翻译是双向的、协议透明的：客户端发出的 tools/list、tools/call 请求原样穿过网关到达 stdio 服务器，服务器的响应也原样返回。工具的行为没有任何变化——变化的只是"谁能连到它"和"怎么连到它"。

顺带一提，这个能力是通用的：SSE 或 Streamable HTTP 的远程 MCP 也可以导入，同样收敛到同一个 HTTP 网关端点后面。所以更准确的说法是——任意协议进，统一 HTTP 出。

准备工作

• 一台运行 MCP2Skill 的机器（下载安装见 mcp2skill.com），stdio 服务器就跑在这台机器上
• 至少一个现成的 stdio MCP 服务器（已有 Claude Code / Cursor 配置的最方便，可以直接导入）
• 如果要外网访问：一个启用 API Key 的打算（下面第 3 步），以及防火墙上放行网关端口

第 1 步：把 stdio 服务器导入 MCP2Skill

打开 MCP2Skill 的 MCP 页面，添加服务，类型选 STDIO，填四样东西：命令（比如 npx）、参数（比如 -y @modelcontextprotocol/server-filesystem /path）、环境变量（这个服务器的 API Key 放这里，以后客户端配置里就不再需要密钥了）和工作目录。

如果你已经在某个客户端里配好了这个服务器，不必手填：MCP2Skill 支持直接导入 Claude Desktop、Claude Code、Cursor、Gemini CLI、Codex 的现有配置，也支持粘贴 JSON。命令、参数、密钥一次性带过来。导入的详细说明见 MCP 服务管理。

保存并启用后，MCP2Skill 会拉起这个 stdio 进程并获取工具列表——从这一刻起，这个进程由网关统一运行，客户端不再各自启动它。

第 2 步：拿到统一的 HTTP 端点

服务启用后，网关（默认监听 127.0.0.1:3571）会为它生成 HTTP 端点。三种粒度按需选用：

在服务或工作区详情页点"复制 JSON"，会得到一段已经填好 URL 和请求头的客户端配置。以一个名为 filesystem 的服务为例（未启用鉴权时）：

{
  "mcpServers": {
    "filesystem": {
      "type": "http",
      "url": "http://127.0.0.1:3571/mcp/filesystem",
      "headers": {
        "X-Title": "Claude Code"
      }
    }
  }
}

到这里，本机客户端已经可以用了：把 JSON 粘进 ~/.claude.json、Cursor 的 ~/.cursor/mcp.json 或任何支持 MCP 的客户端，它们连的不再是一个子进程，而是一个 HTTP URL。stdio → HTTP 的转换在这一步已经完成；剩下两步解决的是"别的机器能不能用、敢不敢让它用"。

第 3 步：启用 API Key 鉴权

默认情况下网关只监听 127.0.0.1，本机之外无人可达——这是刻意保守的默认值。要对外开放，第一件事是鉴权而不是开网。

在设置页启用 API Key 认证。之后所有请求必须携带 Authorization: Bearer <你的密钥> 头，否则被网关直接拒绝。启用后再复制 JSON，鉴权头会自动包含在里面：

{
  "mcpServers": {
    "filesystem": {
      "type": "http",
      "url": "http://127.0.0.1:3571/mcp/filesystem",
      "headers": {
        "X-Title": "Claude Code",
        "Authorization": "Bearer mcp_你的密钥"
      }
    }
  }
}

注意两件事：密钥可以随时重新生成（旧配置立刻失效，记得重新分发 JSON）；而上游服务器真正的密钥（GitHub Token 等）只存在 MCP2Skill 的服务配置里，客户端拿到的只是一个网关密钥——上游凭据不随端点外流。

第 4 步：打开远程访问，让外网用上

在设置页打开远程访问开关后，网关从 127.0.0.1:3571 改为监听 0.0.0.0:3571——局域网其他机器（或经防火墙/反代映射后的公网）就能以 http://<这台机器的地址>:3571/... 访问同一个端点。

把 URL 里的主机名换成可达地址后，同一份 JSON 就能在云端 Agent、CI 流水线或同事的电脑上使用。对外暴露时建议遵循这份清单：

1. 先启用 API Key，再打开远程访问——顺序反了等于裸奔一个窗口期。
2. 端口走防火墙白名单或套一层 TLS 反向代理（stdio 转出来的流量里可能带文件内容、查询结果等敏感数据，明文跨公网不明智）。
3. 长期对外只暴露工作区端点并筛掉破坏性工具，而不是 /all。
4. 定期重新生成密钥；每次重新生成后更新各客户端的 JSON。

设置项的完整说明见常规与 MCP 设置。

验证：让调用自己留下证据

配置完成后发起一次真实调用（让客户端列一下工具就算），然后回到 MCP2Skill 的仪表盘和调用日志：调用次数、成功率、每次请求与响应的内容、来自哪个客户端，都应该已经出现在里面。日志里能看到那次调用，说明客户端 → 网关 → stdio 服务器整条链路是通的；看不到，说明问题出在客户端到网关这一段（最常见的两个原因：URL 主机名不可达、鉴权头缺失）。排查路径见日志与诊断。

转换前后对比

常见问题

stdio MCP 能不改代码直接变成 HTTP MCP 吗？

能。传输翻译发生在网关层：网关以客户端身份拉起 stdio 子进程，同时以 HTTP MCP 服务器的身份对外提供端点，请求和响应原样双向转发。服务器进程、工具定义、行为都不变。你需要做的只是把它导入 MCP2Skill 并复制一段 JSON。

转成 HTTP 后，外网使用安全吗？

安全的前提是配置正确。MCP2Skill 默认只监听本机回环地址，外网不可达；需要远程使用时，先启用 API Key 鉴权再打开远程访问开关，所有请求都必须携带有效的 Bearer 密钥。跨公网时建议再加一层 TLS（反向代理即可），并只暴露经过工具筛选的工作区端点。

远程 MCP（SSE / Streamable HTTP）也能导入吗？

可以。MCP2Skill 支持三种服务类型：STDIO、SSE、Streamable HTTP（URL 加自定义请求头，需要 OAuth 的服务有完整的授权流程）。它们导入后都收敛到同一个 HTTP 网关端点后面——这让你可以把零散的本地与远程 MCP 统一成一个带鉴权、带日志的入口。

转换会增加延迟吗？

多了一跳网关转发，本机场景下这跳是毫秒级的，相对于大模型生成响应的时间可以忽略。换来的是：进程只跑一份、调用有日志、端点可鉴权可远程。如果某个工具调用链路对延迟极端敏感，保留直连 stdio 也完全可以——两种方式不互斥。

这和把 MCP 转成 Skill 有什么区别？

转 HTTP 解决的是连接层面的问题：谁能连、怎么连、连了之后看得见什么日志。转 Skill 解决的是 Token 层面的问题：工具定义何时进入上下文。两者可以叠加——从工作区生成的 Skill 仍然调用该工作区的 HTTP 端点。转换流程见如何把任意 MCP 转成 Skill。

下一步

1. 下载 MCP2Skill，导入你现有的 MCP 配置。
2. 复制端点 JSON，先用本机客户端验证连通。
3. 需要远程使用时：启用 API Key → 打开远程访问 → 换掉 URL 里的主机名重新分发 JSON。
4. 在仪表盘里看着第一次远程调用出现。

想更系统地了解网关模式（聚合、工具筛选、命名空间、与代理/注册表的区别），读这篇：MCP 网关完全指南。