How do I use kimi-acp-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kimi-acp-mcp ask Kimi to write a Python script and run it" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kimi-acp-mcp

by TuTouPower

Overview Schema Source Related Servers Discussions Admin

TypeScript

kimi-acp-mcp

License: MIT GitHub

把 Claude Code 通过 MCP 接到本机已登录的 Kimi Code 的桥，走 Moonshot 官方 kimi acp ACP 协议，非逆向。让 Claude Code 把子任务委派给 Kimi 在指定 cwd 自主干活（读写文件、跑命令、多步推理）。

架构

Claude Code (MCP client)
    │ MCP / stdio
    ▼
kimi-acp-mcp (本项目)
    ├─ MCP server  ← 暴露工具：kimi_prompt / kimi_status / kimi_sessions
    └─ ACP client  ← 长驻子进程 spawn `kimi acp`
        │ ACP / stdio
        ▼
    Kimi K2.7 Code (256K 上下文)

完整设计见 docs/blueprint/architecture.md。

Related MCP server: Kimi MCP Server

前置

Node ≥ 18
本机已装 Kimi Code CLI 并完成 kimi login（验证：kimi --version 返回版本号）

安装与构建

cd ~/karson_ubuntu/kimi-acp-mcp
npm install
npm run build

配置到 Claude Code

Claude Code 的 MCP 配置在 ~/.claude.json（user scope）或项目根 .mcp.json（project scope），不是 ~/.claude/settings.json。推荐用 claude mcp add CLI（user scope，全局可用）：

claude mcp add kimi-acp \
  -e KIMI_BIN=/home/<user>/.kimi-code/bin/kimi \
  -e KIMI_ACP_PERMISSION=readwrite \
  -- node /home/<user>/kimi-acp-mcp/dist/index.js

或在项目根建 .mcp.json：

{
  "mcpServers": {
    "kimi-acp": {
      "command": "node",
      "args": ["/home/<user>/kimi-acp-mcp/dist/index.js"],
      "env": {
        "KIMI_BIN": "/home/<user>/.kimi-code/bin/kimi",
        "KIMI_ACP_PERMISSION": "readwrite"
      }
    }
  }
}

KIMI_BIN 可省略（默认从 PATH 找 kimi）。KIMI_ACP_PERMISSION 可选 readonly / readwrite。

重启 Claude Code 后，/mcp 应能看到 kimi-acp。

详细配置、env 说明、故障排查见 docs/guides/claude-code-setup.md。

配置到 opencode

opencode 1.17+ 也支持，配置位置和键名与 Claude Code 不同：

opencode mcp add kimi-acp \
  --env KIMI_BIN=/home/<user>/.kimi-code/bin/kimi \
  --env KIMI_ACP_PERMISSION=readwrite \
  -- node /home/<user>/kimi-acp-mcp/dist/index.js

写入 ~/.config/opencode/opencode.json 的 mcp 字段。验证：opencode mcp list 应显示 kimi-acp ✓ connected。工具调用以 kimi-acp_kimi_prompt 暴露。

opencode 详细配置（含 Claude Code 与 opencode 格式差异表）见 guide。

测试

npm test                   # 单元 + 集成（默认排除 e2e）
KIMI_ACP_E2E=1 npm test    # e2e（需本机 kimi 已 kimi login；真实消耗 Kimi 配额）

e2e 会真实 spawn kimi acp，让 Kimi 在临时 cwd 创建文件验证全链路。已在本机验证通过。

文档入口

Agent 工作规则：AGENTS.md
架构：docs/blueprint/architecture.md
Claude Code 配置详细：docs/guides/claude-code-setup.md

License

MIT

Available Tools

2 tools

kimi_sessionsA

列出桥本地维护的 session（按 newSession/loadSession 顺序），非 ACP session/list。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It indicates the ordering (by newSession/loadSession order) and scope (local bridge sessions), but does not disclose if the operation is read-only, idempotent, or any potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words, efficiently conveying the purpose, scope, and ordering.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and one sibling, the description is fairly complete. It specifies what is listed and the ordering, though it lacks details on output format or limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since there are zero parameters, the schema coverage is 100%. The description adds value beyond the schema by clarifying what sessions are listed and their ordering, meeting the baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'sessions maintained locally by the bridge', and distinguishes itself from ACP session/list, indicating a specific and unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is not ACP session/list, implying a distinction, but does not provide explicit guidance on when to use this tool versus the sibling kimi_status or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kimi_statusA

检查 Kimi ACP 子进程与握手状态、活跃 session 数。不消耗 Kimi 配额。返回 {rows: [{label, ok, detail}]} 结构，便于 host 程序化解析。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It explicitly states no quota consumption and specifies the return structure. This gives a fairly good behavioral picture without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences: the first announces the purpose, the second adds behavioral context and return structure. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explicitly provides the return structure, which is helpful for programmatic parsing. However, it does not explain the fields 'label, ok, detail' in detail. Overall sufficient for a zero-parameter status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is trivially 100%. Per guidelines, baseline is 4 for zero parameters. The description adds no parameter info since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks subprocess and handshake status and active session count. It is specific about what it does, though it does not explicitly differentiate from the sibling tool 'kimi_sessions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it does not consume quota, implying safe use, but provides no guidance on when to use this tool versus 'kimi_sessions'. No exclusions or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Jul 22, 2026
- First observedkimi_sessions
- First observedkimi_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-22 05:08 across 2 tools

Disambiguation5/5

The two tools serve entirely different purposes: one lists sessions, the other checks status. There is no overlap in functionality.

Naming Consistency4/5

Both tools share the 'kimi_' prefix and follow a noun pattern ('sessions', 'status'), which is consistent. However, the lack of a verb-noun pattern is a minor deviation.

Tool Count2/5

With only 2 tools, the server feels too thin for its apparent domain of session management, which typically requires more operations.

Completeness2/5

The server provides listing and status checking but lacks essential operations like creating, loading, or deleting sessions, leaving significant gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
opchain A
io.github.asfbay-bit
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Developer Tools CI/CD & DevOps Project Management
2
Great ArrowOAuth
ai.greatarrow
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Knowledge & Memory
1
toolweaveOAuth
io.github.andreysparish
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
App Automation AI & Machine Learning Agent Orchestration
2

Related MCP Servers

Herald
kOlapsis
A
license
Not graded
quality
F
maintenance
The self-hosted MCP bridge between Claude Chat and Claude Code.
Updated 3 months ago (2026-06-09 11:54 UTC)
46
AGPL 3.0
Kimi MCP Server
Developer Tools Code Analysis
MichaelCecil
A
license
Not graded
quality
D
maintenance
An MCP bridge that enables Claude Code to consult the Kimi AI model in a structured challenge-loop for code review, debugging, and architecture evaluation.
Updated 5 months ago (2026-04-11 03:52 UTC)
18 npm
2
MIT
harness-bridge
rbutera
A
license
A
quality
A
maintenance
Bridges Claude Code and OpenAI Codex through MCP, allowing cross-harness querying, code review, explanation, and implementation delegation.
Updated a month ago (2026-08-27 23:10 UTC)
6
6 npm
1
MIT
devin-mcp-bridge
Agent Orchestration Autonomous Agents
phenasdev
A
license
A
quality
B
maintenance
Bridges MCP (Claude Code) to ACP (Devin), enabling Claude Code to delegate autonomous tasks to Devin with permission and filesystem sandbox controls.
Updated 2 months ago (2026-07-29 03:41 UTC)
2
MIT

kimi-acp-mcp

架构

前置

安装与构建

配置到 Claude Code

配置到 opencode

测试

文档入口

License

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Herald

Kimi MCP Server

harness-bridge

devin-mcp-bridge