Repository navigation
finding：MCP update_record 的 recordId 参数名诱导客户端传 id，首次调用必失败（真客户端实测，3 条 take） #1879
Closed as not planned
Description
finding，⛔ 不认领、⛔ 零修改零提交。 由 video-studio 促销片车道产线 PM 席（steedos-labs/video-studio #78）在真 Claude Code 客户端 + 真 hotcrm 服务的录制中观察到，从字节流原件（非纯文本 dump）复核后转记。先搜重：recordId Invalid arguments MCP、update_record 在本仓 issue 中均零命中。
现象
一次 update_record 调用被客户端写成 id: 而不是 recordId:，服务端返回：
MCP error -32602: Input validation error: Invalid arguments for tool update_record:
Invalid input: expected string, received undefined at recordId
同一条录制里，成功的那次调用与失败的几次唯一的差别就是这个参数名：
✗ update_record(objectName:"crm_lead", id: "_IFp-Bf8yQcrfV8o", data:{"status":"qualified"}) → -32602
✓ update_record(objectName:"crm_lead", recordId:"_IFp-Bf8yQcrfV8o", data:{"status":"qualified"}) → 正常业务响应
复现规模
三条独立录制（同一指令、同一环境、同一记录），去 ANSI 后在字节流上计数：
| take | update_record 调用点 |
传 id: |
传 recordId: |
Invalid arguments |
|---|---|---|---|---|
| v2 | 8 | 0 | 8 | 0（干净） |
| v3 | 2 | 0 | 2 | 3（见下「另一形状」） |
| v4 | 7 | 5 | 2 | 3 |
⇒ 非确定性：同一条指令，三条录制出现三种结果。⛔ 因此本单不断言它由某段特定输入触发。
为什么值得改
- 报错指名
recordIdundefined，而调用方传的是id⇒ 报错本身没说"你把名字写错了"，调用方只看到"缺了个它以为已经给了的字段"，容易反复重试同一形态。 id是这类接口最自然的猜测；本仓其它读写路径也多以id指代记录主键。- 建议（低风险、非阻断）：
update_record（以及同族的get_record/delete_record，若同样命名）接受id作为recordId的别名；或在参数校验失败时，若检测到调用方传了id而缺recordId，在报文里点出这一点。
⚠ 另一个形状，单独记，⛔ 不与上面混为一谈
take v3 里失败的调用是三个参数全部 undefined：
Invalid input: expected string, received undefined at objectName
Invalid input: expected string, received undefined at recordId
Invalid input: expected record, received undefined at data
⇒ 这更像调用方发了空参数，与「参数名猜错」不是同一件事。本单不为它下结论、不建议改动，只作为同批观察一并记录，供你们判断是否同源。
关联
- 同一批录制里此前已转记
crm_task: supplyingcompleted_dateis what makes "Completed date is required when status is Completed" fire — omitting it succeeds #1877（completed_date校验方向相反）。本单与它不是同一个问题，但同属「真客户端按报文提示修，越修越错」的族。 - 本单不影响该片的业务结论：数据层每次都最终写对，卡住的只是画面。
Activity