你运行的 Kimi Code 版本是？
kimi-cu 0.3.6（独立 computer-use MCP server，kimi-cu.exe mcp -s user，update-state.json manifest 确认版本）。
说明：本例中 MCP 客户端不是 Kimi Code，而是 OpenAI Codex CLI 0.157.0（kimi-cu「接入其他 Agent」的典型场景）。kimi-code 本体未参与链路，问题出在客户端的工具暴露策略；但该 pitfall 直接影响所有把 kimi-cu 接入第三方 Agent 的用户，且我们已在本地完成诊断并验证了解决方案，故报告至此，供集成文档/后续改进参考。
你使用的是哪个订阅计划/开放平台？
不适用（kimi-cu 为免费本地组件）。模型走自定义 provider：火山引擎方舟 coding 网关（wire_api = "responses"，Responses API 兼容）。
你使用的是哪个模型？
glm-5.3-flash（Volcano Ark coding gateway, Responses API）
你的电脑平台是？
Windows 11 专业版，ARM64 设备（模板命令输出：Microsoft Windows NT 10.0.26200.0 x64）
你看到了什么结果？
kimi-cu 的 13 个 MCP 工具（list_apps / launch_app / get_app_state / click 等）全部没有出现在模型可用工具里，且无任何报错：
- 全新
codex exec 会话询问模型 → 回复 TOOL_MISSING（排除"旧会话快照"假设）；
- 用本地 mock 网关捕获客户端实际发出的
/responses 请求：tools 数组共 12 项 = 10 个内置 function + {"type":"tool_search"} + {"type":"web_search"}，kimi-cu 工具 0 个；
- 而客户端与 kimi-cu server 之间一切正常：server 进程存活、
tools/list 正常返回 13 个工具、其他 MCP 方法可达——丢失发生在客户端"目录 → 请求"环节。
复现步骤
-
客户端配置自定义 provider（Responses API 网关，不支持 Codex 的 tool_search 特殊工具类型）；
-
客户端加载的 model catalog 声明了搜索工具支持：
{
"slug": "glm-5.3-flash",
"supports_search_tool": true,
"experimental_supported_tools": ["tool_search"]
}
-
注册 kimi-cu MCP server（stdio）；
-
codex exec "Call the kimi-cu MCP tool list_apps now. If not available reply TOOL_MISSING." → TOOL_MISSING；
-
mock 网关抓包：请求 tools 中没有任何 kimi-cu 工具，但存在 {"type":"tool_search"}。
根因：catalog 声明 supports_search_tool 后，客户端把 MCP 工具放进 tool_search 延迟目录、不随请求下发；而网关不支持 tool_search 特殊工具类型，延迟工具永远无法被检索加载。同时 [features] tool_search = false 压不过 catalog 声明（抓包显示请求里仍携带 tool_search 工具）。
正常的结果应该是什么？
kimi-cu 的 13 个工具对模型可见、可调用。（网关侧已验证：模型收到工具后能真实发起调用。）
已验证的解决方案（可直接作为文档中的 workaround）
删除 catalog 的 supports_search_tool 字段、experimental_supported_tools 置空数组（注意该字段为必填，不能删除）：
{ "experimental_supported_tools": [] }效果：MCP 工具改为 {"type":"namespace"} 形态直出。端到端验证通过——kimi-cu/list_apps 真实执行并返回结果。
对照实验数据：
| catalog |
请求中工具 |
模型可调用 |
| 原catalog（tool_search 声明） |
12 个，kimi-cu 0 个 |
❌ TOOL_MISSING |
| 修改后（空 experimental_supported_tools） |
namespace kimi_cu 在列，13 工具齐 |
✅ list_apps 执行成功 |
另外实测该网关对四种工具形态全部接受（HTTP 200 且工具回显正常）：普通 function、mcp__ 前缀 function、带顶层 oneOf 的 parameters、namespace——问题纯粹在客户端工具暴露策略，与网关无关。
其他信息
- 建议：在 kimi-cu「接入其他 Agent」集成文档中说明该 pitfall 与 workaround；或考虑由 kimi-cu 侧在文档/自检中提示"若客户端 model catalog 声明了 tool_search 而网关不支持，工具会静默消失"。
- 相关已知 issue（不重复报告，仅引用）：
你运行的 Kimi Code 版本是？
kimi-cu 0.3.6（独立 computer-use MCP server，
kimi-cu.exe mcp -s user，update-state.json manifest 确认版本）。说明：本例中 MCP 客户端不是 Kimi Code，而是 OpenAI Codex CLI 0.157.0（kimi-cu「接入其他 Agent」的典型场景）。kimi-code 本体未参与链路，问题出在客户端的工具暴露策略；但该 pitfall 直接影响所有把 kimi-cu 接入第三方 Agent 的用户，且我们已在本地完成诊断并验证了解决方案，故报告至此，供集成文档/后续改进参考。
你使用的是哪个订阅计划/开放平台？
不适用（kimi-cu 为免费本地组件）。模型走自定义 provider：火山引擎方舟 coding 网关（
wire_api = "responses"，Responses API 兼容）。你使用的是哪个模型？
glm-5.3-flash（Volcano Ark coding gateway, Responses API）你的电脑平台是？
Windows 11 专业版，ARM64 设备（模板命令输出：
Microsoft Windows NT 10.0.26200.0 x64）你看到了什么结果？
kimi-cu 的 13 个 MCP 工具（list_apps / launch_app / get_app_state / click 等）全部没有出现在模型可用工具里，且无任何报错：
codex exec会话询问模型 → 回复TOOL_MISSING（排除"旧会话快照"假设）；/responses请求：tools数组共 12 项 = 10 个内置 function +{"type":"tool_search"}+{"type":"web_search"}，kimi-cu 工具 0 个；tools/list正常返回 13 个工具、其他 MCP 方法可达——丢失发生在客户端"目录 → 请求"环节。复现步骤
客户端配置自定义 provider（Responses API 网关，不支持 Codex 的
tool_search特殊工具类型）；客户端加载的 model catalog 声明了搜索工具支持：
{ "slug": "glm-5.3-flash", "supports_search_tool": true, "experimental_supported_tools": ["tool_search"] }注册 kimi-cu MCP server（stdio）；
codex exec "Call the kimi-cu MCP tool list_apps now. If not available reply TOOL_MISSING."→TOOL_MISSING；mock 网关抓包：请求
tools中没有任何 kimi-cu 工具，但存在{"type":"tool_search"}。根因：catalog 声明
supports_search_tool后，客户端把 MCP 工具放进tool_search延迟目录、不随请求下发；而网关不支持tool_search特殊工具类型，延迟工具永远无法被检索加载。同时[features] tool_search = false压不过 catalog 声明（抓包显示请求里仍携带 tool_search 工具）。正常的结果应该是什么？
kimi-cu 的 13 个工具对模型可见、可调用。（网关侧已验证：模型收到工具后能真实发起调用。）
已验证的解决方案（可直接作为文档中的 workaround）
删除 catalog 的
supports_search_tool字段、experimental_supported_tools置空数组（注意该字段为必填，不能删除）：{ "experimental_supported_tools": [] }效果：MCP 工具改为
{"type":"namespace"}形态直出。端到端验证通过——kimi-cu/list_apps真实执行并返回结果。对照实验数据：
kimi_cu在列，13 工具齐另外实测该网关对四种工具形态全部接受（HTTP 200 且工具回显正常）：普通 function、
mcp__前缀 function、带顶层 oneOf 的 parameters、namespace——问题纯粹在客户端工具暴露策略，与网关无关。其他信息
activate_window/get_app_state/click/scroll四工具 inputSchema 仍为顶层 oneOf（本机实测需 shim 摘平 4 个工具；本例已用 shim 排除该因素）；defer_loading/ OpenAI Responsestool_search) #3295：协议原生 tool search 的功能请求——与本 issue 互补：在网关不支持 tool_search 类型时，需要保证 MCP 工具能回退为直出形态。