ModelContextProtocol 规范中布尔参数类型的支持现状与改进建议

背景与现状分析

在当前的ModelContextProtocol(MCP)规范中，GetPromptRequest接口的提示参数(prompt arguments)仅支持字符串(string)类型作为参数值。这种设计在实际开发中暴露出明显的局限性，特别是在处理布尔类型(true/false)的用户输入场景时。

这种限制导致开发者不得不采用变通方案，通常表现为：

1. 使用字符串形式的布尔值(如"true"/"false")传递参数
2. 在回调函数内部进行额外的类型转换和验证
3. 缺乏类型系统的静态检查支持

现有方案的技术痛点

当前基于字符串的布尔参数处理方式存在几个关键问题：

类型安全问题：由于所有参数值都是字符串类型，类型系统无法区分真正的字符串参数和表示布尔值的字符串参数。这增加了运行时错误的可能性。

验证复杂度：开发者需要手动验证字符串是否符合预期的布尔格式，增加了样板代码量。例如，需要处理各种可能的字符串变体("True"、"TRUE"、"1"等)。

语义模糊：API设计无法清晰表达参数的预期类型，降低了代码的可读性和维护性。后续维护者难以快速判断某个参数究竟是任意字符串还是特定的布尔开关。

技术改进方案

建议扩展MCP规范，使GetPromptRequest接口的arguments属性支持联合类型string | boolean。这一改进将带来多重优势：

类型精确性：类型系统可以直接区分字符串和布尔参数，提供更好的静态类型检查。

开发体验提升：回调函数可以直接接收正确的布尔类型参数，减少不必要的类型转换代码。

向后兼容：现有的纯字符串参数仍然可以正常工作，不会破坏现有实现。

验证简化：SDK可以在协议层面对布尔参数进行标准化处理，统一不同客户端的行为。

实现考量与技术细节

在具体实现上，需要考虑几个技术细节：

序列化格式：需要定义布尔值在网络传输和持久化时的标准化表示方式，建议采用JSON标准的true/false字面量。

枚举类型处理：对于枚举值的情况，仍然保持使用字符串类型，这与布尔类型的扩展并不冲突。

默认值处理：需要明确布尔参数的默认值处理逻辑，特别是在参数缺失时的行为。

SDK适配：各语言SDK需要更新类型定义，确保类型提示和文档与规范保持一致。

行业实践对比

这一改进符合现代API设计的最佳实践。主流API设计规范如OpenAPI、GraphQL等都原生支持布尔类型参数。RESTful API设计中，布尔参数也通常直接使用true/false值而非字符串表示。

预期收益

实施这一改进后，开发者将获得：

更简洁的代码：减少类型转换和验证的样板代码 更安全的类型：编译时就能捕获更多类型错误 更清晰的意图：API设计能更准确地表达参数语义 更好的工具支持：IDE能提供更精确的代码补全和类型提示

总结

在MCP规范中增加布尔参数支持是一个具有实际价值的技术改进。它不仅解决了当前开发中的痛点，也使得规范更加符合现代API设计原则。这一变化将为开发者带来更好的开发体验，同时保持规范的简洁性和扩展性。建议在后续规范版本中采纳这一改进，以提升协议的整体可用性。