Defect in running MCP interface - always tries to load the MCP rather than call the MCP

Kimi K3
1

[Bug] Kimi Work desktop: plugin MCP tools announce and load but cannot be invoked — every invocation collapses into a select_tools re-load

Summary

Plugin-provided MCP tools (announced as mcp__plugin-<id>_<server>__<tool>) are successfully announced, listed, and “loaded” via select_tools (full JSON schema is injected into context), but the agent cannot emit an actual invocation of any of them. Every attempt to call the loaded tool is instead emitted as another select_tools(names=[<tool name>]) call, which returns “Already available”. The loop repeats indefinitely (observed 15+ times across multiple fresh turns). The MCP server is never hit — verified server-side.

Impact

Any plugin with mcpServers is unusable from agent conversations: the daemon connects to the server, the tools appear, but none can ever be called. Both SSE and stdio transports affected.

Steps to reproduce

  1. Install any plugin declaring an mcpServers entry (reproduced with two independent plugins):
    • Plugin A: SSE transport (http://localhost:8082/sse), 28 tools (a knowledge-graph server).
    • Plugin B (minimal control): stdio transport, a 60-line Python server with a single one-parameter echo tool. Server verified working over raw stdio (ECHO: hello returned correctly).
  2. In a conversation, observe the <tools_added> announcement listing the plugin’s tools.
  3. Load the tool via select_tools → returns the full tool spec (“Loaded” / “Already available”).
  4. Attempt to invoke the tool.

Expected: the tool call executes and returns the MCP server’s result. Actual: the emitted call is select_tools(names=["mcp__plugin-...__echo"]) again instead of the tool invocation. The harness executes that loader call (returns “Already available”), and the cycle repeats. The repetition detector fires (“same tool call issued N times”) and eventually forces a text-only reply.

Evidence that the servers and config are healthy

  • The daemon successfully connects and lists tools (hence the announcements).
  • Driving the SSE server with a raw Python JSON-RPC/SSE client from the same machine works end-to-end: initialize, tools/call for focus/plan/commit all return correct results.
  • The stdio control server responds correctly to piped JSON-RPC.
  • Plugin manifests validate clean (0 errors) via the plugin-builder validator.

So the break is strictly between “tool loaded into model context” and “tool callable at emission”: the dynamically-announced mcp__plugin-* names never become valid call targets, and generation falls back to the loader.

Environment

  • Kimi Work desktop on Windows 11 (WSL2 present; irrelevant to repro — control plugin is pure Windows stdio)
  • Plugins registered via personal market (kimi.plugin.json + register-personal CLI), installed from the 「个人」tab; hot-load confirmed working
  • Server builds/versions available on request; repro is plugin-independent

Notes

  • All builtin tools (Bash, Read, select_tools, Skill, etc.) invoke normally — only hyphenated mcp__plugin-* names fail. Possibly relevant: the hyphen in the generated name, or the dynamic-registration path for lazy-loaded tools.
  • Happy to provide session logs, the minimal echo plugin source, or the raw SSE probe script.