聊 MCP 的三种传输方式之前先承认一件事大多数人在看 MCP 文档的时候最容易卡住的就是传输层这一节。stdio、SSE、Streamable HTTP 三个词单独拎出来都认识合在一起却不知道它们为什么同时存在、各自解决什么问题。这不怪你因为 MCP 的传输层设计带有很明显的演进痕迹——从本地进程管道到 HTTP 长连接再到统一的流式 HTTP每一步都是被真实场景逼出来的。MCPModel Context Protocol是 AI 应用和外部工具、数据源之间通信的开放协议消息格式统一走 JSON-RPC 2.0。客户端要调用工具、订阅资源、接收通知说到底都是在传输层上搬运一条条 JSON-RPC 消息。传输方式不只是管道这么简单它决定你的 MCP 服务端能部署在哪里、客户端用什么方式连、连接生命周期怎么管理、安全边界画在哪。同样是写一个工具服务跑在本地笔记本上还是部署在远程服务器上传输层的选择完全不同。这篇文章我会围绕实际开发视角把三种传输方式的原理、消息流转、适用场景和踩坑经验完整过一遍。无论你是刚开始写 MCP 服务端还是正在评估本地工具走 stdio、远程服务走 HTTP这类架构应该都能从中拿走一些直接用得上的信息。1. MCP 传输层到底是什么先建立正确的认知框架1.1 协议层和传输层的分工MCP 的分层思路跟 HTTP 很像。协议层负责说什么定义 JSON-RPC 2.0 的方法名、参数、返回结构。你在 MCP 文档里看到的 initialize、tools/list、tools/call、notifications/resources/updated 都属于协议层。传输层负责怎么说消息以什么编码、走什么通道、用什么模型管理连接。两者解耦之后换传输方式不需要改业务代码这也是官方 SDK 一直在维护 Transport 抽象的原因。写 MCP 服务端时我的习惯是把协议处理逻辑请求分发、工具调度、错误处理和传输逻辑读消息、发消息、连接管理拆成两个模块。协议模块保持传输无关对外暴露一个收到一条消息、回一条消息的接口传输模块负责把接口接到具体通道上。这样不仅 stdio 和 HTTP 之间切换成本低连测试也方便直接构造消息就能跑协议层的单元测试。很多人在项目早期图省事把消息解析和业务逻辑揉在一起等到要加 HTTP 传输时才发现到处都耦合了 stdin/stdout改起来非常痛苦。MCP 协议本身不限定传输方式这意味着同一份 protocol 层代码可以跨传输复用。实际项目中我用 stdio 实现了本地工具集后来同一个协议模块几乎原封不动地挂到 Streamable HTTP 上供远程客户端访问只换了传输层一个组件。分层带来的收益在项目规模变大之后会越来越明显。1.2 三者的本质差异进程、双通道、单端点三种传输方式背后是三种截然不同的资源模型理解这一点比背任何 API 都重要。stdio 是进程模型。客户端负责拉起服务端子进程子进程的 stdin/stdout 就是消息通道连接的生命周期等于子进程生命周期。只要进程不退出通道就是可用的进程死了连接自然断开。这里没有端口、没有 URL、没有网络连接的概念。HTTPSSE 是双通道模型。服务端暴露两个 HTTP 端点一条 SSE 长连接用于服务端往客户端推消息一个普通 POST 端点用于客户端往服务端发请求。双向通信靠两条独立通道拼出来这是它管理复杂度高的根源。Streamable HTTP 是单端点模型。一个 HTTP 端点既能处理客户端请求也能按需回推流式消息。服务端根据客户端 Accept 头决定返回普通 JSON 还是 SSE 流还能用 GET 建立长连流、用 DELETE 主动断开会话。会话状态通过 mcp-session-id 头显式传递不再依赖临时 URL 和连接的一对一绑定。把三者放在演化轴上看会更清晰stdio 解决本机进程通信HTTPSSE 解决跨机器通信Streamable HTTP 解决前两者的统一与现代 HTTP 生态落地问题。MCP 规范从早期版本走到现在HTTP 传输定义经历过一次大调整现在官方推荐远程服务用 Streamable HTTPstdio 作为本地传输一直被保留。理解了这些背景之后再看各种 MCP 客户端配置里command args和url两种配置项的差异就不会再迷茫了。1.3 一个容易忽视的前提JSON-RPC 消息才是主角无论在哪种传输方式下传输层搬运的统一是 JSON-RPC 2.0 消息。有三类消息必须区分清楚请求Request带唯一 id必须有对应响应。通知Notification不带 id不需要响应比如日志、进度更新。响应Response匹配请求的 id携带结果或错误信息。一个典型场景客户端调 tools/call 请求服务端执行某个工具。如果是普通请求-响应服务端处理完返回 result 即可如果工具执行时间长服务端可以先用通知发进度再在结束时返回最终 result。这些消息语义在三种传输里完全一样差别只在于服务端能否主动推消息。stdio 里两边都是写管道主动推送就是直接写 stdout天然双向支持SSE 里服务端靠 SSE 流推Streamable HTTP 里服务端通过返回的流推。这个主动推送能力是选型时极容易被忽略的点。很多人只看能不能连上忽略了工具执行过程中能不能给客户端持续回报状态。如果你要做的工具本身就是长任务比如批量处理文件、调用外部慢接口传输层对推送的支持程度会直接影响用户体验。后面讲到具体传输时我会反复回到这个维度上。2. stdio 传输本地进程通信的朴素方案与实战避坑2.1 stdio 如何搬运 JSON-RPC管道机制与消息格式stdio 的做法是把 MCP 服务端当子进程跑。客户端进程 spawn 服务端程序然后拿子进程的 stdin 当发送通道、stdout 当接收通道。消息格式有硬性要求每条消息必须是一整行 JSON末尾带换行符消息内部不能出现未转义的换行也不能一行塞多条消息。为什么这么设计为了解析简单。按行读取是成本最低的解析方式客户端和服务端都不需要引入额外的消息边界协商逻辑不会出现部分帧、粘包这类问题——行本身就是边界。相比长度前缀协议比如 WebSocket 的帧头按行分割几乎没有实现成本对本地进程通信来说足够用了。JSON 本身不支持裸换行所以序列化之后天然不会破坏行边界这也是一种巧妙的约束叠加。一个最小可用的 stdio 服务端在 Node.js 里大概长这样const readline require(readline); const rl readline.createInterface({ input: process.stdin }); rl.on(line, async (line) { const request JSON.parse(line); const response await handleRequest(request); // 你的协议处理函数 process.stdout.write(JSON.stringify(response) \n); });所有调试日志一律走 process.stderr 或 console.error这一点再怎么强调都不过分。我见过不止一个项目在服务端代码里漏了一行 console.log结果客户端莫名其妙报JSON 解析失败排查了半天才发现是日志污染了 stdout。提示stdio 模式下 stdout 是协议专用通道任何非 JSON 内容都会破坏消息流。日志请一律走 stderr。真要在生产环境用 stdio 接入多个本地工具建议在服务端启动阶段就显式约定stdout 只写协议消息这一规则项目内禁用 console.log统一走日志框架。团队里新来的成员最容易在这个地方犯错代码审查时把这个作为硬性要求能省掉很多线上事故。2.2 stdio 的完整生命周期与配置实操stdio 的会话生命周期完全跟着子进程走。客户端负责三件事启动进程、喂消息、处理退出。在 Python 客户端里启动和发送 initialize 请求大概是这样import subprocess, json proc subprocess.Popen( [node, server.js], stdinsubprocess.PIPE, stdoutsubprocess.PIPE, stderrsubprocess.PIPE, ) def send(req: dict) - dict: proc.stdin.write((json.dumps(req) \n).encode()) proc.stdin.flush() line proc.stdout.readline() return json.loads(line) resp send({ jsonrpc: 2.0, id: 1, method: initialize, params: { protocolVersion: 2024-11-05, capabilities: {}, clientInfo: {name: local-client, version: 0.1.0}, }, }) print(resp)这套模式就是连接的绝大部分。上层应用通过配置文件告诉客户端怎么启动这个进程命令是什么、参数是什么、环境变量有哪些。常见的 MCP 客户端配置里会有一个 mcpServers 段落里面每项最多就是一个 command、一组 args、一组 env。相比 HTTP 服务没有端口、没有 URL、没有鉴权配置成本低到可以忽略。但生命周期管理恰恰是坑最多的地方。进程退出时要判断是正常退出还是异常退出检查退出码和 stderr 输出客户端退出时要主动 terminate 子进程避免残留孤儿进程。我在做本地服务封装时还发现一个细节有些服务端程序收到结束信号不会主动清理临时文件和释放资源必须在客户端侧统一兜底退出时先给子进程发结束信号等几秒不行再强杀。这个兜底逻辑看着简单在跨平台环境下比如 Windows 上没有标准 SIGINT 语义尤其容易出问题需要针对平台分别处理。另一个实际经验是不要把 stdout 的读取放在一个不设超时的阻塞循环里。如果服务端因为某种原因没有输出比如死锁了客户端就会永久挂起。给行读取加超时或者做一个看门狗线程超时后主动杀掉子进程并上报错误比让用户干等强得多。2.3 为什么 stdio 只适合本地边界、安全与性能stdio 最重要的特性是不暴露网络。服务端程序只跟父进程通信外部机器无法主动连进来没有端口扫描、没有越权调用这类网络攻击面。本地文件访问、读取密钥、操作本机数据库这类权限敏感的工具用 stdio 是天然安全的——使用权限就是进程启动权限谁启动了这个进程谁就拥有它的能力用户对这一点有清晰感知。也正因为如此stdio 的范围被锁定在客户端和服务端在同一台机器、同一个用户的本地场景。跨机器部署、多人共享、Web 端接入基本都不适合。一旦服务端要部署到服务器上、让多个远程客户端并发访问stdio 就完全使不上劲。有人会尝试用远程命令执行的方式包装 stdio 实现远程 stdio那会引入另一套复杂度和安全隐患而且失去 stdio 最大的优势。性能方面stdio 的管道吞吐足以支撑本地调用链路上频繁的工具调用JSON 序列化和反序列化反而可能是主要开销。真正的性能瓶颈很少出现在管道本身更多出在服务端实现里有没有正确处理并发。这里要特别提醒一点stdio 虽然是管道通信但 MCP 协议没有规定必须串行处理消息。客户端完全可能在未收到前一个请求响应时就发送下一个请求服务端如果按 readline 逐行 await 处理实际上就变成了串行高并发场景下整体响应会被拖慢。如果服务端的工具是 IO 密集型的异步操作建议直接异步处理请求响应顺序由响应里的 id 保证而不是靠处理顺序保证。3. SSE 传输被 HTTP 长连接压垮的半双工方案3.1 理解 SSE 的协议本质单向推送加额外回传通道SSEServer-Sent Events本身是 HTML5 标准里的技术用于服务器向浏览器单向推送事件。它的做法是客户端发起一个普通 HTTP GET 请求服务器收到后不结束响应而是保持连接打开持续往响应体里写事件数据。每条 SSE 事件由若干字段组成最重要的就是 data 字段以两个换行符作为事件分隔data: {jsonrpc:2.0,id:1,result:{protocolVersion:2024-11-05}}MCP 早期版本的 HTTP 传输选择 SSE看中的是它不需要额外依赖原生 HTTP 就能支持、天然适合服务端向客户端推送通知的场景。但 SSE 有一个本质限制它是单向的。客户端想发消息给服务端不能复用这条 SSE 连接必须另走一条 HTTP 通道。所以在老版 MCP HTTP 传输里服务端一般暴露两个端点一个用于建立 SSE 流的端点一个用于接收客户端 POST 请求的消息端点。这也解释了为什么老版 SSE 用起来总有一种别扭感一个双向会话被硬拆成了两条单向通道所有状态都要在这两条通道之间同步任何一个环节掉链子会话完整性就出问题。相比之下WebSocket 天然双向但服务端支持和中间件穿透成本比 SSE 高不少MCP 早期选择了 SSE 也是权衡之后的结果。3.2 老版 HTTPSSE 的会话拆解endpoint 事件与消息端点老版 HTTPSSE 的完整会话流程是这样的客户端 GET 请求服务端的 SSE 端点服务端建立 SSE 连接后续所有服务端到客户端的消息都往这里推。服务端在 SSE 连接建立后先推送一个特殊的 endpoint 事件里面带一个消息端点的 URL。这个 URL 通常是服务端临时生成的可能带着 session 标识event: endpoint data: /mcp/message?sessionIdabc123客户端拿到这个 URL 后后续的 JSON-RPC 请求都通过 POST 方式发到这个消息端点。服务端处理完请求响应通过第 1 步建立的那条 SSE 连接推回给客户端。这套流程最大的问题在于管理起来很拧巴。一个完整的请求-响应跨了两条 HTTP 通道任何一条出问题会话就处于悬空状态。SSE 连接断了客户端的 POST 请求可能还在发出服务端的响应却发不回去。客户端要实现会话恢复必须跟踪当前工作的是哪条 SSE 连接、对应哪个消息端点这组状态同步在无状态 HTTP 场景里非常反直觉。实际项目中我遇到的典型问题还有两类。一类是代理缓冲不少 HTTP 代理和网关默认会缓冲响应体SSE 长连接的内容如果被缓冲客户端会长时间收不到事件表现就是偶尔能通、时不时卡住。必须在代理层关掉缓冲或设置合适的 flush 行为。另一类是连接超时常规 HTTP 链路有超时设置SSE 如果长时间没有事件比如一个耗时工具几十秒没输出中间层可能直接把连接掐了。SSE 规范本身建议服务端定期发以冒号开头的心跳注释行维持连接MCP 服务端实现时也应该加上心跳客户端也别把超时调得太短。3.3 为什么老版 SSE 会被取代并发、会话与实现复杂度从协议设计角度说老版 HTTPSSE 不是不能用而是复杂度管理成本太高。MCP 规范演进后官方明确推荐远程 HTTP 服务使用 Streamable HTTP老版 SSE 传输逐渐被标记为废弃。原因可以归纳为三点。第一双端点设计割裂了会话。SSE 连接和消息端点之间靠临时 URL 绑定代理、负载均衡、客户端重连都会破坏这个绑定。服务端要维护一张sessionId 到 SSE 连接的映射表多个服务实例部署时还得考虑映射表存哪里一趟下来复杂度直接上了一个数量级。第二响应格式分裂。同样的 JSON-RPC 响应有时从 SSE 流里来有时从 POST 响应的 body 里来客户端得维护两套解析逻辑。老版规范里这个边界尤其模糊服务端到底走流还是直接回 JSON很多时候没有明确约定导致客户端实现五花八门。第三没有标准化的终止机制。客户端想主动断开会话只能靠关闭 SSE 连接服务端依赖连接断开的底层事件来清理资源。在代理层拦截、连接泄漏等情况下服务端很难可靠感知会话结束时间一长就容易积累一堆僵尸会话。这些痛点正是 Streamable HTTP 着重解决的。4. Streamable HTTP远程 MCP 服务的当前标准玩法4.1 三个关键改进单端点、双响应模式、可终止会话Streamable HTTP 是 MCP 规范在 2025 年引入并确立的 HTTP 传输方式设计目标很明确把老版 SSE 的复杂度在协议层消灭掉。我总结它的三个关键改进。第一单端点。客户端只需要知道一个 base URL所有 JSON-RPC 消息都 POST 到同一个端点。不再需要先 GET 建立流、拿 endpoint 事件、再跑去另一个地址发消息。服务端可以同时支持 GET 用于打开 SSE 流、POST 用于收发消息、DELETE 用于终止会话但常规请求响应只需要 POST。第二双响应模式。客户端在 POST 请求里通过 Accept 头声明自己期望的响应格式application/json 表示接受普通 JSON 响应text/event-stream 表示接受 SSE 流。服务端根据 Accept 头决定返回方式。核心思想是如果这次请求-响应不需要服务端主动推送过程性消息直接返回 JSON 就够了如果需要流式推送工具执行进度、资源更新通知等就返回 SSE 流。响应不一定非要用流这就给了服务端很大的灵活性。第三标准化的会话生命周期。服务端可以在首次请求的响应里带 mcp-session-id 头后续请求带上这个头就能保持会话。GET 用于打开一条 SSE 流让服务端随时推送通知DELETE 用于主动终止会话服务端能借此释放资源。会话该不该建、建多久、谁负责销毁终于有了一套明确约定。注意Streamable HTTP 不是抛弃了 SSE而是把 SSE 从传输方式降级为消息编码的一种可选项。需要推送时用 SSE 编码不需要时用纯 JSON一个端点按需切换——这是它设计上比老版优雅的核心原因。我在实际使用中的感受是Streamable HTTP 最打动人的地方是服务端可以选择怎么回应。你可以在一个请求里直接返回 JSON 结果也可以在另一个请求里开启流式返回客户端不需要预先知道这次请求会走哪种模式靠 Accept 头和响应头协商就行。这种弹性让传输层从固定的管道变成了按需适配的通道。4.2 服务端实现要点Accept 协商与会话设计写 Streamable HTTP 服务端核心逻辑是响应协商。一个简化版的框架思路server.post(/mcp, async (req, res) { const accept req.headers.accept ?? application/json; const message req.body; // JSON-RPC 消息 const result await handleMessage(message, req.headers[mcp-session-id]); if (accept.includes(text/event-stream)) { // 需要流式返回时回一个 SSE 流 res.setHeader(content-type, text/event-stream); res.write(data: ${JSON.stringify(result)}\n\n); res.end(); } else { // 普通请求-响应 res.setHeader(content-type, application/json); res.send(JSON.stringify(result)); } });这个示例只展示了最简单的分支。真正生产级的实现还要考虑流式模式下工具执行过程中可能有进度通知事件怎么穿插在最终 result 之前会话校验失败时返回什么错误码keep-alive 心跳怎么维持 GET 流不断开。我的建议是不用手写这些直接用官方 SDK 里现成的 Transport 实现它把这些细节都封装好了你只需要注册协议处理器。手写传输层是一次很好的学习过程但生产环境没必要重复造轮子。会话管理上有状态和无状态两种风格我都见过。简单本地部署可以做成有状态内存里存 sessionId 到上下文的映射多实例部署建议无状态把必要的会话上下文序列化后放进 mcp-session-id 头里或者使用外部存储让任意实例都能处理同一会话的请求。选哪种取决于你的实际拓扑但一定要把会话清理想清楚。我见过一个线上服务因为客户端异常退出时没有调 DELETE服务的会话映射表一直不清理内存缓慢上涨最后只能靠重启缓解。服务端可以加一个空闲超时回收机制定期清理长期不活跃的会话。4.3 客户端接入要点响应分支与旧版兼容客户端接入 Streamable HTTP关键也是看响应头。发送 POST 请求时Accept 头建议同时声明两种格式const res await fetch(https://mcp.example.com/mcp, { method: POST, headers: { Content-Type: application/json, Accept: application/json, text/event-stream, }, body: JSON.stringify(request), });拿到响应后先看 content-type再决定走哪条解析路径。application/json 就直接解析 body 里的 JSON-RPC 响应text/event-stream 就按 SSE 格式逐段解析事件。如果响应头里引入了 mcp-session-id记得存下来后续请求带上。兼容老版客户端也是 Streamable HTTP 规范里明确考虑的如果客户端只带 Accept: text/event-stream服务端可以退回老式 SSE 行为。对服务提供方来说如果服务暴露在公网给各种第三方客户端用响应分支要写得健壮尤其是 HTTP 状态码和错误信息的处理。很多客户端在收到非 200 的响应时会直接判定失败但你必须在错误响应体里带上 JSON-RPC 错误结构让客户端能把错误透传给上层。我还遇到过一个性能细节不要把每次 POST 都默认要求流式返回。对 tools/call 这种一问一答的调用直接 JSON 响应最快initialize、工具列表这些更是只适合 JSON。流的价值在于长任务、进度推送和订阅场景。客户端如果对所有请求都声明要流式很多服务端实现会强制走 SSE白白增加连接管理和解析开销。正确做法是 Accept 头里两种格式都带上让服务端根据请求特性自己选择最优响应方式只有对确实需要进度反馈的请求才单独强调流式支持。5. 三种传输方式怎么选一份可以直接抄的对照手册5.1 传输方式差异速览表维度stdio老版 HTTPSSEStreamable HTTP通道模型子进程 stdin/stdoutSSE 长连接 POST单 HTTP 端点部署位置本机同一进程树远程 HTTP远程 HTTP连接生命周期等于子进程生命周期等于 SSE 连接生命周期会话 ID 管理GET/DELETE 控制服务端主动推送写 stdout 即可通过 SSE 流按需 SSE 流网络暴露无暴露 HTTP 端口暴露 HTTP 端口鉴权不适用本地需自行实现支持标准 HTTP 鉴权方式典型场景本地文件、本地数据库、开发工具链老系统遗留接口新远程服务、公网部署协议状态一直保留推荐已废弃当前推荐配置复杂度最低commandargs较高两个端点加会话映射中单 URL 加可选会话头这张表基本覆盖了我选型时全部会关心的维度。最直观的结论是本地优先 stdio远程优先 Streamable HTTP老版 SSE 除非你已经在维护存量系统否则没有任何理由在新项目里选它。5.2 按场景选型的实战建议我把实际项目里最常见的几种场景整理成建议可以直接套用。给 AI 编程工具挂一个本地工具服务比如文件操作、读取项目结构、调用本地命令行选 stdio。无网络暴露、配置简单、跟本地环境天然绑定。给公司内部搭建供多个团队共用的 MCP 服务比如统一的知识库查询接口选 Streamable HTTP。需要并发访问、需要鉴权、需要监控HTTP 生态里这些都是成熟方案。在浏览器 Web 应用里接入 MCP选 Streamable HTTP。老版 SSE 的双端点设计对浏览器端的 fetch 和 EventSource 都不友好单端点方案干净得多。在边缘函数、Serverless 环境里跑 MCP选 Streamable HTTP并且尽量无状态化会话信息用 mcp-session-id 头携带。维护老系统如果存量客户端已经按老版 SSE 对接可以继续用但要在底层做好连接保活和会话重建新功能一律按 Streamable HTTP 扩展。一个容易被忽略的点是转发场景。如果你的 MCP 服务端只是一个薄转发层背后还有真正的业务系统传输选型更要谨慎。stdio 转发到远程是自欺欺人老版 SSE 做转发会放大连接管理的复杂度Streamable HTTP 配合标准鉴权和会话机制是最省心的。我做内部网关的时候就吃过亏最开始图省事用老版 SSE 转发结果上游服务一切换、会话映射就乱套后来重写成 Streamable HTTP问题直接消失。6. 传输层常见问题与排查技巧实录6.1 问题现象与解决速查表现象可能原因排查方向与解法stdio 模式报JSON 解析失败服务端日志混入 stdout检查服务端代码里的 console.log统一改走 stderr在客户端侧打印原始日志辅助定位stdio 模式工具调用后卡住服务端进程退出或死锁检查退出码和 stderr确认服务端是否异步处理长任务别阻塞事件循环SSE 连接时不时断线代理缓冲、中间层超时、心跳缺失关代理缓冲服务端加心跳事件客户端把超时调大并做好重连老版 SSE 会话恢复失败endpoint 事件携带的临时 URL 失效确认服务端是否把 sessionId 和 SSE 流稳定绑定重连时重新建立 GET 流Streamable HTTP 返回 406服务端不认可客户端 Accept 头确认 Accept 头同时带 application/json 和 text/event-stream查看服务端规范要求Streamable HTTP 长任务无进度客户端没要求流式服务端走了普通 JSON对这种请求强调 text/event-stream Accept服务端实现按需协商HTTP 会话内存缓慢上涨会话没被 DELETE服务端映射表未清理客户端退出时调 DELETE服务端加空闲超时回收远程 HTTP 鉴权失败头名或凭据传递方式不对确认客户端使用的鉴权头和 MCP 服务端期望的一致这张表里的问题我几乎全都实际撞见过。最魔幻的一次是 SSE 连接在测试环境一直正常、一上生产就断最后定位到生产网关开启了响应缓冲SSE 事件被囤积在网关层客户端等不到下一个事件触发超时。这类问题有个共性传输层的问题表面上是连接不稳根因往往在链路中间件和配置上而不是 MCP 本身。6.2 排查思路与方法论沉淀排查 MCP 传输问题我总结了一套固定顺序能省很多时间。第一先确认消息有没有到达对端。在服务端打印收到的每条原始消息在客户端打印收到的每条原始响应。传输层的问题九成会在消息流日志里现出原形。stdio 就把 stderr 日志打开看HTTP 就在代理层或服务端加请求日志。先看数据有没有通再看通得对不对。第二区分连接问题和消息问题。连接问题表现为断连、超时、重连消息问题表现为 JSON 解析失败、协议字段错误。两类问题的排查入口完全不同。连接问题先看中间层代理、负载均衡、防火墙消息问题先看序列化和协议实现。我最常看到的情况是大家把所有问题都当连接问题排查绕着圈找不到点。第三用最小复现收窄范围。写一个只发 initialize 请求的最简客户端脚本从握手开始一级一级往上试。MCP 的握手initialize、initialized、工具列表每一步都有明确响应哪一步断了问题就定位在哪一层。我帮别人排障时最常说的就是不要一上来就跑复杂工具调用先让最小握手跑通再逐步增加复杂度。第四关注协议版本。MCP 规范版本迭代快服务端声明的 protocolVersion 跟客户端不一致时某些行为可能完全不同。如果你用了预发布版本的 SDK注意它实现的传输规范是哪个版本。对外提供服务的尽量在 initialize 响应里如实上报版本客户端做兼容判断也有依据。我个人还有一个习惯给每个 HTTP 传输的 MCP 服务都加一个健康检查端点返回协议状态、活跃会话数和最近错误计数。这相当于给传输层上了监控问题爆发前往往能从会话数异常增长里先感知到。最后说一个很多人没意识到、但实际价值很高的点传输选型不是一次性的。早期你可能只是本机工具用 stdio后来业务起来了想把同一个工具能力开放给远程团队就需要在同一份协议处理逻辑上换一个 Streamable HTTP 传输。这正是 MCP 分层设计最大的红利。我自己的项目就是从这条路径走过来的先把业务逻辑封装成传输无关的协议模块后来接 HTTP 只花了一个下午。所以不管你现在只用哪种传输都建议把协议层和传输层保持解耦——这是我能给出的最实用的一条建议。