为什么要盯住一份协议的路线图
MCP 的价值不在"能调工具"，而在"一次编写、到处可用"。一旦某个客户端只支持旧版传输层、或者鉴权方式各家自行其是，这种可移植性就会迅速瓦解。对做技术选型的团队来说，判断一个协议是否值得押注，看的不是它现在能做什么，而是它的演进节奏和破坏性变更频率——这恰恰是路线图与 RFC 讨论区能告诉你的信息。
一个年轻而充满生命力的新标准
MCP 从开源到现在仅过去几个月时间，但已被全球数以万计的开发者和几乎所有主流 AI 编辑器迅速采纳。
采纳速度快带来的副作用同样明显：客户端与服务端的版本组合呈笛卡尔积式膨胀，同一份 Server 代码在不同宿主里的行为差异开始显现。规范因此被迫进入了"高频小步修订"的状态，而这正是理解后续所有议题的前提。
已经落地的两次关键修订
在讨论"未来"之前，先确认"现在"。截至目前的公开规范，两次修订直接决定了你今天的架构选择：
2025-03-26
- 引入 Streamable HTTP 传输层，取代此前的 HTTP+SSE 方案。它允许服务端在单个 HTTP 端点上按需选择"普通响应"或"升级为 SSE 流"，从而可以跑在普通的负载均衡与无服务器函数上，而不必为长连接单独准备会话粘滞。
- 增加 OAuth 2.1 授权支持与授权服务器元数据发现。
- 引入 Tool Annotations，让服务端可以声明工具的读写、破坏性等语义特征。
2025-06-18
- 要求通过
MCP-Protocol-Version请求头显式携带协商后的协议版本。 - 将 MCP Server 明确定位为 OAuth 资源服务器（Resource Server），并引入受保护资源元数据。
- 新增 Elicitation（服务端向用户追问） 与 结构化工具输出（Structured Tool Output）。
- 移除了 JSON-RPC 批量请求（batching）。
对使用者的直接含义是：如果你的 Server 还需要远程部署，Streamable HTTP 已经是默认答案；而"把 Token 塞进环境变量"这种做法，在规范层面已经被正式的授权模型替代了。
正在激烈讨论与推进的未来特性（Community RFCs）
-
统一标准的 OAuth 2.0 / JWT 鉴权协议栈：使得云端远程 MCP Server 可以标准地进行多租户身份识别，摆脱目前纯靠环境变量传 Token 的原始方式；
讨论的焦点已经不是"要不要做"，而是授权粒度。当前实践中一个 MCP Server 往往聚合了几十个工具，而它们在权限上完全不同——读文件与删文件、查询与下单。社区在推进的方向是把授权范围（scope）下沉到工具级别，并让客户端在遇到 401 时能够自动触发一次增量授权，而不是要求用户回到配置界面手工补 Token。选型时要注意：不同宿主对增量授权的支持进度差异很大，这决定了你的多租户方案能不能真正落地。
-
多模态与二进制流式传输深度优化：支持大体积视频切片与音频流的低开销直连传输；
现状是二进制内容普遍以 Base64 编码内嵌在 JSON 消息里，体积膨胀约三分之一，且必须完整到达才能解码，长音频场景下首字延迟很难接受。RFC 方向是允许分块与引用式传输——工具返回一个可寻址的内容句柄，由客户端按需拉取分片。对做语音、视觉 Agent 的团队，这意味着现在就不该把大文件写进工具返回值，而应该返回一个本地或对象存储的 URI，为将来的切换留出余地。
-
更完备的多语言第一方 SDK：Go、Rust、Java、C# 第一方 SDK 的相继完善，将彻底打通传统企业资产接入智能体生态的"最后一公里"；
企业存量的服务网关、ERP、数据中台大多不是 TypeScript/Python 生态。SDK 覆盖度的意义在于：协议细节由官方实现兜底，业务方只需要暴露工具。选型上有一个务实的判断标准——优先选择有第一方 SDK 的语言栈编写 Server，因为协议版本协商、取消传播、重试语义这些容易写错的部分已经被验证过；自研客户端则要重点核对版本头与生命周期方法的实现完整性。
现在做选型，应该检查哪几件事
- 版本协商：客户端与服务端是否显式交换协议版本，而不是"碰巧能用"。
- 传输层：本地进程用 stdio，远程一律优先 Streamable HTTP，并确认它能在你的网关与超时配置下存活。
- 鉴权：是否已经走到 OAuth 资源服务器模型；仍在用环境变量传长期 Token 的方案，需要明确改造窗口。
- 工具契约：返回值是否结构化。把业务字段塞进自由文本的
content里，等于把解析成本转嫁给每一个下游客户端。 - 失败语义：工具执行失败时返回的是协议层错误还是业务层错误，取消请求能否真正中断后端任务。
小结
MCP 的路线图目前呈现出一个健康信号：破坏性变更集中在传输与授权这两个"必须早定"的层面，而能力扩展（追问、结构化输出）都走增量。对使用者来说，现在押注的风险主要不在协议会翻烧饼，而在各宿主的实现进度不齐——选型时把"支持到哪一版规范"当成和"性能"同级的硬指标，比事后补兼容要便宜得多。