MCP 2025-06-18 中的新增功能：人机协同、OAuth、结构化内容和不断发展的 API 范式

最新版本的模型上下文协议（MCP）（日期为 2025 年 6 月 18 日）引入了强大的增强功能，将 MCP 推进为 AI 原生 API 的通用协议。

Model Context Protocol (MCP)

主要亮点包括：

通过 Elicitation 流程提供人机协同
完整的 OAuth 架构定义，适用于用户授权的安全 API
结构化内容和输出架构 — 类型化、经过验证的结果，具有灵活的架构理念和 MIME 类型清晰度

在这篇文章中，我们将探讨这些功能及其重要性，最后观察 MCP 如何反映 AI 优先世界中 API 设计的更广泛转变。

1. 人机协同 — Elicitation Flow

一个主要的新增功能是通过 Elicitation Requests 显式支持多轮次、人机交互。

MCP 现在支持对话序列，而不是单一的一次性呼叫，该工具和客户协作以澄清和收集缺失或模棱两可的信息。

运作方式：

客户端发送工具请求
工具（通过 LLM）返回一个 — 询问缺失或不明确的输入 elicitationRequest
客户端提示用户并收集其他输入
客户端发送包含用户提供信息的请求 continueElicitation
工具继续处理新信息并返回最终结果

此工作流程支持实际应用，例如：

交互式表单填写
阐明用户意图
收集增量数据
确认不明确或部分输入

有关更多详细信息，请参阅 Elicitation 规范。

2. OAuth 架构增强功能

以前，MCP 仅通过简单的标志和最少的元数据来支持 OAuth，将完整的 OAuth 流处理留给客户端实现。

在此版本中，MCP 现在支持完整的 OAuth 2.0 架构定义，允许工具指定：

authorizationUrl
tokenUrl
clientId
Required scopes

此外，工具现在可以将自己显式声明为 OAuth 资源服务器。

为了增强安全性，MCP 客户端现在需要实施 [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707) 中定义的资源指示器。这可以防止恶意服务器滥用用于其他资源的访问令牌。

这些更改支持：

完全集成、安全、用户授权的访问
改进了与企业 OAuth 提供程序的互作性
更好地防止令牌滥用

3. 结构化内容和输出模式

a）输出架构 — 更强大但灵活的合约

工具可以声明 using JSON Schema，从而实现客户端可以可靠地验证和解析的精确类型化输出 outputSchema。

例如，Network Device Status Retriever 工具可以定义以下输出架构：

{
  "type": "object",
  "properties": {
    "deviceId": { "type": "string", "description": "Unique device identifier" },
    "status": { "type": "string", "description": "Device status (e.g., up, down, maintenance)" },
    "uptimeSeconds": { "type": "integer", "description": "Device uptime in seconds" },
    "lastChecked": { "type": "string", "format": "date-time", "description": "Timestamp of last status check" }
  },
  "required": ["deviceId", "status", "uptimeSeconds"]
}

有效的响应可能如下所示：

{
  "structuredContent": {
    "deviceId": "SW-12345",
    "status": "up",
    "uptimeSeconds": 86400,
    "lastChecked": "2025-06-20T14:23:00Z"
  },
  "content": [
    {
      "type": "text",
      "text": "{\"deviceId\": \"SW-12345\", \"status\": \"up\", \"uptimeSeconds\": 86400, \"lastChecked\": \"2025-06-20T14:23:00Z\"}"
    }
  ]
}

此示例自然而然地适用于网络作，展示了 MCP 结构化内容 如何增强 AI 辅助的网络监控和管理。

b） MIME 类型支持

内容块可以使用数据指定 MIME 类型，使客户端能够正确呈现图像、音频、文件等。

例：

{
  "type": "image",
  "data": "base64-encoded-data",
  "mimeType": "image/png"
}

c）软模式契约 — 着眼于未来的实用主义

MCP 采用务实的方法来遵守架构，认识到 AI 生成的输出的概率性质和向后兼容性的需求。

“工具应该提供符合输出架构的结构化结果，客户应该验证它们。
但是，灵活性是关键 — 非结构化回退内容对于优雅地处理变体仍然很重要。"

这种软合同方法意味着：

鼓励工具生成符合 schema 的输出，但并不严格要求每次都这样做。
客户应尽可能验证和解析结构化数据，但也要处理不完美或部分结果。
这种方法可帮助开发人员在当今构建强大的集成，尽管 AI 存在固有的不确定性。

展望未来，随着 AI 模型的改进和标准的成熟，MCP 的架构实施可能会朝着更严格的验证和保证发展，从而更好地支持任务关键型和企业场景。

目前，MCP 在创新和可靠性之间取得平衡 — 在不牺牲灵活性的情况下提供结构。

结论：REST → MCP、SQL → NoSQL — 一个进化的类比？

观察 MCP 的演变让我想起了 API 和数据设计领域的更广泛趋势。

传统的 REST API 强制实施严格的版本控制架构，这与 SQL 数据库需要严格的架构非常相似。

NoSQL 数据库引入了架构灵活性，支持快速迭代和容忍非结构化数据。

同样，MCP 正在朝着以下方向发展：

灵活、不断发展的架构指导，而不是脆弱的合同
结构化和非结构化内容共存
为 AI 的概率性（有时是不完美的输出）设计容差

我并不是说这是一个完美的类比，但它是一个有用的镜头，可以反思 API 在 AI 优先的世界中必须如何发展。

MCP 只是 AI 的 REST 吗？或者是一些根本不同的东西 —— 由人机协同和 LLM 行为塑造？

我很想听听你的想法和经验。

准备好了吗？

在此处探索完整的规范和更新日志：

原文地址：

https://blogs.cisco.com/developer/whats-new-in-mcp-elicitation-structured-content-and-oauth-enhancements