一直没来得及写这一篇，今天终于补上。其实这次更新的内容不算多，在我看来，真正称得上实质功能的可能只有 elicitation 这一项。不过这个词要怎么翻译，真的是见仁见智——是叫“问询”、“引导”，还是别的什么？我个人觉得，“需求获取”可能更贴切一些，但是由于又提供了拒绝选项，所以我接下来会用“征询”来翻译这个词。

https://modelcontextprotocol.io/specification/2025-06-18/changeloghttps://modelcontextprotocol.io/specification/2025-06-18/changelog

主要变更

1. 移除对JSON-RPC批处理的支持（PR #416）
2. 新增结构化工具输出支持（PR #371）
3. 将MCP服务器归类为OAuth资源服务器，并添加受保护资源元数据以关联授权服务器（PR #338）
4. 要求MCP客户端实现RFC 8707资源指示器，防止恶意服务器获取访问令牌（PR #734）
5. 明确授权规范中的安全考虑与最佳实践，新增安全实践指南
6. 新增客户端 征询（elicitation）支持：允许服务器在交互中向用户请求更多信息（PR #382）✅ 显著功能更新
7. 支持工具调用结果中的资源链接（PR #603）
8. 要求在使用HTTP时通过MCP-Protocol-Version头指定协商的协议版本（PR #548）
9. 将生命周期操作中的“SHOULD”改为“MUST”，强化规范要求

其他架构变更：

• 在更多接口类型中增加 _meta 字段（PR #710），并明确其用法
• 在CompletionRequest中新增 context 字段，支持包含已解析变量（PR #598）
• 新增 title 字段，便于显示友好名称，同时保留 name 作为程序标识符（PR #663）

征询功能

模型上下文协议（Model Context Protocol，MCP）在2025-06-18版本中引入了一项创新功能——信息征询（Elicitation）。这项功能为服务器提供了一种标准化的方式，在交互过程中通过客户端向用户请求额外信息。MCP通过这一机制实现了动态信息收集，同时确保客户端保持对用户交互和数据共享的完全控制。

核心设计理念

信息征询功能允许服务器在MCP服务器特性中嵌套实现交互式工作流，通过JSON模式验证响应，确保数据结构的完整性。协议设计充分考虑了灵活性和可扩展性，实施者可以根据自身需求自由选择界面模式，协议本身不强制规定任何特定的用户交互模型。

信任与安全框架

出于信任与安全考虑，MCP对信息征询功能实施了严格限制：

• 服务器严禁使用此功能请求敏感信息
• 应用程序应当提供清晰标识服务器身份的用户界面
• 用户必须在发送前有机会审核和修改响应内容
• 必须充分尊重用户隐私，提供明确的拒绝和取消选项

能力声明机制

支持信息征询功能的客户端必须在初始化过程中明确声明此能力：

{
  "capabilities": {
    "elicitation": {}
  }
}

协议消息规范

创建信息征询请求

服务器通过发送elicitation/create请求向用户征询信息。请求支持两种模式：

简单文本请求示例

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "elicitation/create",
  "params": {
    "message": "请提供您的GitHub用户名",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {"type": "string"}
      },
      "required": ["name"]
    }
  }
}

结构化数据请求示例

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "elicitation/create",
  "params": {
    "message": "请提供您的联系信息",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {"type": "string", "description": "您的全名"},
        "email": {"type": "string", "format": "email", "description": "您的邮箱地址"},
        "age": {"type": "number", "minimum": 18, "description": "您的年龄"}
      },
      "required": ["name", "email"]
    }
  }
}

响应处理机制

信息征询采用三动作响应模型，清晰区分不同用户操作：

接受响应

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "accept",
    "content": {"name": "octocat"}
  }
}

拒绝响应

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {"action": "decline"}
}

取消响应

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {"action": "cancel"}
}

模式限制与支持

信息征询功能使用受限的JSON模式子集，简化客户端实现：

支持的模式类型包括：

• 字符串模式：支持email、uri、date、date-time格式验证
• 数字模式：支持最小值和最大值限制
• 布尔模式：支持默认值设置
• 枚举模式：支持选项值和显示名称分离

不支持的类型：

• 复杂的嵌套结构
• 对象数组
• 其他高级JSON模式功能

安全考量与实践建议

1. 服务器责任：严禁请求敏感信息，必须正确处理各种响应状态
2. 客户端责任：应当实现用户批准控制，提供清晰的服务器标识
3. 双方协作：应当根据提供的模式验证信息征询内容
4. 用户体验：应当允许用户随时拒绝请求，并实施速率限制
5. 透明度：应当清晰展示请求的信息内容和目的

总结

MCP的信息征询功能代表了一种平衡服务器需求与用户控制的创新方法。通过标准化的协议设计和严格的安全限制，它既满足了服务器动态获取信息的需求，又确保了用户隐私和数据安全的保护。这一功能的引入为构建更加交互式和智能化的应用提供了坚实基础，同时维护了用户信任这一核心价值。随着协议的演进，信息征询功能有望在保持安全性的基础上进一步扩展其能力和应用场景。

最后附上原文链接：

https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation

个人评价

MCP 协议的征询功能在整体设计理念上相当出色，但在具体实现细节上还存在一些值得商榷的地方。

类型定义过于 TypeScript 化可能是其中一个较为明显的问题。当前的定义方式对其他编程语言和 UI 框架的实现者不够友好，可能会在跨平台适配过程中造成一定的理解成本和实现难度。类似的倾向在 DXT（MCP Bundles）项目中也有所体现。

格式规范缺乏明确定义是另一个潜在痛点。虽然协议提供了诸如 "email"、"uri"、"date"、"date-time" 等格式选项，但并未明确规定具体的标准格式。以 "date-time" 为例，各种实现可能采用不同的时间格式，这在未来很可能导致正则表达式解析上的不一致和兼容性问题。

实践体验建议：目前 Claude 官方应用尚未支持 elicitation 征询功能，想要尝鲜的开发者可以尝试我个人的 Playground 项目（建议直接下载 ZIP 免安装版本）。

https://www.github.com/AI-QL/tuui

该项目基于 MCP Everything 这一专门的协议测试服务器，能够完整验证包括征询功能在内的各项特性，为开发者提供了一个良好的学习和测试环境。