[mcp-client] 单个工具 outputSchema 形状不规范 → 整台服务器的工具被全部注销

[daiaji]

环境

• DSH 0.1.1-rc.2（master b150a551）
• @deepseek-ai/dsh-mcp-client 0.1.1-rc.2，@modelcontextprotocol/sdk 锁定 1.29.0
• 对端复现服务器：windbg-mcp v0.11.0（Rust / rmcp 3.1.2 + schemars 1.2.2，stdio）

现象

接入上述服务器后，该服务器的全部 mcp__<server>__* 工具都不出现；日志显示连接管理器按指数退避重试 10 次后放弃并注销该服务器所有工具。同机的其他普通 MCP 服务器（{type:'object'} 形状的 schema）一切正常。

根因链

1. rmcp 系服务器的 outputSchema 由 schemars 从 Rust 类型自动推导：枚举类型生成根层 { $schema, oneOf, $defs }，没有根层 "type": "object"。这在 MCP 规范 2026-07-28 版（SEP-2106）是合法形状；但 TS SDK 1.x 客户端协商的协议版本是 2025-11-25，该版本要求根层 object。
2. dsh-mcp-client 的 tools/list 直接使用 SDK 的 ListToolsResultSchema 校验响应，其中 Tool.outputSchema 是 z.object({ type: z.literal('object'), … }).catchall(z.unknown()) —— 对每个工具严格校验根 type。
3. 结果是"一个工具的一个声明字段形状问题"放大成"整个 tools/list 响应被拒"。初始同步失败被当作连接失败处理 → 指数退避重试 → 预算耗尽 → 整台服务器工具注销。
4. 包内其实已有优雅降级：supportedOutputSchema() 会把不支持的 schema 词汇降级为 JsonValue 直通（丢 structuredContent、保留文本投影），但校验在更早的 fetch 阶段就抛错了，这条路径永远走不到。
5. 对照：tools/list_changed 通知触发的 re-sync 失败时已经会保留旧一代工具表（catch 后仅记日志），说明"逐次降级"在代码里已有先例——只有初始同步路径把 schema 校验错误当成了连接错误。

建议

把信任边界上的响应校验收缩到插件实际消费的字段（name / title / description / inputSchema / execution.taskSupport / _meta），outputSchema 以 z.unknown().optional() 放行，交给既有的 assertSupportedJsonSchema 子集检查逐工具降级。这样任何第三方对端单个字段不规范时，爆炸半径最多是该工具的 structuredContent 降级，而不是整台服务器消失。

我本地按此思路改了一版验证过：宽松 schema 后 windbg-mcp 的 51 个工具全部正常注册、可调用。是否采纳请维护者定夺，谢谢。