AI摘要

MCP协议在2025年6月18日发布了重大更新,包括内容规范简化、功能增强和安全升级。更新内容包括移除JSON-RPC批处理支持、版本协商机制、明确生命周期操作要求、结构化工具输出、征询机制和资源链接支持。安全升级方面,MCP服务作为OAuth资源服务器,增加了授权服务器元数据和资源指示器强制要求。此外,还有安全规范与最佳实践、元数据扩展、上下文传递优化和命名规范升级等其他变更。

近日,MCP 于 2025-06-18 发布了重要版本更新。本次协议升级,推动MCP成为更安全、更智能的协作协议。

本文从协议内容规范、功能增强、安全升级三方面介绍本次协议更新的内容。

吴恩达将 MCP 协议定位为“早期但极具潜力”的技术标准。由此可见,MCP 协议目前处于持续迭代演进阶段。

本文为 MCP 系列的第十篇文章,欢迎关注我,后续介绍更多关于 MCP 的内容。

MCP协议内容规范与简化

移除 JSON-RPC 批处理支持
移除对 JSON-RPC 批处理支持,简化协议复杂度,提升单请求可靠性。

原批处理机制:旧版MCP支持JSON-RPC 2.0批处理(Batching),允许客户端通过单次HTTP请求发送多个操作
新规范要求:所有操作必须单独发送,每个请求独立成单个JSON对象

移除 JSON-RPC 批处理支持的好处:

  1. 降低客户端/服务端开发成本
  2. 原生适配Streamable HTTP
  3. 提升可观测性与调试效率
  4. 依赖HTTP/2多路复用与异步IO,更灵活的并发控制

版本协商机制
强制版本标识与严格校验,为协议持续迭代提供了基础保障。

  1. 客户端请求必须携带协商版本号(如,MCP-Protocol-Version: 2025-06-18),确保功能与安全策略精准匹配
  2. 旧版协议的客户端无版本头部,默认按2025-06-18处理。平滑过渡,减少兼容性负担
  3. 版本号无效/不支持,立即返回400,拒绝处理。防止因版本混淆引发未定义行为

明确生命周期操作要求(从should到must)
明确了 MCP 生命周期各阶段,必须遵循的协议内容:https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle#operation

  1. 初始化阶段:客户端必须发送 initialize请求,服务器必须响应能力信息
  2. 操作阶段:服务端与客户端双方必须遵守协商的版本和能力
  3. 关闭阶段:优雅终止连接。无需定义专门的关闭消息,依赖传输层机制(如 HTTP 断开连接/stdio 关闭流)关闭

MCP功能增强

结构化工具输出
工具输出支持返回复杂数据结构而不仅是文本

工具(Tools)调用经常需要返回结构化数据(如数据库查询结果、API 响应),但早期 MCP 仅支持简单文本输出(content 字段)。这导致:

  1. 复杂数据需序列化为文本,丢失结构信息
  2. LLM 难以可靠解析嵌套数据
  3. 客户端需二次解析,增加开发负担

因此,工具输出需要支持复杂数据结构,定义结构化结果的类型和结构,用于验证和数据说明

输出模式

  • 字段 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)的支持,允许服务器在交互过程中动态向用户请求额外信息,解决参数缺失或需动态配置的场景(如身份验证补充、参数澄清)

具体流程:
image.png
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安全升级

  1. 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),获取与授权服务器交互所需的端点信息(如令牌颁发、授权端点等)。

  1. 资源指示器强制要求

要求 MCP 客户端必须实现 RFC 8707 定义的资源指示符(Resource Indicators)机制,以防止恶意服务器获取不当的访问令牌,从而避免越权访问。

问题背景

客户端获取的访问令牌(Access Token)可能被恶意服务器诱导使用。例如,一个钓鱼 MCP 服务器可诱骗客户端发送本应提供给其他服务的令牌,从而越权访问用户数据。

解决方案

通过 RFC 8707 资源指示符(Resource Indicators),强制客户端在申请令牌时声明其目标资源(如 https://api.valid-mcp.com),使令牌仅对该资源有效。恶意服务器无法利用此令牌访问其他系统。

安全价值

  • 最小权限原则:将令牌权限收缩至单一资源,避免“一牌多用”风险。
  • 协议兼容性:基于 OAuth 2.1 标准扩展

安全规范与最佳实践

安全规范

  1. 通过 PKCE、HTTPS、RFC 8707 资源绑定、令牌校验等机制,阻断令牌劫持与越权
  2. 最小权限:短期令牌 + 资源绑定,将攻击影响限制在单一服务内
  3. 协议演进:OAuth 2.1 与 RFC 8707 的强制整合,标志 MCP 从“功能优先”转向“安全优先”

安全最佳实践
https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices

  1. 授权链可信:通过动态客户端的用户双重确认,阻断混淆代理攻击;
  2. 令牌边界隔离:严禁令牌透传,强制受众验证,实现资源级零信任访问;
  3. 会话可溯源:会话ID与用户身份强绑定,消除劫持与注入风险。

MCP其他变更

  1. 元数据扩展:新增_meta字段:支持接口类型扩展元数据。
  2. 上下文传递优化:CompletionRequest增加context字段:允许携带已解析变量。
  3. 命名规范升级:新增title字段,name作为程序标识符,title提供人性化显示名称。

以上是本次 MCP 协议的更新内容介绍,欢迎关注我,后续介绍更多关于 MCP 的内容。

文章来源公众号:数智脉动
文章来源地址:https://mp.weixin.qq.com/s/axSiA6jSzQIOczfS2wgaAw

最后修改:2025 年 06 月 25 日
点赞的人是最酷的