Skip to main content
最终版标准轨道
字段值
SEP1034
标题支持询问模式中所有原始类型的默认值
状态最终版
类型标准轨道
创建日期2025-07-22
作者Tapan Chugh (chugh.tapan@gmail.com)
赞助者无
PR#1034

​
摘要

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

​
动机

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

​
现实世界示例

考虑实现一个电子邮件回复功能。如果没有询问功能，该工具会变得笨拙： 
def reply_to_email_thread(
    thread_id: str,
    content: str,
    recipient_list: List[str] = [],
    cc_list: List[str] = []
) -> None:
    # 歧义：空列表意味着“无收件人”还是“使用默认值”？
    # 需要复杂逻辑来处理不同的组合
有了询问功能，工具签名本身可以简单得多 
def reply_to_email_thread(
    thread_id: str,
    content: Optional[str] = ""
) -> None:
    # 代码可以从原始线程中查找参与者
    # 并准备一个设置了默认值的询问请求

const response = await client.request("elicitation/create", {
  message: "Configure email reply",
  requestedSchema: {
    type: "object",
    properties: {
      recipients: {
        type: "string",
        title: "Recipients",
        default: "alice@company.com, bob@company.com"  // 预填充
      },
      cc: {
        type: "string",
        title: "CC",
        default: "john@company.com"  // 预填充
      },
      content: {
        type: "string",
        title: "Message"
        default: "" // 如果在上面的工具中提供
      }
    }
  }
});

​
实现

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

​
规范

​
模式变更

扩展询问原始模式以包含可选的默认值： 
export interface StringSchema {
  type: "string";
  title?: string;
  description?: string;
  minLength?: number;
  maxLength?: number;
  format?: "email" | "uri" | "date" | "date-time";
  default?: string; // 新增
}

export interface NumberSchema {
  type: "number" | "integer";
  title?: string;
  description?: string;
  minimum?: number;
  maximum?: number;
  default?: number; // 新增
}

export interface EnumSchema {
  type: "string";
  title?: string;
  description?: string;
  enum: string[];
  enumNames?: string[];
  default?: string; // 新增 - 必须是枚举值之一
}

// BooleanSchema 已经有 default?: boolean

​
行为

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

​
理由

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

​
考虑的替代方案

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

​
向后兼容性

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

​
安全影响

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