Skip to main content
Glama
minmax

kimi-cli-mcp

by minmax
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kimi_reply

Destructive

Send a follow-up message to an existing, non-running Kimi session, even after timeout or cancellation, to resume with prior context intact.

Instructions

Send a new turn to an existing kimi session that is not executing right now — including one that timed out or was cancelled: the session survives in kimi's own store, so resume it here instead of restarting with kimi. kimi still has its prior turns (but never this conversation), so the follow-up can be short. Survives restarts of this server. For a turn still running under 'acp', use kimi_send instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoAbsolute path override. Defaults to the directory where the session started.
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.
promptYesFollow-up message for this session.
sessionYesSession id from a [session: <id>] prefix, or from kimi_sessions.
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

A5/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true and readOnlyHint=false, and the description adds substantial context beyond that: session survival in kimi's store, persistence across server restarts, that kimi retains prior turns but never this conversation, and that a timeout-killed run is resumable. It also explains the difference in reachability between transport modes. No contradiction with annotations.

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 four tightly packed sentences. The core purpose is front-loaded, then it adds session persistence, follow-up brevity, and sibling routing. No filler; every clause earns its place.

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

Completeness5/5

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

For a 9-parameter tool with no output schema, the description covers the essential behavioral dimensions: when to use, what happens on timeout, session longevity, transport trade-offs, and routing. It even hints at the return (session id) and missing conversation context. Nothing an agent needs to decide correctly is omitted.

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

Parameters5/5

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

Schema coverage is 100%, yet the description enriches several parameters: it explains session ID sources, why transport should usually be omitted and the reachability difference, timeout override guidance including resumability, and approval_mode headless implications. This goes well beyond the schema's own descriptions.

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 uses a specific verb ('Send a new turn') and names the exact resource ('existing kimi session that is not executing right now'). It explicitly distinguishes itself from kimi_send and kimi, and even includes edge cases like timed-out or cancelled sessions. This fully separates it from all six siblings.

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 states precisely when to use this tool versus alternatives: 'For a turn still running under acp, use kimi_send instead' and 'resume it here instead of restarting with kimi'. This is explicit routing with a clear condition, leaving nothing to inference.

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