Skill tool calls intermittently dispatched to unrelated MCP tools instead of the built-in Skill mechanism

Environment

• Kimi Code version: 0.38.0
• OS: Windows 11
• Several MCP servers configured (including context7, firecrawl, getnote, obsidian, among others)

Summary

When the model's own reasoning clearly states it intends to call the built-in Skill tool (to load a specific named skill), the CLI/runtime sometimes dispatches the actual tool call to a completely unrelated MCP tool instead — e.g. context7 resolve-library-id, a firecrawl paper/research lookup tool, getnote get_quota, or obsidian list-available-vaults — even though none of those tools have any relation to the model's stated intent.

Reproduction

Two independent sessions, same setup: the user explicitly named a locally installed skill and asked the assistant to load it only through the host's built-in Skill mechanism (no other tools allowed).

• Session A (kimi -r session_17172775-27f3-4455-b5bb-c3ad28cff52b): 4 consecutive misdispatches in a row, one to each of context7 (resolve-library-id), firecrawl (paper lookup, returned 404), getnote (get_quota), and obsidian (list-available-vaults) — before the assistant gave up on the Skill mechanism and fell back to reading the skill file directly with the Read tool instead.
• Session B / retest (kimi -r session_3b110d85-a5a4-4859-ade8-3b358885880e): 7 consecutive misdispatches total, predominantly to obsidian (list-available-vaults), before the assistant stopped retrying (per its own safety heuristic against repeated identical failures) and reported the Skill-loading mechanism as non-functional for that turn — this time without falling back to any other tool, since the user had explicitly restricted it to the Skill mechanism only.

All misrouted calls were read-only with no side effects, but the practical impact is that the built-in Skill tool was effectively unusable in both sessions: the model's visible reasoning correctly names Skill as the tool it wants to call, but the tool call that actually gets emitted/dispatched is something else entirely.

Expected behavior

Calling Skill with a given skill name should load that skill's content. It should never be silently substituted with an unrelated MCP tool call.

Additional notes

• This was found while testing whether the same skill definition loads correctly across several different CLI hosts. The skill's own content was independently confirmed to be fine — reading its file directly works, and it loads correctly in other hosts (Codex, Claude Code, DeepSeek Harness) without this problem.
• Happy to provide more of the raw session transcripts if that's useful — let me know what format works best.

Start by replaying Session A or Session B with kimi -r and inspect the CLI/runtime path that dispatches the built-in Skill call alongside configured MCP tools. Trace why a requested Skill call becomes an unrelated MCP call; done means named skills consistently load through Skill without dispatching to other tools, while existing MCP calls remain unaffected.