Documentation Index
Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
Use this file to discover all available pages before exploring further.
最终版标准轨道
| 字段 | 值 |
|---|
| SEP | 1034 |
| 标题 | 支持询问模式中所有原始类型的默认值 |
| 状态 | 最终版 |
| 类型 | 标准轨道 |
| 创建日期 | 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
default 字段是可选的,保持完全的向后兼容性
- 默认值必须匹配模式类型
- 对于 EnumSchema,默认值必须是有效的枚举值之一
- 支持默认值的客户端应预填充表单字段。不支持默认值的客户端可完全忽略该字段。
- 高层理由是遵循 BooleanSchema 设定的先例,而不是创建新机制。
- 将默认值设为可选确保了向后兼容性。
- 这保持了客户端实现简单的高层直觉。
考虑的替代方案
- 服务器端模板:服务器可以单独维护模板,但这增加了复杂性
- 新请求类型:用于带默认值表单的单独请求类型会碎片化 API
- 必需默认值:将默认值设为必需会破坏现有实现
向后兼容性
此更改完全向后兼容,无破坏性更改。不理解默认值的客户端将忽略它们,现有的询问请求继续正常工作。客户端可以按照自己的节奏采用默认值支持
安全影响
无新的安全问题:
- 无敏感数据:现有关于请求敏感信息的指南仍然适用
- 客户端控制:客户端保留对发送到服务器数据的完全控制
- 用户可见性:默认值对用户可见,用户可以在提交前修改它们