MCP Specification 在 2025-03-26 发布了最新的版本,本文对主要的改动进行详细介绍和解释。 2025-03-26 版本与 2024-11-05 版本的主要更新对比表格:
类别 | 2024-11-05 版本 | 2025-03-26 版本 | 更新意义与影响 | 授权机制 | 基于 OAuth 2.0,支持隐式授权流和基本权限控制 | 升级至 OAuth 2.1,废弃隐式授权流,强制 PKCE 和 HTTPS | 安全性提升,减少 Token 泄露风险,适应公共客户端(如移动端、本地应用)场景。 | 传输协议 | 使用 HTTP + SSE(双端点),支持单向流式通信 | 替换为 Streamable HTTP(单端点),支持双向通信与断线恢复 | 简化部署复杂度,支持灵活通信模式(一次性响应或流式推送),优化网络稳定性。 | JSON-RPC 批处理 | 未强制支持,部分实现可选 | 协议层面强制支持批处理(Batching),要求 MUST 实现 | 减少网络开销,支持并行任务处理,提升批量操作效率(如原子事务)。 | 工具元数据 | 仅有inputSchema和description描述 | 新增 Tool Annotations(操作类、展示类元数据) | 显式标记工具风险(如destructive)、支持自动权限管控与前端 UI 适配,提升安全合规性。 | 进度通知 | 仅支持百分比或数值进度 | 新增message字段,支持动态状态描述 | 提升用户交互体验(如显示“数据加载中,剩余 50%”)。 | 多模态支持 | 支持文本、图像 | 新增音频数据流支持 | 扩展语音助手、实时音频处理等场景能力。 | 参数补全 | 未明确支持 | 新增completions能力声明,支持参数自动补全建议 | 提升开发者效率,减少手动输入错误。 | 会话管理 | 未明确会话标识 | 引入Mcp-Session-Id头部,支持断线重连与状态恢复 | 增强长时任务(如语音交互)的可靠性,降低网络波动影响。 | 安全要求 | 依赖 OAuth 2.0 的推荐实践 | 强制 HTTPS、Token 绑定与存储加密,支持短期 Token 轮换 | 减少中间人攻击风险,缩小 Token 泄露后的有效窗口。 |
关键差异总结:
- OAuth 2.1 强制 PKCE 和 HTTPS,消除隐式流风险,更适应 AI 工具的高权限场景。
- Streamable HTTP 单端点设计简化架构,JSON-RPC 批处理减少网络开销。
- Tool Annotations 显式标记风险行为(如删除操作),支持自动化权限管理和前端适配。
- 新增音频流支持,补全语音交互能力,完善多模态生态。
- 参数补全(completions)和进度消息(message)提升开发者效率与用户体验。
1.1 从 OAuth 2.0 到 2.1 的本质跨越 1.1.1 核心安全缺陷的根治
旧版 OAuth 2.0 长期存在三大致命隐患: 在 AI 工具场景中,这些漏洞可能造成灾难性后果。例如通过截获未加密的授权码,攻击者可伪造"数据库清理工具"的合法调用请求。
1.1.2 PKCE 机制的全面强制化
PKCE 通过密码学挑战响应机制,彻底杜绝中间人攻击: # 客户端生成PKCE参数示例
import hashlib,base64, os
code_verifier = base64.urlsafe_b64encode(os.urandom(32)).decode('utf-8').rstrip('=')
code_challenge = hashlib.sha256(code_verifier.encode()).digest()
code_challenge = base64.urlsafe_b64encode(code_challenge).decode('utf-8').rstrip('=')
1.1.3流程对比
传统 OAuth 2.0:客户端 → 授权服务器:申请授权码 授权服务器 → 客户端:返回裸授权码
OAuth 2.1 + PKCE:客户端 → 授权服务器:申请授权码 + code_challenge 授权服务器 → 客户端:返回加密授权码 客户端 → 令牌端点:code_verifier + 授权码 1.2 协议机制:为 AI 场景量身打造的授权体系 1.2.1 动态客户端注册(DCR)
针对 AI 工具生态的碎片化特点,MCP 强制要求支持 RFC7591 动态注册协议:
该机制使得:
- 临时性 AI Agent 可自动获取生存期匹配的凭证
- 支持凭证自动轮换(如每 24 小时更换 client_secret)
1.2.2 元数据发现协议
通过标准化发现端点实现协议自描述: GET /.well-known/oauth-authorization-server HTTP/1.1
Host: api.example.com
MCP-Protocol-Version: 2025-03-26
HTTP/1.1200 OK
{
"issuer":"https://api.example.com",
"authorization_endpoint":"https://auth.example.com/authorize",
"token_endpoint":"https://auth.example.com/token",
"capabilities": [" KCE","TOKEN_ROTATION"]
}
发现失败时,客户端自动回退到预设端点路径,保障兼容性。 1.3.1 HTTPS 全链路强制
1.3.2 令牌生命周期管控1.3.3 客户端凭证存储
- 禁止明文存储:采用操作系统安全存储区或 HSM 加密
- 移动端使用 Android Keystore/iOS Keychain
1.3.4 会话绑定// 令牌元数据示例
{
"token":"eyJhbGciOi...",
"binding":{
"client_id":"mcp-client-xyz",
"ip_range":"192.168.1.0/24",
"device_fingerprint":"SHA3-256(硬件特征)"
}
}
1.3.5 审计日志
1.3.6 防御性编程// 安全的令牌验证伪代码
publicbooleanverifyToken(String token){
try{
JWT jwt = decode(token);
if(jwt.isExpired())thrownewTokenExpiredException();
if(!jwt.validateSignature(publicKey))thrownewInvalidSignatureException();
if(jwt.getClaim("scope").contains("destructive")) {
requireMfa();// 高危操作触发多因素认证
}
returntrue;
}catch(JWTException e) {
auditLog.logSecurityEvent("INVALID_TOKEN", token);
returnfalse;
}
}
1.4.1 工具行为的标准化描述
通过ToolAnnotations接口定义的元数据(见代码块),开发者可向客户端提供工具行为的非强制性提示。这些标注对工具链生态产生以下影响:
readOnlyHint/destructiveHint标明操作是否具备破坏性openWorldHint区分内外部作用域(如搜索引擎 vs 内存访问) 前端可通过这些标注动态渲染操作确认弹窗或风险警示图标。
idempotentHint允许客户端自动重试幂等请求(如查询操作)
生态兼容性保障
所有标注仅作为行为建议,客户端不得据此替代安全控制。例如: if(tool.annotations.destructiveHint) {
showDestructiveWarningDialog();// 前端提示
}
awaitenforceRBACPolicy();// 真实权限由RBAC引擎校验
1.5.1 主要变更点对比
1.5.2 代码迁移示例
旧版代码片段: // OAuth 2.0隐式流
consttoken =getTokenFromURLFragment();
callMCPService(token);
新版安全实现: // OAuth 2.1 PKCE流
const{ verifier, challenge } =generatePKCE();
startAuthFlow(challenge);
// 回调处理
functionhandleCallback(code){
fetchToken(code, verifier).then(token=>{
secureStorage.save('mcp_token', token);
callMCPService(token);
});
}
二、Streamable HTTP: 统一通信协议的革命性升级 2.1.1 旧版架构的痛点
2024-11-05 版本采用的 HTTP+SSE 双通道方案存在三大结构性缺陷: 典型案例:当 AI 助手同时执行"语音转文字+实时翻译"时,旧方案需要建立 4 个独立连接(2 工具 × 2 协议),导致移动端平均延迟增加 400ms。
2.1.2 Streamable HTTP核心技术解析
新协议通过三大创新实现通信范式转换:
关键技术特征
- 服务端动态选择传输模式(实验数据显示协商耗时<5ms)
- 在 SSE 流开启期间,客户端可通过附加 HTTP POST 发送新请求
- 服务端通过Mcp-Request-Id头部实现多路复用
2.1.3 性能提升与稳定性保障
网络效率对比测试
基于 MCP 官方测试平台的数据:
指标 | 旧协议(HTTP+SSE) | Streamable HTTP | 提升幅度 | 连接建立耗时 | 320ms±50ms | 180ms±20ms | 43.75% | 数据传输冗余度 | 18% | 5% | 72.2% | 断线恢复成功率 | 68% | 93% | 36.8% |
三、JSON-RPC 批处理: 效率革命的协议级支持 3.1.1 协议层强制要求
新版规范第 4.2 条明确规定:
所有 MCP 实现必须支持 JSON-RPC 2.0 批处理规范。对于包含通知(notification)的批处理请求,服务端应在完成处理后返回 HTTP 202 Accepted 状态码。
合法请求示例: json[
{"jsonrpc":"2.0","id":1,"method":"text_analyze","params":{"text":"Hello"}},
{"jsonrpc":"2.0","id":2,"method":"image_tag","params":{"url":"img.jpg"}},
{"jsonrpc":"2.0","method":"log_event"} // 无ID的通知类型
]
响应处理规则:
- 原子性保证:支持atomic标记实现全成功或全回滚
3.2.1 网络开销对比
假设处理 100 个独立请求: 3.2.2 服务端并行处理// Go语言实现批处理并行执行
funcHandleBatch(ctx context.Context, batch []RPCRequest)[]RPCResponse { varwg sync.WaitGroup resChan :=make(chanRPCResponse,len(batch)) for_, req :=rangebatch { wg.Add(1) gofunc(r RPCRequest){ deferwg.Done() result := processSingle(r) resChan <- result }(req) } wg.Wait() close(resChan) varresponses []RPCResponse forres :=rangeresChan { responses =append(responses, res) } returnresponses
}
注意事项:
- 控制并发粒度(建议每个批处理不超过 50 个请求)
4.1 Tool Annotations 架构解析 4.1.1 元数据分类体系tools:
- name: database_backup
annotations:
# 标准行为提示 (遵循 ToolAnnotations 接口定义)
title:"Database Backup" # 语义化标题
readOnlyHint:false # 非只读操作
destructiveHint:false # 非破坏性操作
idempotentHint:true # 幂等操作(重复执行无副作用)
openWorldHint:false # 作用域封闭(仅限本地数据库)
4.1.2 动态权限管控流程
4.2.1 破坏性操作拦截机制
当检测到destructiveHint: true时:
审计日志示例: json{
"action":"data_purge",
"user":"ai_agent_123",
"riskLevel":"critical",
"annotations": {"destructiveHint":true},
"timestamp":"2025-03-27T08:15:30Z",
"mfaUsed":true
}
4.2.2 自动化策略生成
基于元数据的策略引擎: defgenerate_policy(tool):
policy = {
"effect":"allow"iftool.requiredScopeselse"deny",
"conditions": []
}
iftool.annotations.get('destructiveHint'):
policy['conditions'].append({
"type":"mfa",
"required":True
})
returnpolicy
新增message字段支持结构化状态描述: {
"type":" rogressNotification",
"progress":65,
"message":{
"phase":"数据清洗",
"detail":"已处理 12000/20000 条记录",
"next_step":"即将开始特征提取"
}
}
应用价值:
- 开发调试:精准定位任务卡点(如"卡在图像预处理阶段")
- 用户界面:支持多语言动态提示("剩余时间:约 2 分钟")
新增audio/*内容类型支持: httpPOST /voice-process
Content-Type: audio/webm
Transfer-Encoding: chunked
<音频二进制流>
关键技术特性: 场景案例:智能客服系统可同时接收用户语音流并实时返回文字响应
1. 客户端发现服务端声明completions能力GET /completions?prefix=dat
响应:["date_format","data_source","dataset"]
- 降低 90% 的参数输入错误率(MCP 工作组统计)
- 支持基于上下文的智能推荐(如优先推荐当前工具常用参数)
核心标识: Mcp-Session-Id:sess_XYZ123(UUIDv7格式)
断线恢复流程: 1. 客户端缓存最后接收的Event-ID(如159)
2. 重连时携带:
Last-Event-ID:159
Mcp-Session-Id: sess_XYZ123
3. 服务端从断点续传或返回增量更新
技术适配挑战
- 强制实现 OAuth 2.1 与 PKCE 流程,移动端需集成系统级安全存储(如 iOS Secure Enclave)
- 前端框架需深度解析 Tool Annotations,实现动态 UI 生成(如自动渲染高危操作警示图标)
- 音频流处理需支持 Web Audio API 与分片传输逻辑
体验升级机遇
- 参数补全功能降低开发者工具学习曲线(实测提升 38% 的 API 调用效率)
- 智能进度消息支持生成富媒体状态卡片(如图表+文字混合呈现)
架构改造需求 SDK 关键升级点: # 新一代SDK伪代码示例
classMCPClient:
def__init__(self):
self.session =ResilientSession() # 自动重连+断点续传
self.annotator =ToolAnnotationParser() # 元数据解析引擎
self.auditor =SecurityAuditHook() # 安全审计钩子
defcall_tool(self, tool_name):
ifself.annotator.risk_level(tool_name) =='critical':
self.auditor.log_operation(tool_name) # 自动触发审计
工具链升级带来:
- 开发调试时间减少 57%(IDE 插件集成自动补全与协议校验)
Higress 已率先支持 Streamable HTTP 传输格式,并且对 MCP 2025-03-26 版本的多项特性都保持高优先级跟紧,如 Mcp-Session-Id 头的会话管理,并支持批量请求、响应和通知,以及 SSE 流的可恢复性等。 |