AI摘要
近日,MCP 于 2025-06-18 发布了重要版本更新。本次协议升级,推动MCP成为更安全、更智能的协作协议。
本文从协议内容规范、功能增强、安全升级三方面介绍本次协议更新的内容。
吴恩达将 MCP 协议定位为“早期但极具潜力”的技术标准。由此可见,MCP 协议目前处于持续迭代演进阶段。
本文为 MCP 系列的第十篇文章,欢迎关注我,后续介绍更多关于 MCP 的内容。
MCP协议内容规范与简化
移除 JSON-RPC 批处理支持
移除对 JSON-RPC 批处理支持,简化协议复杂度,提升单请求可靠性。
原批处理机制:旧版MCP支持JSON-RPC 2.0批处理(Batching),允许客户端通过单次HTTP请求发送多个操作
新规范要求:所有操作必须单独发送,每个请求独立成单个JSON对象
移除 JSON-RPC 批处理支持的好处:
- 降低客户端/服务端开发成本
- 原生适配Streamable HTTP
- 提升可观测性与调试效率
- 依赖HTTP/2多路复用与异步IO,更灵活的并发控制
版本协商机制
强制版本标识与严格校验,为协议持续迭代提供了基础保障。
- 客户端请求必须携带协商版本号(如,MCP-Protocol-Version: 2025-06-18),确保功能与安全策略精准匹配
- 旧版协议的客户端无版本头部,默认按2025-06-18处理。平滑过渡,减少兼容性负担
- 版本号无效/不支持,立即返回400,拒绝处理。防止因版本混淆引发未定义行为
明确生命周期操作要求(从should到must)
明确了 MCP 生命周期各阶段,必须遵循的协议内容:https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle#operation
- 初始化阶段:客户端必须发送 initialize请求,服务器必须响应能力信息
- 操作阶段:服务端与客户端双方必须遵守协商的版本和能力
- 关闭阶段:优雅终止连接。无需定义专门的关闭消息,依赖传输层机制(如 HTTP 断开连接/stdio 关闭流)关闭
MCP功能增强
结构化工具输出
工具输出支持返回复杂数据结构而不仅是文本
工具(Tools)调用经常需要返回结构化数据(如数据库查询结果、API 响应),但早期 MCP 仅支持简单文本输出(content 字段)。这导致:
- 复杂数据需序列化为文本,丢失结构信息
- LLM 难以可靠解析嵌套数据
- 客户端需二次解析,增加开发负担
因此,工具输出需要支持复杂数据结构,定义结构化结果的类型和结构,用于验证和数据说明
输出模式
- 字段 structuredContent:工具结果中返回结构化数据的字段,值为JSON对象。
- 向后兼容要求:工具返回结构化内容时,应同时提供功能等价的非结构化内容(在content 字段返回序列化的JSON字符串)
- 服务端:若工具声明了outputSchema,则服务端必须返回符合该模式的结构化结果
- 客户端:客户端应验证结构化结果是否符合输出模式
工具定义示例(含输入/输出模式)
{
"name": "get_weather_data",
"title": "Weather Data Retriever",
"description": "Get current weather data for a location",
"inputSchema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City name or zip code"
}
},
"required": ["location"]
},
"outputSchema": {
"type": "object",
"properties": {
"temperature": {
"type": "number",
"description": "Temperature in celsius"
},
"conditions": {
"type": "string",
"description": "Weather conditions description"
},
"humidity": {
"type": "number",
"description": "Humidity percentage"
}
},
"required": ["temperature", "conditions", "humidity"]
}
}
工具输出示例
{
"jsonrpc": "2.0",
"id": 5,
"result": {
"content": [{
"type": "text",
"text": "{\"temperature\": 22.5, \"conditions\": \"Partly cloudy\", \"humidity\": 65}"
}],
"structuredContent": {
"temperature": 22.5,
"conditions": "Partly cloudy",
"humidity": 65
}
}
}
结构化工具输出的好处
✅ 支持对响应进行严格的模式校验
💡 提供类型信息以更好地与编程语言集成
🧭 引导客户端和LLM正确解析并利用返回的数据
📚 支持更好的文档和开发者体验
征询机制(Elicitation)
新增对信息征询机制(Elicitation)的支持,允许服务器在交互过程中动态向用户请求额外信息,解决参数缺失或需动态配置的场景(如身份验证补充、参数澄清)
具体流程:
Elicitation 是 MCP 实现 Human-in-the-loop(人在回路) 的关键机制,使服务器能打破被动响应模式,主动介入交互流程。
资源链接支持
工具调用结果可包含资源 uri 引用,以提供额外的上下文或数据(工具将返回一个可供客户端订阅或获取的 uri)
含资源 uri 的响应示例:
{
"type": "resource_link",
"uri": "file:///project/src/main.rs",
"name": "main.rs",
"description": "Primary application entry point",
"mimeType": "text/x-rust"
}
MCP安全升级
- OAuth 资源服务器
明确MCP服务作为OAuth资源服务器的角色,增加授权服务器元数据
授权服务器位置声明机制
MCP服务器必须实现OAuth 2.0受保护资源元数据规范(RFC9728),以声明其关联的授权服务器位置。MCP服务器返回的元数据文档必须包含authorization_servers字段,且该字段需至少列出一个授权服务器地址。
- 关键要求:当返回HTTP 401 Unauthorized响应时,MCP服务器必须在WWW-Authenticate头部中声明资源服务器元数据URL
- 客户端责任:MCP客户端必须能解析WWW-Authenticate头部,并正确处理来自MCP服务器的401响应
服务器元数据发现机制
MCP客户端必须遵循OAuth 2.0授权服务器元数据规范(RFC8414),获取与授权服务器交互所需的端点信息(如令牌颁发、授权端点等)。
- 资源指示器强制要求
要求 MCP 客户端必须实现 RFC 8707 定义的资源指示符(Resource Indicators)机制,以防止恶意服务器获取不当的访问令牌,从而避免越权访问。
问题背景
客户端获取的访问令牌(Access Token)可能被恶意服务器诱导使用。例如,一个钓鱼 MCP 服务器可诱骗客户端发送本应提供给其他服务的令牌,从而越权访问用户数据。
解决方案
通过 RFC 8707 资源指示符(Resource Indicators),强制客户端在申请令牌时声明其目标资源(如 https://api.valid-mcp.com),使令牌仅对该资源有效。恶意服务器无法利用此令牌访问其他系统。
安全价值
- 最小权限原则:将令牌权限收缩至单一资源,避免“一牌多用”风险。
- 协议兼容性:基于 OAuth 2.1 标准扩展
安全规范与最佳实践
安全规范
- 通过 PKCE、HTTPS、RFC 8707 资源绑定、令牌校验等机制,阻断令牌劫持与越权
- 最小权限:短期令牌 + 资源绑定,将攻击影响限制在单一服务内
- 协议演进:OAuth 2.1 与 RFC 8707 的强制整合,标志 MCP 从“功能优先”转向“安全优先”
安全最佳实践
https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices
- 授权链可信:通过动态客户端的用户双重确认,阻断混淆代理攻击;
- 令牌边界隔离:严禁令牌透传,强制受众验证,实现资源级零信任访问;
- 会话可溯源:会话ID与用户身份强绑定,消除劫持与注入风险。
MCP其他变更
- 元数据扩展:新增_meta字段:支持接口类型扩展元数据。
- 上下文传递优化:CompletionRequest增加context字段:允许携带已解析变量。
- 命名规范升级:新增title字段,name作为程序标识符,title提供人性化显示名称。
以上是本次 MCP 协议的更新内容介绍,欢迎关注我,后续介绍更多关于 MCP 的内容。
文章来源公众号:数智脉动
文章来源地址:https://mp.weixin.qq.com/s/axSiA6jSzQIOczfS2wgaAw