Skip to main content
Glama
minmax

kimi-cli-mcp

by minmax
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kimi

Destructive

Start a coding task in an isolated CLI agent that edits files and runs shell commands, then returns the final result with a session ID for later continuation.

Instructions

Start a NEW task in the local Kimi Code agent — a separate CLI coding agent with its own file/shell tools and its own context window. Blocks until kimi settles, then returns only its final result plus stats, prefixed [session: ]; continue that session later with kimi_reply. Good for: a second opinion from a different model, work kept out of this context, or parallel investigation. Caution: with approval_mode 'yolo' (the server default, ACP) kimi edits files and runs shell commands as your user inside cwd without asking. Print mode also executes tools without confirmation (and forbids combining -p with -y).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoUsually omit to use this server's cwd. If set, must be an absolute path (relative is rejected). kimi works and edits here, and reads AGENTS.md / project rules from here.
modelNoModel alias as configured in kimi, e.g. 'kimi-code/k3' or 'stepfun-high/step-3.7-flash'. Defaults to kimi's own default_model. kimi_models lists what this install has configured.
promptYesThe complete task. kimi cannot see this conversation, so include everything it needs: file paths, goal, constraints, expected output format.
add_dirsNoComma-separated extra workspace directories passed as kimi --add-dir (print) or ACP additionalDirectories (acp). Each path must be absolute.
thinkingNoACP thinking config (`session/set_config_option` id=thinking). Print transport has no thinking flag — kimi has no CLI --effort; pick a model alias instead.
transportNoUsually omit. The default 'acp' keeps kimi up (`kimi acp`) so a running turn can be steered or aborted with kimi_send. 'print' is kimi -p --output-format stream-json: one process per turn that cannot be reached while it works. -p is last (greedy).
timeout_msNoUsually omit — the server default is generous. Override only when the task's real size demands it. A run killed at the deadline is not lost: it still returns its session id and is resumable with kimi_reply.
approval_modeNoACP session mode: 'yolo' (auto-approve everything), 'auto' (auto-approve safe ops), 'default' (ask — unusable headless), 'plan' (read-only). Server default is yolo. Print transport cannot take -y/--auto/--plan with -p (the CLI rejects that); prompt mode already executes tools without confirmation, and 'plan' is rejected on print.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true), it discloses that with 'yolo' approval mode kimi edits files and runs shell commands as the user, that print mode executes without confirmation, that it blocks until settling, and that interrupted runs preserve a resumable session id. This significantly extends the structured annotations without contradiction.

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

Conciseness4/5

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

Structured into purpose, usage, and caution paragraphs with no filler—each sentence conveys an important fact or constraint. It is somewhat long, but that length is reasonable given the tool can mutate the local machine and has 8 configurable parameters.

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?

With no output schema, it sensibly tells the agent what to expect ('only its final result plus stats, prefixed session id') and covers resumability, blocking, cwd scope, and destructive behavior. It does not spell out the exact structure of the result/stats, but the remaining gap is minor for evaluating outcomes.

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

Parameters3/5

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

The schema already covers all 8 parameters with detailed, 100% coverage. The description reinforces certain parameters (e.g., cwd's workspace scope, approval_mode's yolo hazard, timeouts not losing sessions) but adds little meaning beyond the schema's existing text, so the baseline of 3 applies.

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 opens with a specific verb and resource ('Start a NEW task in the local Kimi Code agent') and clearly identifies it as separate from the current conversation, naming kimi_reply for continuation. This makes it easy to distinguish from the six sibling tools.

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

Usage Guidelines5/5

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

It explicitly lists when to use it ('Good for: a second opinion, work kept out of this context, parallel investigation') and points to kimi_reply as the continuation path, effectively stating when not to use this tool. It also gives practical guidance on optional parameters ('Usually omit').

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

Deploy Server

Other Tools