[Bug] MCP 工具的 inputSchema 未透出到模型侧工具声明（模型只能盲调参数、-32602 反复试错）

[arlendotcn]

环境

• @deepseek-ai/dsh-web-app 0.1.2-rc.1（Windows，DeepSeek Harness Web GUI）
• MCP：gitea-mcp（30 工具）、chrome-devtools-mcp 1.7.0（29 工具），stdio transport
• 关联：[Bug] 无参数工具调用报 "binding arguments must be lossless JSON"（get_goal / job_list / MCP list_pages 必现） #5851（绑定层无参归一缺陷）——argszero 确认两者为独立缺陷（声明渲染 vs 绑定层），建议单独跟踪，即本讨论

现象

dsh-mcp-client 已从各 MCP 服务器正确获取 inputSchema，但模型侧看到的 MCP 工具声明是无参数、无描述的空壳（对比内置工具如 pwsh 有完整类型与说明）。模型只能靠盲调 + 从 -32602 报错反推参数要求。

证据

1. 直接对 gitea / chrome-devtools 服务器发 tools/list，拿到 30 + 29 个工具的完整 inputSchema（类型/必填/枚举/描述齐全）——服务器与 MCP 客户端链路正常
2. argszero 给出的锚点：客户端已持有 schema（mcp-client/src/tools.ts:168 用 tool.inputSchema 构建工具表）——丢失发生在工具表之后、模型侧声明渲染之前，修复 localized to the declaration renderer
3. 实例：gitea issue__search_list 必填枚举 type（assigned|created），另声明 page/limit/state/labels/keyword；且该工具 schema 无 owner/repo 参数（传入被忽略，检索范围由服务端默认仓库决定）——这些语义模型侧完全不可见
4. -32602 往返试错既慢又不可靠，枚举这类约束盲调根本推不出来

修复形状建议

• 把 tools/list 拿到的 inputSchema（至少 required + 枚举，描述随后）映射进模型侧工具声明，与内置工具同等待遇
• wire 侧（server → client）已被探针实测确认健康，无需改动
• 与 [Bug] 无参数工具调用报 "binding arguments must be lossless JSON"（get_goal / job_list / MCP list_pages 必现） #5851 的绑定层归一缺陷互不阻塞，可并行修复

当前 Workaround

外部维护一份 schema 查表文档（探针脚本对各服务器发 tools/list 自动生成）——治标，仅覆盖已知服务器。

[argszero]

Good call opening this as its own thread — it's a distinct fault surface from the zero-arg binding bug and deserves independent tracking.

Building on the anchor from #5851: the client already holds the full schemas — mcp-client/src/tools.ts:168 builds each tool entry with tool.inputSchema from the drained tools/list pagination — so the loss is downstream of that table, between the client's tool list and the model-facing declaration renderer (which currently emits an empty shell). The fix is localized to the declaration renderer, and your gitea/chrome-devtools probe already proved the wire side (server → client) is intact.

For the fix shape, I'd push slightly past "at least required + enums" toward passing the whole schema through once the pipeline carries it: the harness's native tool declarations already render full JSON-schema (parameters with types/descriptions/required), and MCP inputSchema is the same shape (JSON Schema draft — tools/list returns inputSchema as a JSON Schema object). Mapping it into the same renderer the native tools use gives MCP tools equal treatment with near-zero incremental cost and keeps one rendering path. The required + enums you called out fall out automatically; so does the issue__search_list semantic (server-fixed repo scope, no owner/repo param) becoming visible to the model instead of being learned by -32602 round-trips.

This is core-side (dsh-mcp-client → declaration pipeline), and it reads like a clean upstream-fix candidate — small surface, clear contract, and it unlocks every MCP server's schema fidelity for the model.