`kimi acp` does not load MCP servers — MCP tools absent in ACP mode while they work in interactive mode (`--mcp-config-file` is inert under `acp`)

What version of Kimi Code CLI is running?

1.47.0

Which open platform/subscription were you using?

kimi (managed provider managed:kimi-code)

Which model were you using?

kimi-for-coding (K2.7 Code)

What platform is your computer?

macOS 26.3.1 (Apple Silicon)

What issue are you seeing?

When kimi runs as an ACP server (kimi acp), MCP servers are never connected and their tools are never exposed to the ACP client — the agent only ever has the built-in tools (Agent, Shell, ReadFile, Grep, WriteFile, SearchWeb, FetchURL, …, 17 total). The same MCP configuration works correctly in interactive kimi. The global --mcp-config-file flag also has no effect when the acp subcommand is used.

This breaks MCP for every ACP client (Zed, JetBrains AI Assistant, and multi-agent orchestrators that drive kimi acp over ACP), and is a parity gap vs. interactive kimi and vs. other ACP-native agents whose adapters do surface MCP tools over ACP.

What steps can reproduce the bug?

Using a minimal non-auth, local stdio MCP server (so OAuth/remote auth is not a factor):

1. Create mcp-test.json:

   { "mcpServers": { "fs-test": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"] } } }
   

2. Interactive (works): launch kimi (with this MCP configured) and ask "list every tool available to you." → the filesystem MCP tools (list_directory, read_text_file, …) appear. The log shows:

   kimi_cli.soul.toolset:_connect_server | Connected MCP server: fs-test
   

3. ACP (fails): launch in ACP mode with the same config — kimi --mcp-config-file ./mcp-test.json acp — driven by any ACP client, and from that client prompt "list every tool available to you."
4. Observe: only the 17 built-in tools are returned; no fs-test tools. Re-running with the MCP server defined in the default config instead of --mcp-config-file makes no difference.

Evidence (ACP startup log)

A fresh kimi acp spawn logs no MCP-connection phase at all — note mcp=MCPConfig(client=…) with no servers, the built-ins-only load_tools, and the complete absence of any _connect_server / Connected MCP server line:

kimi_cli.acp:acp_main | Starting ACP server on stdio
kimi_cli.acp.server:initialize | ACP server initialized with client protocol version: 1, negotiated version: ACPVersionSpec(protocol_version=1, spec_tag='v0.10.8', sdk_version='0.8.0')
kimi_cli.app:create | Loaded config: ... mcp=MCPConfig(client=MCPClientConfig(tool_call_timeout_ms=60000)) ...
kimi_cli.soul.toolset:load_tools | Loaded tools: ['kimi_cli.tools.agent:Agent', 'kimi_cli.tools.ask_user:AskUserQuestion', 'kimi_cli.tools.todo:SetTodoList', 'kimi_cli.tools.shell:Shell', 'kimi_cli.tools.background:TaskList', 'kimi_cli.tools.background:TaskOutput', 'kimi_cli.tools.background:TaskStop', 'kimi_cli.tools.file:ReadFile', 'kimi_cli.tools.file:ReadMediaFile', 'kimi_cli.tools.file:Glob', 'kimi_cli.tools.file:Grep', 'kimi_cli.tools.file:WriteFile', 'kimi_cli.tools.file:StrReplaceFile', 'kimi_cli.tools.web:SearchWeb', 'kimi_cli.tools.web:FetchURL', 'kimi_cli.tools.plan:ExitPlanMode', 'kimi_cli.tools.plan.enter:EnterPlanMode']

By contrast, interactive sessions on the same machine and config log kimi_cli.soul.toolset:_connect_server | Connected MCP server: <name> at startup.

Expected behavior

kimi acp should connect configured MCP servers (from --mcp-config-file and/or the default config) and expose their tools to the ACP client — matching interactive kimi and other ACP agents.

Actual behavior

The acp toolset-construction path loads only built-in tools; it never runs the MCP connection step the interactive path runs, and it ignores --mcp-config-file.

Likely root cause (guess)

The ACP new_session / toolset path (kimi_cli.acp.server → kimi_cli.soul.toolset:load_tools) appears to skip the MCP-server connection that the interactive path performs, and the global --mcp-config-file option is not threaded into the acp session setup. Ruled out by elimination: not OAuth (a non-auth local stdio server also fails); not a stale/warm process (a fresh spawn fails identically); no connection is attempted at all, so it is not a connect-then-filter issue.

Impact

ACP clients driving kimi are limited to built-in tools — MCP servers (databases, browsers, internal tooling) configured for kimi are unusable in any IDE/orchestrator that talks to kimi acp. Other ACP-native agents bridge MCP over ACP, so this is a parity/regression gap.

Start by tracing the ACP new_session/toolset path in kimi_cli.acp.server into kimi_cli.soul.toolset:load_tools, then compare it with the interactive startup path and how --mcp-config-file reaches session setup. Done means kimi acp connects configured local MCP servers and exposes their tools to the ACP client, with the startup log showing the connection rather than only the built-in tools.