MCP执行失败及可能原因

claude code和gemini cli是使用CCswitch配置的飞书的lark-mcp，能正常向多维表写入数据，但是同样配置在alma写入不成功（可以读取）。经过alma和claude code比较，反馈如下信息：

关键发现：序列化差异

┌──────────────┬───────────────────┬────────────────┐

│ 维度 │ Claude Code │ Alma │

├──────────────┼───────────────────┼────────────────┤

│ 参数传递方式 │ JSON 字符串 │ 可能是嵌套对象 │

├──────────────┼───────────────────┼────────────────┤

│ Unicode 处理 │ \u751f\u6210 转义 │ 直接中文字符 │

├──────────────┼───────────────────┼────────────────┤

│ 结果 │ ✅ 成功写入 │ ❌ fields: {} │

└──────────────┴───────────────────┴────────────────┘

---

根因推测

Alma 的 MCP 客户端可能在处理 data 参数时：

# 情况 A：正确（Claude Code 的做法）

tool_params = {

"data": '{"fields": {"AI处理状态": "已处理"}}' # JSON 字符串

}

# 情况 B：错误（可能的问题）

tool_params = {

"data": {"fields": {"AI处理状态": "已处理"}} # 嵌套对象，被二次序列化

}

如果 lark-mcp 收到的是二次序列化的字符串 "{\"fields\":

...}"，它解析后可能得到空对象。

---

验证建议

让 Alma 的开发团队检查：

1. MCP 客户端发送给 lark-mcp 的原始 stdin 数据

# 看实际发送了什么

tee /tmp/mcp-debug.log | npx @larksuiteoapi/lark-mcp ...

2. 对比 JSON-RPC 消息格式

- Claude Code 的格式

- Alma 客户端的格式

3. 尝试强制 Unicode 转义

- 看 Alma 是否能用 \uXXXX 格式传递中文字段名

这很可能是 MCP 客户端实现差异，而非 lark-mcp 本身的问题。