MCPModel Context Protocol模型上下文协议这两年已经成了 AI 工具链里的基础设施stdio 和 HTTP 是它最常见的两种传输方式。平时我们配 Claude Desktop、Cursor 这类客户端很多都是填一条npx命令让客户端通过标准输入输出拉起 MCP server这就是 stdio 模式。本地用着很顺但一旦你想把同一个 MCP server 开放给另一台电脑上的客户端或者部署到云端长期运行stdio 就被卡住了——它是进程内通信不是你随便写个地址就能连的。于是“把 stdio MCP 转成 HTTP MCP”就变成了一个非常实际的需求。我不是 MCP 协议的发明者只是个天天在各种 server 里折腾的普通开发者。这篇文章记录的是我实际用过的做法不改底层工具的逻辑只在外面加一层转换层把原本只支持 stdio 的 MCP server 包装成可以被远程调用的 HTTP 服务并补上认证、TLS、进程管理这些安全细节。整个过程会涉及协议理解、桥接代码、客户端配置和一堆排查经验适合手里已经有一个能用 stdio 启动的 MCP server、正在发愁怎么把它共享出去的朋友。1. 先把 stdio 和 HTTP 两种传输方式聊透1.1 stdio 为什么在本地场景这么好用stdio 的全称是 standard input / standard output在 MCP 里指的是父进程和子进程之间的通信方式。AI 客户端在你的电脑上拉起一个子进程命令行参数里带着命令和参数之后客户端把 JSON-RPC 消息写到子进程的标准输入子进程把响应写到标准输出两边一进一出就完成了消息交换。因为消息是按行分隔的 JSON-RPC所以调试非常直观你甚至可以在终端里用一个简单的管道把一条消息喂进去看子进程吐出什么结果。这个模式的优势很明显不需要开端口不需要管防火墙也没有跨域和鉴权的问题进程跟着客户端走退出客户端时子进程自动回收。对单机使用来说这是最稳妥、最不容易出事故的方式。但它也有一个天然的边界stdio 是进程内部的通道连接关系是“客户端进程与子进程一一绑定”换一台机器就无法访问。比如你在 A 电脑上启动了一个数据库查询 MCP serverB 电脑上的 AI 客户端想用它连不到 A 电脑里那个进程因为没有一个网络地址可以指过去。1.2 HTTP 版本解决了什么问题HTTP 传输官方现在主推的是 Streamable HTTP早期还有 SSE 模式但现在正在逐步收敛把 MCP 的 JSON-RPC 消息放到了 HTTP 请求和响应里。客户端向某个 URL 发起 POST 请求消息体是 JSON-RPC服务端返回 JSON 或者按 SSE 格式流式返回。相比 stdio它最大的变化是进程边界变成了网络边界。只要网络能通任何符合 MCP 协议的客户端都能连上来。这个过程放到实际场景里就是你可以把一个 MCP server 部署在服务器上供团队里的多个人使用也可以把它嵌到自己的后端服务里通过一个固定 URL 暴露给 AI 应用甚至可以叠加多租户、流量控制和访问审计。HTTP 版本也让 MCP 变得更像一个“标准后端服务”而不是一个“本地小工具”。这也是为什么现在越来越多的 MCP server 默认就同时支持 stdio 和 HTTP 两种启动方式。1.3 转换的本质改传输层不动协议层MCP 的消息本身是 JSON-RPC 2.0不管走 stdio 还是 HTTP消息结构是一样的。所以从 stdio 转 HTTP并不是把业务功能重写一遍而是做一个传输层的翻译对外是一个 HTTP 服务对内是一个 stdio 客户端。HTTP 请求进来转换层把 JSON-RPC 消息变成字节流写到 stdio 子进程的标准输入读取子进程的标准输出解析响应再作为 HTTP 响应发回去。打个比方stdio server 像一个只愿意当面交谈的内部员工HTTP 转换层像一个前台接待。外面的电话请求打到前台前台把问题转述给里面的员工再把员工的答复带回电话里。员工不需要知道电话怎么用打电话的人也不需要知道员工在哪个工位。理解了这一层后面看代码就会轻松很多。需要额外注意的是 MCP 生命周期里的 initialize、notifications/initialized、tools/list、tools/call 这些请求转换层必须正确处理否则客户端会卡在握手阶段。2. 动手之前先选一条适合自己的转换路线2.1 你的 server 本身就支持 HTTP那就别折腾现在官方 TypeScript SDK 和 Python SDK 都已经支持 HTTP 方式启动。如果你是自己用 SDK 写的 MCP server优先去查文档里有没有类似--transport http的参数如果有直接加上这是最省事、最不容易出问题的路线。我用 Python 的 FastMCP 写过一个内部工具底层指定transporthttp之后启动就是一个完整的 HTTP 服务完全不需要额外桥接。如果你拿到的 server 是别人编译好的、只支持 stdio或者你不想改它的启动逻辑那才需要继续看后面的方案。还有一种情况是server 虽然支持 HTTP但你想在它前面加一层鉴权、限流、日志或者你想让一个已经很稳定的 stdio 服务不做任何代码改动就暴露出去这时候也需要一个外置的转换层。2.2 社区现成工具适合快速验证社区里已经有不少把 stdio MCP 变成 HTTP 服务的现成工具常见用法是给你一条命令后面接上原本的启动命令工具会替你管理子进程并对外暴露一个 HTTP 端口。这种工具最适合快速验证“这个思路能不能通”尤其是协议调试阶段几分钟就能看到效果。不过它有几个隐患有些工具只支持老的 SSE 传输新版 Streamable HTTP 客户端连不上有些对流式响应、取消通知这类高阶消息处理得不完整更关键的是很多工具默认没有鉴权能力直接暴露端口就像把家门钥匙挂在门上。我的建议是快速验证可以用现成工具正式对外服务还是自己写一个小桥接层或者在现成工具前面加一道带鉴权的接入层。2.3 自己写桥接层可控性优先我最后选择了自己写一个轻量桥接层核心原因是我想精确控制 session 和认证。自己写大约 200 行代码但你几乎能掌握每条消息的走向。你需要理解 MCP 协议里几个核心方法initialize、notifications/initialized、tools/list、tools/call以及可选的 resources/list、prompts/list。只要把 JSON-RPC 消息在两端的格式对齐日志、鉴权、并发限制都可以按需添加。这个方案对开发者要求稍高一点但我觉得很值得因为你会真正理解 MCP 的工作机制。而且桥接层本身也是一个独立的程序可以被其他项目复用。下面我就用 TypeScript 和官方 Node SDK 写一个最小可用的转换服务。3. 写一个可运行的 stdio 转 HTTP 桥接层3.1 准备一个最简单的 stdio MCP server 作为目标为了演示我们先造一个只支持 stdio 的 MCP server。它做的事情很简单注册一个echo工具入参是一段文本返回加上echo:前缀的结果。完整代码是这样的// server.js import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; const server new McpServer({ name: echo-server, version: 1.0.0, }); server.tool( echo, { text: z.string() }, async ({ text }) ({ content: [{ type: text, text: echo: ${text} }] }) ); const transport new StdioServerTransport(); await server.connect(transport);跑这个项目需要 Node 18 以上安装依赖后用node server.js就能启动。正常情况下它不会在终端打印任何东西而是等待客户端通过标准输入写 JSON-RPC 消息。你可以用npx modelcontextprotocol/inspector node server.js打开 MCP Inspector 验证一下能看到echo工具已经被正确识别。这就是我们接下来要转换的“目标服务”。3.2 桥接层运行原理和核心代码桥接层在 HTTP 这一侧是一个服务端接收/mcp路径的 POST 请求在 stdio 这一侧是一个客户端负责拉起并连接server.js这个子进程。为了保持会话状态我给每一个 HTTP session 分配一个独立的 stdio 子进程并用一个 Map 保存 sessionId 和内部 client 的对应关系。这里是核心代码// bridge.js import express from express; import { randomUUID } from node:crypto; import { Client } from modelcontextprotocol/sdk/client/index.js; import { StdioClientTransport } from modelcontextprotocol/sdk/client/stdio.js; const app express(); app.use(express.json()); const sessions new Map(); async function createSession() { const transport new StdioClientTransport({ command: node, args: [server.js], cwd: process.cwd(), }); const client new Client( { name: stdio-http-bridge, version: 1.0.0 }, { capabilities: {} } ); await client.connect(transport); return { client, transport }; } function sendJson(res, message, result) { res.json({ jsonrpc: 2.0, id: message.id, result }); } app.post(/mcp, async (req, res) { const sessionId req.headers[mcp-session-id]; const message req.body; try { // 1. initialize建立 HTTP 会话同时创建对应的 stdio 子进程 if (message.method initialize) { const sid randomUUID(); const session await createSession(); sessions.set(sid, session); const capabilities session.client.getServerCapabilities(); const serverInfo session.client.getServerVersion(); return sendJson(res, message, { protocolVersion: message.params.protocolVersion, capabilities, serverInfo, }); } // 2. 后续请求必须带 sessionId if (!sessionId || !sessions.has(sessionId)) { return res.status(400).json({ jsonrpc: 2.0, id: message.id, error: { code: -32000, message: invalid session }, }); } const session sessions.get(sessionId); // 3. initialized 通知 if (message.method notifications/initialized) { await session.client.notification({ method: notifications/initialized }); return res.status(202).end(); } // 4. 工具列表 if (message.method tools/list) { const result await session.client.listTools(); return sendJson(res, message, result); } // 5. 调用工具 if (message.method tools/call) { const result await session.client.callTool(message.params); return sendJson(res, message, result); } return res.status(501).json({ jsonrpc: 2.0, id: message.id, error: { code: -32601, message: method not supported }, }); } catch (err) { console.error([bridge error], err); return res.status(500).json({ jsonrpc: 2.0, id: message.id, error: { code: -32603, message: err.message }, }); } }); app.listen(3000, 0.0.0.0, () { console.log(bridge listening on http://0.0.0.0:3000/mcp); });这段代码我刻意保持精简重点是把链路讲清楚。实际使用时有几个细节要按你的 SDK 版本微调比如getServerCapabilities()和getServerVersion()在不同版本 SDK 里可能返回 Promise也可能方法名略有差异。如果你发现类型不对直接看安装的 SDK 的.d.ts里 Client 类有哪些方法即可。另外初始化握手时HTTP 客户端的initialize请求和内部 stdio 的initialize请求不是同一个。上面代码里createSession()已经帮我们在桥接层和server.js之间完成了一次握手所以 HTTP 侧收到initialize时我们只需要把内部已经协商好的能力和服务信息返回即可。如果某些版本 SDK 不直接暴露这两个方法你也可以在创建 session 时手动保存initialize的结果。对于tools/call的流式输出上面的实现只支持普通 JSON 响应。如果你的工具会长时间运行或需要实时推送就要在 HTTP 响应里按 SSE 格式分块发送Accept: text/event-stream的客户端才能正常处理。这个扩展点在真实项目中非常常见建议你先跑通 JSON 模式再按需升级。3.3 安全加固远程调用不是裸奔把上面的代码跑起来你已经有了一个可从远程访问的 HTTP MCP 服务但这只是第一步绝对不能就这样暴露到公网。远程调用意味着不可信的网络所以身份认证、传输加密和资源限制这三件事至少要做。首先是绑定地址。我演示代码里写的是0.0.0.0这意味着所有网卡都能访问。如果你的服务只需要在局域网内使用建议明确绑定内网 IP如果只在单机调试直接绑定127.0.0.1。其次是认证。最简单的方案是在 Express 里加一个中间件检查 HTTP 请求的Authorizationheader 是否为约定的 Bearer Tokenfunction auth(req, res, next) { const token process.env.MCP_HTTP_TOKEN; const authHeader req.headers[authorization] || ; if (!token || authHeader ! Bearer ${token}) { return res.status(401).json({ error: unauthorized }); } next(); } app.use(/mcp, auth);Token 一定要通过环境变量注入不要硬编码在代码里。然后考虑传输加密生产环境不要用裸 HTTP 传输 MCP 消息因为工具调用可能携带数据库查询、文件内容、内部接口地址等敏感信息。最简单的做法是在前面架一道 Nginx让 Nginx 统一处理 TLS 证书和请求分发如果你不想引入额外组件也可以直接在 Node 里用https模块加载证书。最后是会话清理和并发限制。我在代码里用 Map 存了 session如果不清理长期运行后内存会一直涨。建议加一个定时器回收超过一定时间没有活跃请求的 session。另外每个 session 会拉起一个子进程如果有人脚本化地批量创建 session系统资源很快会耗尽。最好全局维护一个活跃 session 数量的计数器超过阈值就拒绝新的initialize请求。3.4 用守护进程把桥接服务跑起来开发环境里node bridge.js凑合能用但正式环境要让它开机自启、崩溃自动拉起来。Linux 上推荐用 systemd写一个 service 文件指定ExecStart、环境变量和日志路径。如果你习惯用 PM2也可以直接用pm2 start bridge.js --name mcp-bridge管理。容器化也是很好的选择把server.js、bridge.js、依赖打包进一个镜像对外只暴露 HTTP 端口。无论用哪种方式都要确保子进程的日志能被捕获。stdio server 在子进程里跑如果它输出到 stderr是桥接层级联日志的一部分如果它在 stdout 里乱打日志就会污染协议通信这个问题我在后面专门讲。4. 远程调用实战从客户端配置到调用链验证4.1 用 curl 手工验证桥接层代码跑起来之后先别急着拿 AI 客户端试。用curl手工走一遍 MCP 握手能最快暴露问题。第一步发initializecurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H Authorization: Bearer your-token \ -d {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:curl,version:1.0}}}注意在返回的响应 header 里找到Mcp-Session-Id后面的请求都要带上它。然后发notifications/initialized通知再发tools/listcurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer your-token \ -H Mcp-Session-Id: 上一步拿到的sessionId \ -d {jsonrpc:2.0,id:2,method:tools/list}正常情况下你应该能拿到包含echo工具的列表。最后发tools/callcurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer your-token \ -H Mcp-Session-Id: sessionId \ -d {jsonrpc:2.0,id:3,method:tools/call,params:{name:echo,arguments:{text:hello}}}返回结果里应该有content数组包含echo: hello。这一趟如果顺利说明桥接层核心链路已经通了。4.2 在常用 AI 客户端里接入 HTTP MCP现在很多主流 AI 客户端都支持使用 URL 形式的 MCP server。以 Claude Code 为例可以用类似这样的命令添加一个 HTTP MCP serverclaude mcp add --transport http my-remote-server http://your-server:3000/mcp --header Authorization: Bearer your-tokenCursor、Trae 这类 IDE 也提供了 MCP 配置界面通常可以在里面选择 HTTP 类型填写 URL 和自定义 Header。要注意的是不同客户端对自定义 Header 的支持程度不一样。有的客户端界面里没有地方填 Header这种情况通常只能通过环境变量传递给后端进程或者使用客户端内置的“请求头”配置入口。如果你实在没法传 Header也可以退而求其次在内网环境用 URL query 参数传 token但对于公网服务我不建议这么干因为 URL 会出现在访问日志里。配置好之后直接在客户端对话里让 AI 调用工具。如果客户端没有按预期列出工具先检查桥接层的日志看看tools/list是否被调用、返回了什么内容。从客户端到 HTTP 接入层再到 stdio 子进程这条链路上的每个环节都可以单独观察这也是自己写桥接层的一大优势。4.3 典型场景把 stdio 工具变成团队共享能力这种转换方式最典型的应用是把那些只提供 stdio 启动方式的官方工具变成团队共享服务。举个例子我调试浏览器页面时经常用到 chrome-devtools-mcp官方 npm 包默认启动方式就是 stdio server单机用起来很方便但团队其他成员如果也想连我本地调试的浏览器就很不现实。用本文的桥接层把它包成 HTTP 服务后只要网络可达、有 token其他人也能通过 URL 方式连接同一个调试能力。类似的还有 Playwright MCP、数据库查询 MCP、Figma 的 MCP 插件等。只要是“命令行启动一个 stdio server”的工具理论上都可以被这套桥接逻辑包起来。唯一要额外留意的是这类工具往往会在本地启动浏览器、打开端口或读取文件做成远程服务之前一定要想清楚权限边界哪些人能用、能用在哪些 URL 上、会不会被拿去访问不该访问的资源。毕竟工具越强大被滥用的风险也越大。5. 常见问题与排查技巧实录5.1 连接失败端口、绑定地址、防火墙我见过最多的现象是本机 curl 一切正常换一台机器就连接超时。这个问题大概率是监听地址或防火墙导致的。先用ss -lntp | grep 3000看桥接服务到底监听在哪个地址上如果看到的是127.0.0.1:3000那其他机器当然连不上。改成0.0.0.0:3000或具体的内网 IP 后再检查防火墙是否放行了对应端口。远程客户端如果返回 502 或 503则要重点看桥接进程是否活着以及 stdio 子进程是否异常退出。还有一种情况我遇到过客户端用http://访问到了只配置了 HTTPS 的端口服务端会直接返回类似400 Bad Request: The plain HTTP request was sent to HTTPS port。这种情况不是 MCP 的问题单纯是客户端把协议写错了把 URL 改成https://即可。5.2 stdio 子进程 stdout 被污染导致协议解析失败这是我自己写桥接层时踩过最深的坑。stdio MCP 的通信通道是标准输出可很多开发者习惯在代码里用console.log打印调试信息。如果这个console.log跑在 MCP server 内部而你的 server 又通过 stdio 传消息那这些日志就会被当成 JSON-RPC 消息发送给客户端轻则解析失败重则导致整个会话卡死。这类问题排查起来也很头疼因为日志往往是无意的。建议做法是在实现 MCP server 时所有业务日志一律走 stderr或者写到独立文件转换层在看到子进程 stdout 中出现无法解析的行时也要能抛出明显错误方便快速定位。如果你接手的是一个别人写的 server没法改代码那只能在桥接层做防御性处理比如过滤掉非 JSON-RPC 行但这可能会掩盖问题最好的方案还是让源头干净。5.3 超时与长时间运行的工具任务HTTP 传输天然有超时机制但 MCP 工具执行时间可能非常长。如果你在本地 stdio 模式下调用一个耗时几分钟的工具没问题转成 HTTP 后却总是报超时大概率是接入层或 HTTP 客户端的默认 timeout 设置太短。Express 的默认超时不一定够用Nginx 这样的接入层默认proxy_read_timeout也只有 60 秒左右。处理方式有两种一是调大超时时间适合工具确实需要几分钟才能返回的场景二是改成异步任务模式接口先返回一个任务 ID客户端通过其他接口轮询结果。后者实现复杂但更合理尤其是工具内部会触发副作用时客户端一旦超时重试很容易导致同一个任务被重复执行。我个人建议容易被调用的工具尽量设计成快速返回重活放到后台队列里做MCP 只负责提交任务和查询状态。5.4 会话并发过高与资源管理每个 HTTP session 对应一个 stdio 子进程这个模型简单直观但代价是资源开销很大。如果有人反复创建 session 而不主动关闭服务端的进程数会不断上涨最终拖垮整台服务器。我一开始没做限制结果一次联调测试就把进程数跑到了几百个内存直接吃满。做好两件事可以避免这种情况一是限制最大并发 session 数超过阈值直接拒绝新的initialize二是实现空闲回收定期清理超过 N 分钟没有请求的 session。桥接层还应该对notifications/initialized之后长期没有任何请求的连接做保活或断开策略避免半开连接占用资源。5.5 认证失败与客户端不支持自定义 Header启用鉴权后最常见的问题是 401。先检查 token 是否通过环境变量正确传入再确认客户端发送的 header 格式是不是标准的Authorization: Bearer xxx。有些客户端会自动把请求体里的某些字段塞到 header但不会带自定义 token有些客户端界面名叫 “Header” 但底层用的是 basic auth。遇到这种情况我的建议是尽量选择支持自定义 header 的客户端或者用前面提到的接入层统一做认证让每个客户端只负责提供 MCP 请求认证交给网关处理。还遇到过一种情况客户端本身能正常认证但某个工具内部又发起了外部的 HTTP 请求那个请求也需要认证。这个跟桥接层无关但容易被误判为桥接层的问题。排查时记得把调用链拆开看先确认到 MCP server 这一步是否通过认证再查工具内部逻辑。5.6 进程守护与日志审计远程服务的稳定性不能靠运气。即使你的桥接层代码没问题stdio 子进程也可能因为外部原因退出比如内存不足、被系统杀掉、文件描述符耗尽。所以桥接层需要处理子进程意外退出的情况检测到退出后主动注销对应的 session并返回明确的错误码给客户端避免客户端拿到一个永远无响应的连接。日志审计同样重要。我在桥接层里给每个请求都加了一行 JSON 日志包含时间、sessionId、method、请求耗时和返回码。这样一旦有问题可以直接从日志里还原出客户端到底做了什么操作。生产环境还可以把日志接入统一日志平台按 user 或 session 维度汇总发现异常调用行为。6. 写在最后几个我以为重要的小细节连续折腾了几天之后我最直观的感受是stdio 转 HTTP 本身不难难的是把状态管理、安全边界和异常恢复想清楚。初期我也图省事直接用社区工具把端口暴露出去结果一天下来被一堆请求打满了日志从那以后我把鉴权、绑定地址和会话限制都当成了必选项而不是可选项。如果你也在做类似的事最后分享一个小技巧调试桥接层时先用 MCP Inspector 指向你的 HTTP 地址确认协议层没问题再用 Cursor 或 Claude Code 去连。如果业务逻辑有问题查 stdio 子进程的 stderr如果协议有问题查 HTTP 请求和响应头。分层排查远比在客户端里反复重连高效得多。希望这篇记录能帮你少走几步弯路。
把 stdio MCP 包装成 HTTP 服务：原理、桥接实现与安全加固实践
MCPModel Context Protocol模型上下文协议这两年已经成了 AI 工具链里的基础设施stdio 和 HTTP 是它最常见的两种传输方式。平时我们配 Claude Desktop、Cursor 这类客户端很多都是填一条npx命令让客户端通过标准输入输出拉起 MCP server这就是 stdio 模式。本地用着很顺但一旦你想把同一个 MCP server 开放给另一台电脑上的客户端或者部署到云端长期运行stdio 就被卡住了——它是进程内通信不是你随便写个地址就能连的。于是“把 stdio MCP 转成 HTTP MCP”就变成了一个非常实际的需求。我不是 MCP 协议的发明者只是个天天在各种 server 里折腾的普通开发者。这篇文章记录的是我实际用过的做法不改底层工具的逻辑只在外面加一层转换层把原本只支持 stdio 的 MCP server 包装成可以被远程调用的 HTTP 服务并补上认证、TLS、进程管理这些安全细节。整个过程会涉及协议理解、桥接代码、客户端配置和一堆排查经验适合手里已经有一个能用 stdio 启动的 MCP server、正在发愁怎么把它共享出去的朋友。1. 先把 stdio 和 HTTP 两种传输方式聊透1.1 stdio 为什么在本地场景这么好用stdio 的全称是 standard input / standard output在 MCP 里指的是父进程和子进程之间的通信方式。AI 客户端在你的电脑上拉起一个子进程命令行参数里带着命令和参数之后客户端把 JSON-RPC 消息写到子进程的标准输入子进程把响应写到标准输出两边一进一出就完成了消息交换。因为消息是按行分隔的 JSON-RPC所以调试非常直观你甚至可以在终端里用一个简单的管道把一条消息喂进去看子进程吐出什么结果。这个模式的优势很明显不需要开端口不需要管防火墙也没有跨域和鉴权的问题进程跟着客户端走退出客户端时子进程自动回收。对单机使用来说这是最稳妥、最不容易出事故的方式。但它也有一个天然的边界stdio 是进程内部的通道连接关系是“客户端进程与子进程一一绑定”换一台机器就无法访问。比如你在 A 电脑上启动了一个数据库查询 MCP serverB 电脑上的 AI 客户端想用它连不到 A 电脑里那个进程因为没有一个网络地址可以指过去。1.2 HTTP 版本解决了什么问题HTTP 传输官方现在主推的是 Streamable HTTP早期还有 SSE 模式但现在正在逐步收敛把 MCP 的 JSON-RPC 消息放到了 HTTP 请求和响应里。客户端向某个 URL 发起 POST 请求消息体是 JSON-RPC服务端返回 JSON 或者按 SSE 格式流式返回。相比 stdio它最大的变化是进程边界变成了网络边界。只要网络能通任何符合 MCP 协议的客户端都能连上来。这个过程放到实际场景里就是你可以把一个 MCP server 部署在服务器上供团队里的多个人使用也可以把它嵌到自己的后端服务里通过一个固定 URL 暴露给 AI 应用甚至可以叠加多租户、流量控制和访问审计。HTTP 版本也让 MCP 变得更像一个“标准后端服务”而不是一个“本地小工具”。这也是为什么现在越来越多的 MCP server 默认就同时支持 stdio 和 HTTP 两种启动方式。1.3 转换的本质改传输层不动协议层MCP 的消息本身是 JSON-RPC 2.0不管走 stdio 还是 HTTP消息结构是一样的。所以从 stdio 转 HTTP并不是把业务功能重写一遍而是做一个传输层的翻译对外是一个 HTTP 服务对内是一个 stdio 客户端。HTTP 请求进来转换层把 JSON-RPC 消息变成字节流写到 stdio 子进程的标准输入读取子进程的标准输出解析响应再作为 HTTP 响应发回去。打个比方stdio server 像一个只愿意当面交谈的内部员工HTTP 转换层像一个前台接待。外面的电话请求打到前台前台把问题转述给里面的员工再把员工的答复带回电话里。员工不需要知道电话怎么用打电话的人也不需要知道员工在哪个工位。理解了这一层后面看代码就会轻松很多。需要额外注意的是 MCP 生命周期里的 initialize、notifications/initialized、tools/list、tools/call 这些请求转换层必须正确处理否则客户端会卡在握手阶段。2. 动手之前先选一条适合自己的转换路线2.1 你的 server 本身就支持 HTTP那就别折腾现在官方 TypeScript SDK 和 Python SDK 都已经支持 HTTP 方式启动。如果你是自己用 SDK 写的 MCP server优先去查文档里有没有类似--transport http的参数如果有直接加上这是最省事、最不容易出问题的路线。我用 Python 的 FastMCP 写过一个内部工具底层指定transporthttp之后启动就是一个完整的 HTTP 服务完全不需要额外桥接。如果你拿到的 server 是别人编译好的、只支持 stdio或者你不想改它的启动逻辑那才需要继续看后面的方案。还有一种情况是server 虽然支持 HTTP但你想在它前面加一层鉴权、限流、日志或者你想让一个已经很稳定的 stdio 服务不做任何代码改动就暴露出去这时候也需要一个外置的转换层。2.2 社区现成工具适合快速验证社区里已经有不少把 stdio MCP 变成 HTTP 服务的现成工具常见用法是给你一条命令后面接上原本的启动命令工具会替你管理子进程并对外暴露一个 HTTP 端口。这种工具最适合快速验证“这个思路能不能通”尤其是协议调试阶段几分钟就能看到效果。不过它有几个隐患有些工具只支持老的 SSE 传输新版 Streamable HTTP 客户端连不上有些对流式响应、取消通知这类高阶消息处理得不完整更关键的是很多工具默认没有鉴权能力直接暴露端口就像把家门钥匙挂在门上。我的建议是快速验证可以用现成工具正式对外服务还是自己写一个小桥接层或者在现成工具前面加一道带鉴权的接入层。2.3 自己写桥接层可控性优先我最后选择了自己写一个轻量桥接层核心原因是我想精确控制 session 和认证。自己写大约 200 行代码但你几乎能掌握每条消息的走向。你需要理解 MCP 协议里几个核心方法initialize、notifications/initialized、tools/list、tools/call以及可选的 resources/list、prompts/list。只要把 JSON-RPC 消息在两端的格式对齐日志、鉴权、并发限制都可以按需添加。这个方案对开发者要求稍高一点但我觉得很值得因为你会真正理解 MCP 的工作机制。而且桥接层本身也是一个独立的程序可以被其他项目复用。下面我就用 TypeScript 和官方 Node SDK 写一个最小可用的转换服务。3. 写一个可运行的 stdio 转 HTTP 桥接层3.1 准备一个最简单的 stdio MCP server 作为目标为了演示我们先造一个只支持 stdio 的 MCP server。它做的事情很简单注册一个echo工具入参是一段文本返回加上echo:前缀的结果。完整代码是这样的// server.js import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; const server new McpServer({ name: echo-server, version: 1.0.0, }); server.tool( echo, { text: z.string() }, async ({ text }) ({ content: [{ type: text, text: echo: ${text} }] }) ); const transport new StdioServerTransport(); await server.connect(transport);跑这个项目需要 Node 18 以上安装依赖后用node server.js就能启动。正常情况下它不会在终端打印任何东西而是等待客户端通过标准输入写 JSON-RPC 消息。你可以用npx modelcontextprotocol/inspector node server.js打开 MCP Inspector 验证一下能看到echo工具已经被正确识别。这就是我们接下来要转换的“目标服务”。3.2 桥接层运行原理和核心代码桥接层在 HTTP 这一侧是一个服务端接收/mcp路径的 POST 请求在 stdio 这一侧是一个客户端负责拉起并连接server.js这个子进程。为了保持会话状态我给每一个 HTTP session 分配一个独立的 stdio 子进程并用一个 Map 保存 sessionId 和内部 client 的对应关系。这里是核心代码// bridge.js import express from express; import { randomUUID } from node:crypto; import { Client } from modelcontextprotocol/sdk/client/index.js; import { StdioClientTransport } from modelcontextprotocol/sdk/client/stdio.js; const app express(); app.use(express.json()); const sessions new Map(); async function createSession() { const transport new StdioClientTransport({ command: node, args: [server.js], cwd: process.cwd(), }); const client new Client( { name: stdio-http-bridge, version: 1.0.0 }, { capabilities: {} } ); await client.connect(transport); return { client, transport }; } function sendJson(res, message, result) { res.json({ jsonrpc: 2.0, id: message.id, result }); } app.post(/mcp, async (req, res) { const sessionId req.headers[mcp-session-id]; const message req.body; try { // 1. initialize建立 HTTP 会话同时创建对应的 stdio 子进程 if (message.method initialize) { const sid randomUUID(); const session await createSession(); sessions.set(sid, session); const capabilities session.client.getServerCapabilities(); const serverInfo session.client.getServerVersion(); return sendJson(res, message, { protocolVersion: message.params.protocolVersion, capabilities, serverInfo, }); } // 2. 后续请求必须带 sessionId if (!sessionId || !sessions.has(sessionId)) { return res.status(400).json({ jsonrpc: 2.0, id: message.id, error: { code: -32000, message: invalid session }, }); } const session sessions.get(sessionId); // 3. initialized 通知 if (message.method notifications/initialized) { await session.client.notification({ method: notifications/initialized }); return res.status(202).end(); } // 4. 工具列表 if (message.method tools/list) { const result await session.client.listTools(); return sendJson(res, message, result); } // 5. 调用工具 if (message.method tools/call) { const result await session.client.callTool(message.params); return sendJson(res, message, result); } return res.status(501).json({ jsonrpc: 2.0, id: message.id, error: { code: -32601, message: method not supported }, }); } catch (err) { console.error([bridge error], err); return res.status(500).json({ jsonrpc: 2.0, id: message.id, error: { code: -32603, message: err.message }, }); } }); app.listen(3000, 0.0.0.0, () { console.log(bridge listening on http://0.0.0.0:3000/mcp); });这段代码我刻意保持精简重点是把链路讲清楚。实际使用时有几个细节要按你的 SDK 版本微调比如getServerCapabilities()和getServerVersion()在不同版本 SDK 里可能返回 Promise也可能方法名略有差异。如果你发现类型不对直接看安装的 SDK 的.d.ts里 Client 类有哪些方法即可。另外初始化握手时HTTP 客户端的initialize请求和内部 stdio 的initialize请求不是同一个。上面代码里createSession()已经帮我们在桥接层和server.js之间完成了一次握手所以 HTTP 侧收到initialize时我们只需要把内部已经协商好的能力和服务信息返回即可。如果某些版本 SDK 不直接暴露这两个方法你也可以在创建 session 时手动保存initialize的结果。对于tools/call的流式输出上面的实现只支持普通 JSON 响应。如果你的工具会长时间运行或需要实时推送就要在 HTTP 响应里按 SSE 格式分块发送Accept: text/event-stream的客户端才能正常处理。这个扩展点在真实项目中非常常见建议你先跑通 JSON 模式再按需升级。3.3 安全加固远程调用不是裸奔把上面的代码跑起来你已经有了一个可从远程访问的 HTTP MCP 服务但这只是第一步绝对不能就这样暴露到公网。远程调用意味着不可信的网络所以身份认证、传输加密和资源限制这三件事至少要做。首先是绑定地址。我演示代码里写的是0.0.0.0这意味着所有网卡都能访问。如果你的服务只需要在局域网内使用建议明确绑定内网 IP如果只在单机调试直接绑定127.0.0.1。其次是认证。最简单的方案是在 Express 里加一个中间件检查 HTTP 请求的Authorizationheader 是否为约定的 Bearer Tokenfunction auth(req, res, next) { const token process.env.MCP_HTTP_TOKEN; const authHeader req.headers[authorization] || ; if (!token || authHeader ! Bearer ${token}) { return res.status(401).json({ error: unauthorized }); } next(); } app.use(/mcp, auth);Token 一定要通过环境变量注入不要硬编码在代码里。然后考虑传输加密生产环境不要用裸 HTTP 传输 MCP 消息因为工具调用可能携带数据库查询、文件内容、内部接口地址等敏感信息。最简单的做法是在前面架一道 Nginx让 Nginx 统一处理 TLS 证书和请求分发如果你不想引入额外组件也可以直接在 Node 里用https模块加载证书。最后是会话清理和并发限制。我在代码里用 Map 存了 session如果不清理长期运行后内存会一直涨。建议加一个定时器回收超过一定时间没有活跃请求的 session。另外每个 session 会拉起一个子进程如果有人脚本化地批量创建 session系统资源很快会耗尽。最好全局维护一个活跃 session 数量的计数器超过阈值就拒绝新的initialize请求。3.4 用守护进程把桥接服务跑起来开发环境里node bridge.js凑合能用但正式环境要让它开机自启、崩溃自动拉起来。Linux 上推荐用 systemd写一个 service 文件指定ExecStart、环境变量和日志路径。如果你习惯用 PM2也可以直接用pm2 start bridge.js --name mcp-bridge管理。容器化也是很好的选择把server.js、bridge.js、依赖打包进一个镜像对外只暴露 HTTP 端口。无论用哪种方式都要确保子进程的日志能被捕获。stdio server 在子进程里跑如果它输出到 stderr是桥接层级联日志的一部分如果它在 stdout 里乱打日志就会污染协议通信这个问题我在后面专门讲。4. 远程调用实战从客户端配置到调用链验证4.1 用 curl 手工验证桥接层代码跑起来之后先别急着拿 AI 客户端试。用curl手工走一遍 MCP 握手能最快暴露问题。第一步发initializecurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H Authorization: Bearer your-token \ -d {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:curl,version:1.0}}}注意在返回的响应 header 里找到Mcp-Session-Id后面的请求都要带上它。然后发notifications/initialized通知再发tools/listcurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer your-token \ -H Mcp-Session-Id: 上一步拿到的sessionId \ -d {jsonrpc:2.0,id:2,method:tools/list}正常情况下你应该能拿到包含echo工具的列表。最后发tools/callcurl -X POST http://127.0.0.1:3000/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer your-token \ -H Mcp-Session-Id: sessionId \ -d {jsonrpc:2.0,id:3,method:tools/call,params:{name:echo,arguments:{text:hello}}}返回结果里应该有content数组包含echo: hello。这一趟如果顺利说明桥接层核心链路已经通了。4.2 在常用 AI 客户端里接入 HTTP MCP现在很多主流 AI 客户端都支持使用 URL 形式的 MCP server。以 Claude Code 为例可以用类似这样的命令添加一个 HTTP MCP serverclaude mcp add --transport http my-remote-server http://your-server:3000/mcp --header Authorization: Bearer your-tokenCursor、Trae 这类 IDE 也提供了 MCP 配置界面通常可以在里面选择 HTTP 类型填写 URL 和自定义 Header。要注意的是不同客户端对自定义 Header 的支持程度不一样。有的客户端界面里没有地方填 Header这种情况通常只能通过环境变量传递给后端进程或者使用客户端内置的“请求头”配置入口。如果你实在没法传 Header也可以退而求其次在内网环境用 URL query 参数传 token但对于公网服务我不建议这么干因为 URL 会出现在访问日志里。配置好之后直接在客户端对话里让 AI 调用工具。如果客户端没有按预期列出工具先检查桥接层的日志看看tools/list是否被调用、返回了什么内容。从客户端到 HTTP 接入层再到 stdio 子进程这条链路上的每个环节都可以单独观察这也是自己写桥接层的一大优势。4.3 典型场景把 stdio 工具变成团队共享能力这种转换方式最典型的应用是把那些只提供 stdio 启动方式的官方工具变成团队共享服务。举个例子我调试浏览器页面时经常用到 chrome-devtools-mcp官方 npm 包默认启动方式就是 stdio server单机用起来很方便但团队其他成员如果也想连我本地调试的浏览器就很不现实。用本文的桥接层把它包成 HTTP 服务后只要网络可达、有 token其他人也能通过 URL 方式连接同一个调试能力。类似的还有 Playwright MCP、数据库查询 MCP、Figma 的 MCP 插件等。只要是“命令行启动一个 stdio server”的工具理论上都可以被这套桥接逻辑包起来。唯一要额外留意的是这类工具往往会在本地启动浏览器、打开端口或读取文件做成远程服务之前一定要想清楚权限边界哪些人能用、能用在哪些 URL 上、会不会被拿去访问不该访问的资源。毕竟工具越强大被滥用的风险也越大。5. 常见问题与排查技巧实录5.1 连接失败端口、绑定地址、防火墙我见过最多的现象是本机 curl 一切正常换一台机器就连接超时。这个问题大概率是监听地址或防火墙导致的。先用ss -lntp | grep 3000看桥接服务到底监听在哪个地址上如果看到的是127.0.0.1:3000那其他机器当然连不上。改成0.0.0.0:3000或具体的内网 IP 后再检查防火墙是否放行了对应端口。远程客户端如果返回 502 或 503则要重点看桥接进程是否活着以及 stdio 子进程是否异常退出。还有一种情况我遇到过客户端用http://访问到了只配置了 HTTPS 的端口服务端会直接返回类似400 Bad Request: The plain HTTP request was sent to HTTPS port。这种情况不是 MCP 的问题单纯是客户端把协议写错了把 URL 改成https://即可。5.2 stdio 子进程 stdout 被污染导致协议解析失败这是我自己写桥接层时踩过最深的坑。stdio MCP 的通信通道是标准输出可很多开发者习惯在代码里用console.log打印调试信息。如果这个console.log跑在 MCP server 内部而你的 server 又通过 stdio 传消息那这些日志就会被当成 JSON-RPC 消息发送给客户端轻则解析失败重则导致整个会话卡死。这类问题排查起来也很头疼因为日志往往是无意的。建议做法是在实现 MCP server 时所有业务日志一律走 stderr或者写到独立文件转换层在看到子进程 stdout 中出现无法解析的行时也要能抛出明显错误方便快速定位。如果你接手的是一个别人写的 server没法改代码那只能在桥接层做防御性处理比如过滤掉非 JSON-RPC 行但这可能会掩盖问题最好的方案还是让源头干净。5.3 超时与长时间运行的工具任务HTTP 传输天然有超时机制但 MCP 工具执行时间可能非常长。如果你在本地 stdio 模式下调用一个耗时几分钟的工具没问题转成 HTTP 后却总是报超时大概率是接入层或 HTTP 客户端的默认 timeout 设置太短。Express 的默认超时不一定够用Nginx 这样的接入层默认proxy_read_timeout也只有 60 秒左右。处理方式有两种一是调大超时时间适合工具确实需要几分钟才能返回的场景二是改成异步任务模式接口先返回一个任务 ID客户端通过其他接口轮询结果。后者实现复杂但更合理尤其是工具内部会触发副作用时客户端一旦超时重试很容易导致同一个任务被重复执行。我个人建议容易被调用的工具尽量设计成快速返回重活放到后台队列里做MCP 只负责提交任务和查询状态。5.4 会话并发过高与资源管理每个 HTTP session 对应一个 stdio 子进程这个模型简单直观但代价是资源开销很大。如果有人反复创建 session 而不主动关闭服务端的进程数会不断上涨最终拖垮整台服务器。我一开始没做限制结果一次联调测试就把进程数跑到了几百个内存直接吃满。做好两件事可以避免这种情况一是限制最大并发 session 数超过阈值直接拒绝新的initialize二是实现空闲回收定期清理超过 N 分钟没有请求的 session。桥接层还应该对notifications/initialized之后长期没有任何请求的连接做保活或断开策略避免半开连接占用资源。5.5 认证失败与客户端不支持自定义 Header启用鉴权后最常见的问题是 401。先检查 token 是否通过环境变量正确传入再确认客户端发送的 header 格式是不是标准的Authorization: Bearer xxx。有些客户端会自动把请求体里的某些字段塞到 header但不会带自定义 token有些客户端界面名叫 “Header” 但底层用的是 basic auth。遇到这种情况我的建议是尽量选择支持自定义 header 的客户端或者用前面提到的接入层统一做认证让每个客户端只负责提供 MCP 请求认证交给网关处理。还遇到过一种情况客户端本身能正常认证但某个工具内部又发起了外部的 HTTP 请求那个请求也需要认证。这个跟桥接层无关但容易被误判为桥接层的问题。排查时记得把调用链拆开看先确认到 MCP server 这一步是否通过认证再查工具内部逻辑。5.6 进程守护与日志审计远程服务的稳定性不能靠运气。即使你的桥接层代码没问题stdio 子进程也可能因为外部原因退出比如内存不足、被系统杀掉、文件描述符耗尽。所以桥接层需要处理子进程意外退出的情况检测到退出后主动注销对应的 session并返回明确的错误码给客户端避免客户端拿到一个永远无响应的连接。日志审计同样重要。我在桥接层里给每个请求都加了一行 JSON 日志包含时间、sessionId、method、请求耗时和返回码。这样一旦有问题可以直接从日志里还原出客户端到底做了什么操作。生产环境还可以把日志接入统一日志平台按 user 或 session 维度汇总发现异常调用行为。6. 写在最后几个我以为重要的小细节连续折腾了几天之后我最直观的感受是stdio 转 HTTP 本身不难难的是把状态管理、安全边界和异常恢复想清楚。初期我也图省事直接用社区工具把端口暴露出去结果一天下来被一堆请求打满了日志从那以后我把鉴权、绑定地址和会话限制都当成了必选项而不是可选项。如果你也在做类似的事最后分享一个小技巧调试桥接层时先用 MCP Inspector 指向你的 HTTP 地址确认协议层没问题再用 Cursor 或 Claude Code 去连。如果业务逻辑有问题查 stdio 子进程的 stderr如果协议有问题查 HTTP 请求和响应头。分层排查远比在客户端里反复重连高效得多。希望这篇记录能帮你少走几步弯路。