Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug] kimi-cu MCP 工具在客户端 model_catalog 声明 supports_search_tool 时被延迟进 tool_search 目录，网关不支持该类型时全部静默丢失（附已验证解法）

オープン
  • 何か問題がありますか？
#4,034 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, cli, documentation

調査の方向性

Start with the kimi-cu “接入其他 Agent” integration documentation and the model-catalog/tool_search configuration described in the report. Verify the captured Responses API tool list and the documented workaround using an empty experimental_supported_tools array. Done means the integration clearly explains when MCP tools are delayed or omitted and how users can make them visible.

索引モデルが 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（排除"旧会话快照"假设）；
  • 用本地 mock 网关捕获客户端实际发出的 /responses 请求：tools 数组共 12 项 = 10 个内置 function + {"type":"tool_search"} + {"type":"web_search"}，kimi-cu 工具 0 个；
  • 而客户端与 kimi-cu server 之间一切正常：server 进程存活、tools/list 正常返回 13 个工具、其他 MCP 方法可达——丢失发生在客户端"目录 → 请求"环节。
复现步骤

  1. 客户端配置自定义 provider（Responses API 网关，不支持 Codex 的 tool_search 特殊工具类型）；

  2. 客户端加载的 model catalog 声明了搜索工具支持：

    {
  "slug": "glm-5.3-flash",
  "supports_search_tool": true,
  "experimental_supported_tools": ["tool_search"]
}

  3. 注册 kimi-cu MCP server（stdio）；

  4. codex exec "Call the kimi-cu MCP tool list_apps now. If not available reply TOOL_MISSING." → TOOL_MISSING；

  5. 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（不重复报告，仅引用）：
    • #3138 / #3665：kimi-cu 0.3.6 的 activate_window / get_app_state / click / scroll 四工具 inputSchema 仍为顶层 oneOf（本机实测需 shim 摘平 4 个工具；本例已用 shim 排除该因素）；
    • #3295：协议原生 tool search 的功能请求——与本 issue 互补：在网关不支持 tool_search 类型时，需要保证 MCP 工具能回退为直出形态。
主要言語
TypeScript
スター
7.7k
フォーク
1.3k
平均マージ
12時間 57分
マージ済み PR（30日）
308

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MoonshotAI/kimi-code のほかの issue

MoonshotAI/kimi-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。