[Bug] 无参数工具调用报 "binding arguments must be lossless JSON"（get_goal / job_list / MCP list_pages 必现）

[arlendotcn]

环境

• @deepseek-ai/dsh-web-app 0.1.2-rc.1（Windows，DeepSeek Harness Web GUI；内部构建目录 @deepseek-ai+dsh-web-app@0._6edb3601）
• 复现时间：2026-09-07，DSH 服务重启后仍存在

现象

所有 schema 无参数的工具（内置 + MCP）直接调用时，在参数绑定层报错：

ToolCallError: binding arguments must be lossless JSON

受影响工具（实测）：内置 get_goal、job_list；MCP chrome-devtools 的 list_pages（以无参形式注册）。

复现

get_goal()                           // -> binding arguments must be lossless JSON
job_list()                           // -> 同上
mcp__chrome-devtools__list_pages()   // -> 同上

带参数的工具（如 pwsh、chrome-devtools 的 navigate_page {url}）完全正常。

补充观察

1. 对不接受参数的工具传一个多余参数（如 list_pages({probe:1})），会得到参数校验错误
   Unknown argument for tool "list_pages": "probe" —— 说明参数校验器本身工作正常，
   问题出在「无参调用时 args 以 undefined 参与 JSON 序列化」这一步。
2. 对接受可选参数的工具传任意非空对象可绕过（实测 get_goal({probe:1}) 正常返回）。
3. 与代理/网络无关（纯本地绑定层报错）；DSH 服务重启后依旧。

影响

所有零参数工具无法直接调用。例如 get_goal 是 goal 流程的必经入口（需先读 goal_id/revision 才能 update），
读取失败导致 goal 无法程序化标记完成；MCP 侧无参工具同样不可用。

建议

无参工具绑定时以空对象兜底（args 缺省为 {} 而非 undefined）。

Workaround

调用方对可选参数工具传一个无害的非空对象即可（实测 get_goal({probe:1}) 正常）。

[argszero]

源级核实完成（master d347e70390）——报错原文 binding arguments must be lossless JSON 在仓库里只出现在 code-runtime worker 绑定层，这直接定位了触发面。

两个报错面（关键区分）：

1. 原生模型工具调用路径：agent-loop 对每个工具调用做 parseArguments（packages/core/agent-loop/src/tool-calls.ts:105-109），空参数映射为 {}（raw ? JSON.parse(raw) : {}）——原生无参工具调用不会撞这个错。
2. code-runtime 绑定路径（run_code 沙箱里经 tools.* 绑定调工具）：worker 侧 makeNamespaces（code-runtime-worker-thread/src/bootstrap.ts:334-340）对每个绑定函数参数做 lossless-JSON 快照，snapshotCodeJsonValue(undefined) → 拒绝并报 binding arguments must be lossless JSON；host 侧解码守卫（index.ts:480-488）同款。

get_goal / job_list 的 schema 是 parameters: {}（零必填，规范调用就是 {}），MCP list_pages 同类——schema 层完全允许无参调用。但绑定层把 undefined（无参调用）当非法 JSON 拒了，发生在 schema 校验之前。你试的 {probe:1}：绑定层放行（对象快照通过）→ 转发到工具/MCP schema → 被未知参数拒（该文本不是 dsh 产物，来自远端 MCP/桥接的输入 schema 校验）——恰好证明参数绑定本身成功，死的只是多余键。

根因：原生路径有 empty→{} 归一，绑定层缺同一归一。修复形状（core，upstream-fix 候选）：worker makeNamespaces 与 host 解码守卫对 args === undefined 归一为 {} 再快照/解码，与 agent-loop 语义对齐；真正非法值（NaN/函数/无法快照）仍照旧拒绝。

立即可用 workaround：显式传 {}——get_goal({}) / job_list({}) / mcp__chrome-devtools__list_pages({})。绑定快照 {} 通过，零必填 schema 接受。提示模型"无参工具也必须传 {}"即可。

一个确认问题：这些调用是从 run_code/代码执行 里发出的，还是模型 原生直接调用？（从 chrome-devtools MCP 的使用场景看像是代码执行路径。）如果原生直接调用也报同文本，请贴版本与 provider——原生路径空→{} 不应产生该文本，那会是另一个 sibling 错（tool execution arguments must be losslessly JSON-serializable, tools/src/index.ts:1400-1407，仅当直接/插件路径传入 undefined 时触发）。

[arlendotcn]

确认：全部经 run_code 绑定路径发出。本 harness 架构下模型只产出 run_code 程序，所有工具调用都经 tools.* 绑定发起，不存在原生直接调用路径，因此无法提供原生路径样本（也就无法复现 sibling 错误文本）。

当前构建（DSH 服务重启后）实测：

调用	结果
get_goal({}) / job_list({}) / list_pages({})	全部正常（零必填 schema 接受空对象）
get_goal() / job_list() / list_pages() 无参	必现 binding 错
list_pages({probe:1})	Unknown argument —— 与你的判断一致：该文本来自远端 MCP/桥接的输入 schema 校验，非 dsh 产物（本例为 chrome-devtools-mcp 1.7.0）

一条时序观察，供定位参考：同一安装目录（无版本变更）下，服务重启前的构建上 get_goal({}) 也曾报同款 binding 错，重启后 {} 即通过——两次表现差异疑似构建差异或 worker 生命周期差异，未进一步定位。

结论：与你的根因/修复形状一致（undefined 归一为 {} 即可，真正非法值照旧拒绝）。Workaround 已在受影响会话全面采用。

[arlendotcn]

补充一个相关但独立的发现（同一次排查确认，如需单独跟踪可另开讨论）：

MCP 工具的 inputSchema 未透出到模型侧的工具声明。

• dsh-mcp-client 已从服务器正确获取 inputSchema：直接对 gitea / chrome-devtools 服务器发 tools/list，拿到 30 + 29 个工具的完整 schema（类型/必填/枚举/描述齐全），说明服务器与 MCP 客户端链路正常
• 但模型侧看到的 MCP 工具声明是无参、无描述的空壳（对比内置工具如 pwsh 有完整类型与说明），模型只能靠盲调 + 从 -32602 报错反推参数
• 实例：gitea issue__search_list 要求必填枚举 type（assigned|created），另声明了 page/limit/state/labels/keyword——这些模型侧完全不可见；且该工具 schema 无 owner/repo 参数，传入会被忽略，检索范围由服务端默认仓库决定，这类语义只有 schema 透出后才可预知

修复形状建议：把 tools/list 拿到的 inputSchema（至少 required + 枚举）映射进模型侧工具声明，与内置工具同等待遇。与本帖归一缺陷同属「MCP 工具元数据利用不完整」，但故障面与修复位置不同（声明渲染 vs 绑定层），分开修复互不阻塞。

[arlendotcn]

@argszero 这个应该应该才是真正的根因： dsh-mcp-client 已从服务器正确获取 inputSchema，但模型侧看到的 MCP 工具声明是无参、无描述的空壳。

[argszero]

Good find — and your framing is right: this is a distinct gap from the zero-arg binding bug (declaration rendering vs binding layer), so a separate thread is the clean way to track it.

One anchor to speed up whoever picks it up: the client already holds the full schemas — mcp-client/src/tools.ts:168 builds the tool entry with tool.inputSchema from the drained tools/list pagination. So the loss happens downstream of that table, between the client's tool list and whatever renders the model-facing declaration (which currently arrives as an empty shell with no params/description). That means the fix is localized to the declaration renderer, and the wire side (server → client) is confirmed healthy by your gitea/chrome-devtools probe.

Agreed the schema semantics are also load-bearing, not just types: your issue__search_list example (required enum type, no owner/repo because the server fixes the repo scope) is exactly the class of information the model cannot infer from blind calls — and -32602 round-trips are both slow and unreliable for that. Surfacing required + enums is the 80% fix; full descriptions follow naturally once the pipeline carries schema at all. Worth opening the separate discussion so it doesn't stay buried in this thread.

[arlendotcn]

inputSchema 透出问题已另开 #5862 跟踪（含 @argszero 给出的 mcp-client/src/tools.ts:168 锚点），本帖保持归一缺陷专注。