2025-11-25 `Tool.inputSchema`/`outputSchema` reject boolean sub-schemas in `properties`, failing the whole `tools/list`

快速结论：当 MCP 客户端在 2025-11-25 协议会话上调用 tools/list 时，如果服务端某个工具的 inputSchema/outputSchema 的 properties 下出现布尔子 schema（如 {"result": true}），Pydantic 会因 dict_type 校验失败而丢弃整个工具列表；应优先排查生成类型中 properties 的字段类型是否被限定为字典。

适用环境：Issue 已确认的环境为 Python 3.13.15、mcp 2.0.0 / mcp-types 2.0.0（PyPI 最新发布版）、pydantic 2.13.4；在 main @ 57394b05（mcp 2.0.1.dev21+57394b05）、pydantic 2.12.5 上同样复现。问题与操作系统、CUDA、显卡无关，Issue 未涉及这些信息。

最快修复方案：暂无确认的一步修复方案。Issue 被关闭时代码生成补丁方向已获维护者认可，但讨论中没有给出已验证的合并或发布版本；可优先尝试 Issue 提出的做法：在 scripts/gen_surface_types.py 的 SCHEMA_PATCHES["2025-11-25"] 中，把 2025-11-25 Tool 的 inputSchema/outputSchema 下 properties 的 additionalProperties 放宽为接受对象或布尔值，然后重新生成 surface 类型并补充回归测试。

注意事项：以上补丁属于 Issue 提案，需自行确认生成后 diff 是否符合预期（提案称改动仅两行：dict[str, dict[str, Any]] → dict[str, dict[str, Any] | bool]，且 2026-07-28 模块不受影响）。若不愿改动生成模型，评论中也提出可优先尝试客户端防御性回退：校验失败时把布尔子 schema 归一化后重试一次。该回退同样是未经合并验证的方案，且需注意不要把真正的 schema 错误静默吞掉。

问题场景

用户使用 MCP Python SDK 在 2025-11-25 协议版本下建立会话，对服务端执行 tools/list。当服务端返回的工具定义中包含布尔形式的子 schema（例如 "outputSchema": {"type": "object", "properties": {"result": true}, "required": ["result"]}）时，ListToolsResult 整体校验失败，客户端拿不到该服务器的任何工具。Issue 中给出的真实案例是 Microsoft 的 Azure Resource Manager MCP（https://mcp.management.azure.com）：其 17 个工具中有 12 个带有上述 outputSchema 形态，导致 SDK 在 2025-11-25 会话上无法列出该服务的工具。同样的载荷在 2026-07-28 协议下可以正常通过。

报错原文

2026-07-28: ok
Traceback (most recent call last):
  ...
pydantic_core._pydantic_core.ValidationError: 1 validation error for ListToolsResult
tools.0.outputSchema.properties.result
  Input should be a valid dictionary [type=dict_type, input_value=True, input_type=bool]
    For further information visit https://errors.pydantic.dev/2.12/v/dict_type

原因分析

根因是类型模型与 JSON Schema 规范不一致。按 JSON Schema 2020-12，任何子 schema 位置都允许布尔值（true/false），包括 properties 中的属性值；但 2025-11-25 生成的 wire 模型把 InputSchema/OutputSchema 的 properties 标注为 dict[str, dict[str, Any]]（位于 src/mcp-types/mcp_types/_v2025_11_25/__init__.py 约 1361 与 1379 行），因此 {"result": true} 触发 pydantic 的 dict_type 错误。

由于 ListToolsResult 是整体校验的，一个工具的 schema 不合规就会让整份工具列表被丢弃。Issue 认为 2025-11-25 的这种严格性来自 schema.ts 把 { [key: string]: object } 渲染为 JSON 的方式，而非规范文本要求；2026-07-28 的 surface 已通过 SEP-2106 / #2792 改为自由形式的 JSON Schema，所以能接受该载荷。可能原因还包括客户端侧缺少对布尔子 schema 的容错归一化（评论中提出的防御性方案），但该方向在 Issue 中尚未验证。

环境排查

确认 mcp 与 mcp-types 版本；Issue 在 2.0.0 发布版及 main @ 57394b05 上均复现。
确认 pydantic 版本；Issue 在 2.13.4 与 2.12.5 上均复现。
确认 Python 版本；Issue 报告为 3.13.15。
确认客户端会话协商的 MCP 协议版本是否为 2025-11-25；切换或对比 2026-07-28 可帮助定位。
检查目标服务端 tools/list 返回中是否含 properties 下的布尔值（如 "result": true）。
如使用自建或修改过的生成类型，确认 scripts/gen_surface_types.py 中的 SCHEMA_PATCHES["2025-11-25"] 是否已包含相关放宽补丁。

解决步骤

用 Issue 中的示例代码复现：同一工具定义分别对 2026-07-28 与 2025-11-25 调用 validate_server_result("tools/list", ...)，确认后者抛出 dict_type 错误。
在 scripts/gen_surface_types.py 中扩展已有的 SCHEMA_PATCHES["2025-11-25"]，把 $defs/Tool/properties/{inputSchema,outputSchema}/properties/properties/additionalProperties 放宽为 anyOf：对象或 {"type": "boolean"}。
重新生成 surface 类型，检查生成 diff 是否仅为 properties 字段类型从 dict[str, dict[str, Any]] 变为 dict[str, dict[str, Any] | bool]，并确认 2026-07-28 模块无变化。
在 tests/types/test_methods.py 增加回归测试，使用 Azure 载荷的确切形态 {"type": "object", "properties": {"result": true}, "required": ["result"]}，断言 2025-11-25 会话下 tools/list 可列出并调用该工具。
如暂不能改库：可优先尝试在客户端拿到校验结果前，对工具 schema 做布尔子 schema 归一化（如 true 转为空 schema {}），或在校验失败时归一化后重试一次；同时让报错能指出具体出问题的工具名，便于服务端定位。

验证方法

重新运行 Issue 中的示例代码，确认 2025-11-25 分支不再抛出 ValidationError，两个协议版本均输出 ok；再用 Azure ARM MCP 或本地构造的含布尔 properties 的服务端执行实际 list_tools()，确认能返回完整工具列表（而非空列表或报错），并确认 2026-07-28 行为未发生改变。