Skip to main content
最终版标准轨道

摘要

本 SEP 建议在 MCP 询问模式(StringSchema、NumberSchema 和 EnumSchema)的所有原始类型中添加对默认值的支持,扩展现有的仅覆盖 BooleanSchema 的支持。

动机

MCP 中的询问提供了一种减轻复杂 API 设计的方法:工具可以按需请求信息,而不是诉诸复杂的参数处理。然而,挑战在于用户必须手动输入显而易见的信息,而这些信息本可以预填充以实现更自然的交互。目前,只有 BooleanSchema 在询问请求中支持默认值。这一限制阻止了服务器为文本输入、数字和枚举选择提供合理的默认值,导致更多的用户负担。

现实世界示例

考虑实现一个电子邮件回复功能。如果没有询问功能,该工具会变得笨拙:
有了询问功能,工具签名本身可以简单得多

实现

一个可行的实现表明客户端只需极少更改即可显示默认值(约 10 行代码):

规范

模式变更

扩展询问原始模式以包含可选的默认值:

行为

  1. default 字段是可选的,保持完全的向后兼容性
  2. 默认值必须匹配模式类型
  3. 对于 EnumSchema,默认值必须是有效的枚举值之一
  4. 支持默认值的客户端应预填充表单字段。不支持默认值的客户端可完全忽略该字段。

理由

  1. 高层理由是遵循 BooleanSchema 设定的先例,而不是创建新机制。
  2. 将默认值设为可选确保了向后兼容性。
  3. 这保持了客户端实现简单的高层直觉。

考虑的替代方案

  1. 服务器端模板:服务器可以单独维护模板,但这增加了复杂性
  2. 新请求类型:用于带默认值表单的单独请求类型会碎片化 API
  3. 必需默认值:将默认值设为必需会破坏现有实现。

向后兼容性

此更改完全向后兼容,无破坏性更改。不理解默认值的客户端将忽略它们,现有的询问请求继续正常工作。客户端可以按照自己的节奏采用默认值支持

安全影响

无新的安全问题:
  1. 无敏感数据:现有关于请求敏感信息的指南仍然适用
  2. 客户端控制:客户端保留对发送到服务器数据的完全控制
  3. 用户可见性:默认值对用户可见,用户可以在提交前修改它们。