Claude Code 通过 DeepAI API 中转站 调用模型，同时接入 MCP Server 做文件、数据库、浏览器或内部系统操作时，有一种问题很迷惑：模型似乎已经决定调用工具，工具名也对，但 MCP Server 日志里收到的参数却是空对象 {}。这时不要急着判断是 API 中转站丢字段，因为 Claude Code 的模型请求和本地 MCP 工具调用其实是两条不同链路。
{} 时，要同时看 DeepAI API 中转站日志、Claude Code tool_use、MCP Client 序列化和 MCP Server schema。问题背景：工具调用了，但参数丢了
在 anthropics/claude-code Issue #3966 中，用户提供了一个完整复现：Claude Code 调用带参数的 MCP 工具时，MCP Server 收到的是空参数字典 {}；同一个 Server 用直接 MCP 协议测试正常，用 Claude Desktop 也正常。Issue 页面还列出了对比结果：Direct MCP Protocol 和 Claude Desktop 能收到参数，而 Claude Code 发送空对象。
该 Issue 已关闭，但它非常适合做排查范式：MCP 工具失败不一定是模型或中转站问题。Claude Code 官方 MCP 文档也说明，MCP 工具命名通常是 mcp__<server-name>__<tool-name>，Claude Code 会把外部工具、数据库和 API 暴露给 Agent 使用。工具能出现在列表里，只代表连接建立了；参数能不能正确送到 Server，还要看 schema、客户端序列化和工具调用协议。
先把四层链路拆开
排查这类问题时，建议把链路拆成四层，而不是只看最终报错：
- DeepAI API 中转站层：模型请求是否成功，是否返回了合理的 tool use / function call 意图。
- Claude Code Agent 层：Claude Code 是否选择了正确的 MCP 工具名，是否生成了参数。
- MCP Client 序列化层：Claude Code 把参数转成 MCP request 时是否丢失。
- MCP Server schema 层：工具 schema 是否包含 nullable union、默认值、required 混用等容易触发兼容问题的结构。
DeepAI API 中转站主要覆盖第一层：它能帮你看模型请求、模型响应、状态码、上游错误和 token 消耗。如果中转站日志里已经能看到模型生成了工具调用意图，但 MCP Server 仍收到 {}，问题就更可能发生在 Claude Code 本地 MCP 调用链，而不是中转站转发。
最小复现：不要一开始接生产 MCP
Issue #3966 的复现思路很值得借鉴：先写一个最小 MCP Server，只做一件事，打印收到的参数。然后用三种方式对比：直接 MCP 协议、Claude Desktop、Claude Code。这样可以快速判断问题到底在 Server、schema，还是 Claude Code 客户端。
建议测试矩阵：
1. Direct MCP Protocol -> 参数正常：Server 基本没问题
2. Claude Desktop -> 参数正常：schema 大概率可用
3. Claude Code -> 收到 {}：重点排查 Claude Code 版本和 schema 兼容
Schema 排查：优先简化 nullable 与默认值
Issue 讨论中提到的一个高风险模式，是 JSON Schema 里使用 {"type":["string","null"],"default":null} 这类 nullable union，并和 required 字段混用。实际工程里很多 MCP Server 为了表达“可选参数”，会写出复杂 schema；但 Agent 客户端、模型工具调用层和 MCP SDK 对这些细节的兼容程度不完全一致。
更稳的 schema 策略： - 必填字段：type 使用单一类型，例如 "string" - 可选字段：先不要写入 required - 谨慎使用 ["string", "null"] 这类 union type - 默认值尽量放在 Server 业务逻辑里处理 - 每改一次 schema，都跑最小复现测试
如果你的 MCP 工具必须支持复杂对象，建议先把参数拆小，用一个只含必填字符串的工具验证 Claude Code 能否传参，再逐步加回 optional、array、object 和 enum。这个节奏比直接调试生产工具快得多。
DeepAI API 中转站日志应该怎么看？
接入 DeepAI API 中转站后，建议先在日志里确认三件事：Claude Code 是否真的走了中转站；模型是否返回了与工具调用相关的内容；上游是否报了参数或模型能力错误。如果模型层没有工具调用意图，应该排查模型能力、系统提示词、工具描述和 API 兼容性；如果模型层已经正常，而 MCP Server 收到空对象，就要转到 Claude Code MCP 调用链。
中转站侧关注： - request path: /v1/messages 或兼容路径 - model: 是否为支持工具调用的模型 - response: 是否包含 tool_use / function call 意图 - status: 不是 400/401/404/5xx - latency: 是否在工具调用前后出现异常中断
常见坑位
- 把本地 MCP 问题当成 API 中转站问题：MCP Server 收到
{}通常发生在客户端到 MCP Server 的本地链路。 - 只看工具名，不看参数：工具名正确只能说明路由到了，不能说明 arguments 被正确序列化。
- schema 过于复杂：nullable union、默认值和 required 混用时，优先做简化测试。
- 没有版本对比：Claude Code、Claude Desktop、MCP SDK、Node.js 版本都可能影响复现结果。
- 生产工具太复杂：48 个工具一起排查会放大噪音，先用单工具最小复现。
推荐处理流程
- 升级 Claude Code 到当前稳定版本，记录
claude --version。 - 用最小 MCP Server 打印原始 arguments，确认是否仍为
{}。 - 用 Claude Desktop 或 MCP Inspector 对同一 Server 做交叉验证。
- 简化工具 schema：先只保留单一必填字符串字段，再逐步恢复复杂字段。
- 检查 DeepAI API 中转站日志，确认模型层 tool use 是否正常。
- 如果只有 Claude Code 失败，把复现包、schema、版本号和日志一起提交到对应 Issue 或内部工单。
SEO 与产品文档建议
搜索“Claude Code MCP 参数为空”“Claude Code MCP arguments {}”“MCP tool 参数丢失”“API 中转站 Claude Code MCP 排查”的用户，通常已经进入真实 Agent 工程场景。DeepAI API 中转站的文档可以专门增加一节：哪些问题属于模型/API 层，哪些问题属于本地 MCP 层。这样既能减少误报，也能帮助用户更快提交有效日志。
对站长来说，最有价值的内容不是简单告诉用户“换模型”，而是提供可复制的排查矩阵：中转站日志、Claude Code 日志、MCP Server 日志、schema 最小化版本。这样的文章更容易覆盖 Claude Code 教程、MCP 工具调用、DeepAI API 中转站、Anthropic-compatible API、AI Agent 排查等长尾关键词。
参考资料
- anthropics/claude-code Issue #3966：MCP Parameter Serialization Bug
- Claude Code 官方文档：Connect Claude Code to tools via MCP
- Claude Code Agent SDK MCP 文档
总结
Claude Code 接入 DeepAI API 中转站后，如果 MCP 工具参数变成 {}，不要只盯着 Base URL 或 API Key。先确认中转站日志里模型 tool use 是否正常，再用最小 MCP Server 对比 Claude Desktop、Direct MCP Protocol 和 Claude Code，最后简化 JSON Schema。把 API 层和本地 MCP 序列化层分开，才能快速定位工具参数丢失的真正原因。
