ACP server: stdio MCP server without "type" throws "does not declare a runtime identity"

What version of Kimi Code is running?
0.37.2

Which open platform/subscription were you using?

Which model were you using?

What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Running kimi-code acp as an ACP agent from an ACP client (in my case Zed), the agent crashes when the client relays a stdio MCP server (i.e. an entry with no type field, per ACP schema 0.23 convention) through session/new / session/load's mcpServers parameter:

Internal error: {
  "details": "ACP stdio MCP server console_db does not declare a runtime identity"
}

What steps can reproduce the bug?

1. Configure any stdio MCP server on the ACP client side (e.g. Zed context_servers), for example:

   {
     "context_servers": {
       "console_db": {
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://..."],
         "enabled": true,
         "remote": false
       }
     }
   }
   

2. Run kimi-code acp and let the client send this server (no type field — stdio, per ACP schema 0.23) via session/new's (or session/load's) mcpServers param.
3. kimi-code throws Internal error: ACP stdio MCP server <name> does not declare a runtime identity and the session fails to start / resume.

Root cause (found by reading the published bundle, apps/kimi-code, dist/main.mjs): the codebase has two independent ACP mcpServers converters, and only one of them is correct.

• packages/acp-adapter/src/mcp.ts → acpMcpServerToConfig / acpMcpServersToConfigs. Its doc comment states the actual ACP contract correctly:

  Caveat (ACP schema 0.23): the McpServer union types stdio as a bare branch WITHOUT a discriminator... stdio is identified by the ABSENCE of type.

  And its implementation branches on !("type" in server) to build a transport: "stdio" config — correct.

• packages/acp-server/src/mcp.ts → acpMcpServersToConfigRecord, which is what the actual kimi-code acp CLI command uses (registerAcpCommand → runAcpServer → AcpServer, wired through newSession / loadSession / resumeSession). It does the same !("type" in server) check, but instead of treating it as stdio, it throws:

  if (!("type" in server)) throw new Error(`ACP stdio MCP server ${server.name} does not declare a runtime identity`);
  

This is also consistent with the AcpServer's initialize response only declaring mcpCapabilities: { http: true, sse: true } (no stdio flag) — but the error message is confusing since it looks like a client/config problem rather than an unimplemented-transport limitation on the agent side.

What is the expected behavior?

acpMcpServersToConfigRecord (used by the real kimi-code acp command) should handle the type-absent stdio case the same way acpMcpServersToConfigs/acpMcpServerToConfig already do in packages/acp-adapter, instead of throwing. If stdio-over-ACP is intentionally unsupported for now, the agent should at least drop it with a log.warn (like the existing acp transport fallback branch does) instead of throwing and failing the whole session.

Additional information

Workaround: don't declare the same stdio MCP server on the ACP client side (e.g. Zed context_servers); configure it directly in kimi-code's own mcp.json (project-root .mcp.json, project-local .kimi-code/mcp.json, or user-global ~/.kimi-code/mcp.json) instead — that config path doesn't go through the ACP mcpServers relay and isn't affected by this bug.

Start with packages/acp-server/src/mcp.ts and trace acpMcpServersToConfigRecord through registerAcpCommand, runAcpServer, and the session/new and session/load paths. Compare its type-absent handling with packages/acp-adapter/src/mcp.ts. Done means a relayed stdio MCP server no longer causes the ACP session to fail, with unsupported behavior matching the project's intended fallback.