本地应用接一个文件工具，与多个应用访问远程工具服务，对连接方式的需求不同。选 MCP 传输时，先看谁启动服务、两端在哪里运行，再看客户端支持的协议版本。
我对照了 MCP 官方的 2026-07-28 传输规范整理这篇文章。下面围绕 Client 与 Server 的通信讲解，旧项目应按实际采用的规范和 SDK 版本核对。
stdio 连接一个由应用启动的进程
采用 stdio 时，Client 启动 MCP Server 子进程，通过标准输入发送协议消息，从标准输出接收协议消息。消息是按换行分隔的 JSON-RPC 数据。
它适合由应用管理的本地服务，不需要单独为这段通信开放 HTTP 端口。进程启动失败、运行文件路径错误，或者标准输出混进了一行调试日志，都可能让接入出问题。
标准输出应只写合法的 MCP 消息。调试日志写到标准错误，客户端再按需要记录。排查"工具服务明明启动了，客户端却读不懂"时，先检查这两个输出有没有混在一起。
stdio 只描述 Client 与这一个进程的通信。进程内部仍然可以调用远程接口，能访问哪些资源取决于实现与权限。启动本地服务时，同样要检查可执行文件和它的访问范围。
Streamable HTTP 连接独立服务
工具服务在另一台机器上，或者需要被多个应用访问，可以采用 Streamable HTTP。Client 向 MCP 端点发送 HTTP 请求，Server 可以用普通 JSON 返回结果，也可以用 SSE 返回协议消息流。
按本文采用的规范，客户端需要支持这两种响应形式。只把所有响应都交给 response.json()，遇到 SSE 就处理不了；反过来要求每个工具都建立持续事件流，也会误判普通 JSON 响应。
HTTP 部署还增加了实际的网络条件。代理超时、响应缓冲和连接断开，都可能影响长请求。可以先用一个快速完成的只读工具确认请求与结果，再测试一个会发送进度通知的长任务，分别观察应用真正收到了什么。
先确认消息能完整到达，再检查代理和客户端各自的超时设置。性能则需要在具体部署环境里测量。
三种流式行为各有一段实现
| 行为 | 谁需要处理 | 可以检查什么 |
|---|---|---|
| MCP 响应用 SSE 发送消息 | MCP Server 与 Client | 通知和最终响应能否被正确解析 |
| 工具报告执行进度 | 工具、协议实现与应用 | 进度是否产生，应用是否展示 |
| 模型逐步输出答案 | 模型接口与前端 | 工具结束后，模型输出是否按预期渲染 |
假设查询订单的工具很快就能拿到结果，可以一次返回 JSON。生成大报表的工具可能发出进度通知，应用收到以后再决定是否展示进度。模型根据报表组织文字时，还需要模型接口自己的流式输出能力。
因此，看到 Streamable HTTP 这个名称，还需要继续检查后面的工具实现和界面。协议消息在流动，不会自动让所有业务结果变成逐字输出。
版本和权限要在接入时核对
接一个已有服务时，记录 Client、Server 和 SDK 支持的规范版本。旧教程中的 GET 流、会话标识和恢复机制，都应回到那个版本的文档确认，不能把某段示例代码直接当成所有版本的固定流程。
实际接入时，应沿着所用 SDK 的示例完成初始化、能力处理和工具调用，再核对版本相关字段。快速工具能返回结果后，再引入长任务和恢复机制，会更容易定位故障。
工具能被发现，也还要检查它能否被当前用户调用。用户身份应从可信会话获取，业务服务核对访问权限。可以发现一个退款工具，不等于这次任务已经获准退款。
如果现在只服务一个本地应用，可以先用 stdio 把调用过程跑通。需要共享远程服务时，再评估 HTTP 的部署与运维条件。性能应按相同任务实测，不能仅凭传输名称排序。
我是程序员Sunday。相关分层图和面试追问见 sunday面试指南的 MCP 传输解析。