MCP协议，全称“模型上下文协议（Model Context Protocol）”，自2024年11月发布首个版本以来，虽然问世时间尚短，却已展现出“出道即巅峰”的势头。它试图解决的问题并不复杂，但其核心概念和架构设计却让不少初学者感到陌生。
现在MCP Server提供了三种形态类型，分别是标准输入/输出（Stdio）、服务器发送事件（SSE）、可流式传输的HTTP（StreamableHttp），也正是因为有三种的不同类型，导致其比较难理解的原因。我以比较简洁的方式凸显它们的场景和区别，详细的技术实现网上已经有很多，可以自行查看。
本地运行的标准输入/输出（Stdio）
与Linux的管道技术是一样的，它就是以标准输入和输出，连接客户端和MCP Server，如下图所示：
这种方式的一大特点就是像C/S架构，代码是运行在客户端本地的，比如就是运行在你自己的电脑，会启动相应的进程。
- 开发者。可以使用python、NodeJS等开发运行，按MCP协议的规范开发代码，最后以可执行程序或脚本文件，提供给客户端运行，包括Cline、Cursor、Cherry studio以及自己开发的智能体等。
- 用户。自己的电脑通过客户端代理用户提交的请求（自然语言），把MCP Server提供的工具tools说明（包括参数说明）、提示词（可选），加上用户的请求，一同提供给大模型，由大模型决定是否有合适的工具解决用户的问题，如果有就返回给客户端，由客户端调用具体的工具（数据库、服务接口等等）。
- 外部服务。MCP Server的代码已经包含了如何调用外部服务的功能，以及返回调用结果。所以，这里说的标准输入和输出，指的是 MCP Server 与 客户端之前的数据交换用的是StdIO。
这种方式是当前最成熟的方式，很多开源的MCP Server都是以这种方式提供对接。这种方式与传统的C/S架构的软件一样，更新维护很麻烦。
服务器发送事件（SSE）
这种方式是典型的B/S架构，代码是独立运行在服务端，客户端通过SSE（Server Send Event）协议进行交换数据（最底层还是HTTP，这里只是弱化了），客户端和服务端一直保持长连接（类似汽车的全时四驱）。可以通过下图对比其中的区别：
使用 SSE（Server-Sent Events）作为 MCP（模型上下文协议，Model Context Protocol）底层通信方式时，虽然实现相对简单，但也存在一些明显问题，主要体现在以下几个方面：
1. 单向通信限制。SSE 仅支持服务器向客户端推送数据，客户端无法主动发送事件，限制了交互的灵活性和实时性，尤其在模型和服务之间需要双向交互的场景中显得力不从心。
2. 并发连接数受限。SSE 基于 HTTP 长连接，不支持复用，浏览器通常对同一源的并发连接数量有限（例如 Chrome 默认最多 6 个），在多模型、多请求并发场景下容易达到瓶颈。
3. 不支持二进制数据。SSE 只能传输 UTF-8 编码的文本，无法直接支持二进制数据传输，不适用于图像、音频或其他非结构化数据的上下文场景，限制了协议在多模态智能体中的扩展能力。
4. 重连和断线恢复机制不够健壮。虽然 SSE 提供了简单的自动重连机制（retry），但对连接中断、消息丢失等异常情况的处理能力较弱，无法确保消息的完整性和顺序性。
5. 缺乏扩展性和标准的认证机制。SSE 本身不包含认证机制，通常需要额外实现，如通过 HTTP Header 携带 token，不如 WebSocket 或 gRPC 在安全和扩展控制方面灵活。
因为其存在比较多的问题，所以还没真正落地使用起来，就要被StreamableHttp取代。所以，大家可以不用管这种方式了，只是知道一下就好了。
可流式传输的HTTP（StreamableHttp）
这种方式也是B/S架构，它是SSE方式的升级版，将会取代SSE的方式。它们的区别如下图所示：
其实最大的区别就是它可以只使用普通的HTTP方式进行交互，按需可以使用SSE的方式交互（类似汽车的适时四驱）。采用 Streamable HTTP传输方式相比传统 SSE 有显著优势，主要体现在以下几个核心方面：
1.高可靠性与会话恢复。支持可选 session ID与 Last-Event-ID，可实现断线重连和断点续传，避免了 SSE 重连后上下文丢失的问题 。连接恢复后，服务器可重发客户端可能错过的消息，确保消息完整性。
2.资源利用更高效。无需持续保持长连接，连接仅在需要时建立，降低资源占用 。支持连接池和请求批处理机制，可进一步提高吞吐量与并发性能。
3.基础设施兼容性强。采用标准 HTTP，无需特殊配置 SSE 端点，在主流 CDN、负载均衡器、反向代理等标准架构中可无缝集成 。REST 风格兼容性好，易于与现有微服务、API 网关集成。
4.实现简单、易维护。将客户端请求和服务器响应集中到一个统一的 /message 端点，开发实践更直观 。精简了连接管理逻辑，减少开发和调试复杂度。
5.灵活支持各种部署与扩展。可支持 无状态服务部署，如无需会话保存的场景。同时支持 有状态部署，适用于需要会话持久化、负载均衡的复杂系统 。可按需选用 SSE 流式响应，实现实时进度通知等高级功能。
