一句话总结：MCP 把"说什么"和"怎么送"拆开了。stdio 是本地子进程的悄悄话，Streamable HTTP 是远程服务的标准邮件------平时寄封信就走，需要直播时才开流。** 选哪种，不看哪个"高级"，只看 Server 离你有多远、是一个人用还是一群人在用。
一、先搞懂三个词：Host、Client、Server
MCP 全称是 Model Context Protocol（模型上下文协议） ，你可以把它理解成一套"AI 和外部工具之间的通用插头标准"。它采用 Host → Client → Server 的三层结构。
Host（宿主） 就是你正在用的 AI 应用，比如 Claude Desktop、Cursor 或者公司内部的 AI 助手。它是"总指挥"，负责管理所有连接、控制权限、决定哪些工具可以用。
Client（客户端） 是 Host 内部的一个"联络员"。每一个 Server 都对应一个专属的 Client，一对一绑定，不会串线。
Server（服务端） 是真正干活的程序。它可以是本机上的一个小工具，也可以是部署在云端的远程服务。Server 负责暴露工具、资源和提示词，但它看不到完整的对话历史，只拿到自己需要的那一小块上下文。
用一句话概括：Host 是老板，Client 是秘书，Server 是外部专家。老板不会直接联系专家，而是让秘书一对一去对接。
二、传输方式只有两种：stdio 和 Streamable HTTP
MCP 的消息格式用的是 JSON-RPC （一种结构化的"信件格式"），但"信怎么送"由传输层决定。2026 年的主线只有两种标准传输方式：stdio 和 Streamable HTTP。
传输方式只决定"消息怎么搬"，不改变工具本身的含义。同一个工具，不管用哪种传输，参数和结果都是一样的。
三、stdio：面对面说悄悄话
原理 ：Host 直接把 Server 拉起来，作为自己电脑上的一个子进程。双方通过标准输入（stdin）和标准输出（stdout）传话，一行一条 JSON-RPC 消息。
什么时候用 ：Server 装在你本机上，比如读本地文件、操作本机 Git、连本地数据库。Host 启动子进程，生命周期归 Host 管，用完就回收。
优点 ：不走网络，延迟最低，部署最简单，数据不出本机。缺点：只能本地用，单连接，别人连不进来。
四、Streamable HTTP：打长途电话，但不用一直占线
原理 ：Server 是一个独立进程 ，可以部署在远程，同时服务多个 Client。Client 每发一条消息，就是一次普通的 HTTP POST 请求，打到同一个 MCP 端点上。
关键点在于"响应形态" ：Server 收到请求后，可以返回一个普通的 JSON 对象 （一问一答，立刻结束），也可以把这次响应临时升级成 SSE 流（Server 慢慢往外吐数据，直到说完）。
选了 HTTP，并不是一定建立长连接一直连着。
- 平时：查个天气、读个配置，就是一次短连接，发完请求、收到 JSON、连接关闭，非常省资源。
- 需要时 ：生成长文、处理大文件、实时推送进度，才在这一个请求内部临时开启 SSE 流，说完就断。
SSE 本身没有消失，它从"整个会话强制长连接"降级成了"按请求可选的流式通道"。
五、旧版 HTTP+SSE 为什么被淘汰
旧方案是两个端点 + 强制长连接 ：一个 GET /sse 永远挂着用来收消息，另一个 POST 端点用来发消息。
问题很实在：连接断了没法从断点恢复，只能重来；服务器必须一直维持高可用长连接，并发一高资源就被吃光；而且在安全和基础设施层面也很难处理------长连接一旦建立，中间件往往只检查一次身份，之后门就一直开着。所以它被 Streamable HTTP 取代了。
六、企业内部怎么选：看"服务对象是一个人，还是一个组织"
个人桌面工具 → stdio。员工本机用的效率工具，优先 stdio。零网络暴露，权限就是当前系统用户，客户端退出子进程就回收。企业要做的是在 stdio 外面加沙箱和权限管控，而不是换传输方式。
团队共享服务 → Streamable HTTP。一旦工具连的是公司共享资源（内部代码仓库、工单系统、共享数据库），或者需要集中升级和审计，就必须让 Server 作为独立服务跑起来，用 Streamable HTTP 对内暴露。
企业场景下有几个硬要求：必须上 HTTPS ，内网也不例外；认证不能省 ，MCP 的授权模型以 OAuth 2.1 为基础；通常会引入 MCP 网关做统一收口------工具的注册发现、权限过滤、调用审计、敏感动作管控都在网关层完成。