先给结论
传输层选型取决于部署形态。若工具运行在本地，应直接选 stdio 传输。此方式将服务端作为本地子进程启动，适合文件系统、本地命令及 IDE 插件，具零网络开销与进程级隔离特征，权限等同于操作系统用户的权限。
若工具为团队共享服务，或需集中管控权限、审计与更新，应选 Streamable HTTP。该方式通过单一端点承载请求，支持按需升级为流式返回，满足远程部署与多端共享需求，但需承担网络与运维成本。
逐项对比
| 对比维度 | stdio | Streamable HTTP |
|---|---|---|
| 定位 | 本地子进程通信 | 远程网络服务端通信 |
| 强项 | 零网络开销，进程级隔离，权限等同于操作系统用户权限 | 支持远程部署、鉴权、多客户端共享与负载均衡 |
| 弱项 | 无法跨机器访问，仅限本地单机使用 | 存在网络延迟，协议未内置鉴权，安全责任较重 |
| 典型场景 | 文件系统操作，本地命令执行，IDE 插件 | 团队共享服务，需集中管控权限与更新的工具 |
| 成本 | 无服务运维成本 | 需承担网络开销与服务端运维成本 |
这两种传输方式在底层架构上有本质区分。stdio 通过标准输入输出交换 JSON-RPC 数据，将安全边界交由操作系统，客户端与服务端同处一台物理机器，省去了网络层开销。相比之下，Streamable HTTP 允许跨物理边界进行服务调用，但协议本身不内置鉴权机制，开发者必须自行实现安全校验以防止发生未经授权的越权访问。
在实际工程落地过程中，同一个服务端应用完全可以同时支持这两种不同的传输协议。这种组合用法允许工具在本地开发测试时使用单机进程模式，在生产环境发布时无缝切换为远程网络服务模式，从而兼顾开发效率与部署要求。
无论选择哪种传输路径，模型上下文协议的核心语义始终保持绝对一致。工具、资源与提示词等原语不会因为底层通信方式的切换而改变。需要澄清的是，网络模式下的流式返回语义专门用于传递生成型任务或长耗时任务的进度信息，并不适用于音视频媒体流传输。
面试怎么答
建议先向面试官确认工具的部署拓扑形态，再给出选型方案。先询问工具是供用户在本地设备独占使用，还是作为公共服务供多端调用。明确前提后，对本地场景答选用子进程通信，对公共服务场景答选用网络通信，并陈述对应的安全与运维成本。
常见错误答法是认为传输层切换会导致代码重写，或将流式响应误解为用于传输音视频文件。必须指出，核心原语在不同传输下保持一致，流式语义仅用于反馈长任务进度，以此体现对协议边界的准确理解。