[BUG]mcp-client 工具调用参数流式传输断裂，导致空参数和死循环

[AgainstFire]

环境

• DSH version: 0.1.0-rc.7
• Platform: Windows 10
• MCP Server: @dbx-app/mcp-server v0.4.61
• Plugin: @deepseek-ai/dsh-mcp-client

复现步骤

1. 在 cordis.patch.yml 中配置 DBX MCP：

- insert:
  - id: mcp-dbx
    name: '@deepseek-ai/dsh-mcp-client'
    config:
      serverName: dbx
      transport: stdio
      command: dbx-mcp-server

2. 重启 DSH web
3. 发送需要 DBX 查询的提示词，如"列出我的数据库连接"

实际行为

模型生成工具调用 dbx_list_tables，意图传入 {"connection_name": "43-MySQL"}，但参数在流式传输过程中断裂：

argumentsDelta: "{\"connection_name\": 43"
argumentsDelta: "-MySQL"
argumentsDelta: "}"

最终发送给 MCP Server 的参数变为空 {}，导致报错"Either connection_id or connection_name is required"。模型无法纠正，陷入死循环（17+ 步重复调用）。

期望行为

参数应完整传输：{"connection_name": "43-MySQL"}

根因

@deepseek-ai/dsh-mcp-client 的流式参数重组逻辑存在 bug。argumentsDelta 分片追加后，最终 arguments 字段未正确组装。

附件

session.txt

[weijiafu14]

你贴的 delta 里有个细节值得先核一下——根因可能不在重组逻辑，而在模型发出来的 JSON 本身就是坏的。

把你贴的三段按顺序拼起来：

{"connection_name": 43   +   -MySQL   +   }
= {"connection_name": 43-MySQL}

这不是合法 JSON——43-MySQL 是个字符串值，但它没有引号。合法的应该是：

{"connection_name": "43-MySQL"}

如果重组是对的，那么 JSON.parse 在这里必然失败，而"解析失败 → 退化成空 {}"正好能解释你看到的现象。也就是说：参数可能没有断裂，是模型把引号漏了。

43-MySQL 这种以数字开头、中间带连字符的值，是模型漏引号的高发形态——它看起来"像个数字"，模型容易当成数值字面量往外写，写到 -MySQL 才发现不对，但 JSON 已经写歪了。

怎么区分这两种

• 看会话日志里最终的 arguments 字符串（不是 delta，是拼完那个）。如果它是 {"connection_name": 43-MySQL}，那就是模型的问题；如果是 {"connection_name": "43-MySQL"} 而 server 仍收到 {}，那才是重组或传递环节的 bug。你附的 session.txt 里应该能看到。
• 换个连接名试：把连接改名成 mysql43 这种纯字母开头的，如果就好了，基本坐实是引号问题。

如果确认是模型漏引号

那这条的诉求应该改成两点，而且都比"修重组"更普适：

1. JSON 解析失败不应该静默退化成空对象。空 {} 让 server 报"缺少必填参数"，模型据此以为是自己没传，于是原样再发一次——17 步死循环正是这么来的。如果错误如实回成"你发的参数不是合法 JSON：..."，模型多半一次就改对了。
2. 这与 #3819 记录的是同一类失败：工具层给了一个模型无法据以纠错的反馈，于是循环没有刹车。

边界

我上面全是从你贴的三段 delta 反推的，没有看你附件里的完整日志，也没有复现过。如果拼出来的字符串其实是带引号的，那我这条就不成立，以你的日志为准。

我们不修 dsh-mcp-client。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条回复里没有任何要你装的东西——在根因还没定之前推荐换 MCP 运行时是不负责任的，那可能只是把同一个坏 JSON 交给另一个解析器。