Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
kimiA

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).

kimi_replyA

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.

kimi_modelsA

List the models this kimi installation has configured right now — read live from kimi provider list --json. Use it to pick a model value for kimi / kimi_reply. Starts no task. This is the configured catalog, not a paid probe of every endpoint.

kimi_sendA

Deliver a message into a kimi turn that is executing right now. The default transport 'acp' keeps the turn reachable; 'print' runs cannot be reached, and a session that already finished takes kimi_reply, not kimi_send. Returns immediately; kimi's reaction appears in the answer of the kimi/kimi_reply call still waiting on that turn. kimi_running lists reachable sessions. Note: the adapter reports the first result envelope; a follow_up queued behind the current turn is delivered but its answer is not awaited by the original call.

kimi_runningA

List kimi turns executing at this moment — the ones kimi_send can reach — with session id, working directory, elapsed time, and messages already sent in. Only acp-transport runs appear; 'print' runs are unreachable mid-run. For past sessions use kimi_sessions.

kimi_sessionsA

List all kimi sessions started through this server, newest first, with their working directory — running or finished, including runs that timed out. Use it to recover an id for kimi_reply. For turns still executing (kimi_send targets), use kimi_running.

kimi_historyA

Read a bounded snapshot of a kimi session's visible conversation from kimi's native agents/main/wire.jsonl. Does not send anything into the run, does not take the session lock, and does not wait for kimi to finish. Returns JSON: session, state (active if this process is running it, otherwise unknown — sessions stay resumable so 'completed' is not claimed), items (user / assistant / tool / gap), an opaque cursor to resume even at the current EOF, has_more, truncated_tail. Thought/reasoning/encrypted content are omitted. User text comes only from context.append_message with role=user — if that stream has none, the page says so rather than inventing prompts from session metadata. Caps: limit (default 50, max 200), max_chars per item (default 4000, max 16000), and 100000 chars on the whole JSON page.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.5/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct phase of the Kimi session lifecycle: start (kimi), resume (kimi_reply), message a running turn (kimi_send), list running (kimi_running), list all (kimi_sessions), read history (kimi_history), and list models (kimi_models). The overlapping pairs (reply/send, running/sessions) are explicitly differentiated by execution state.

Naming Consistency5/5

All tools share the kimi_ prefix with lowercase snake_case names. The only deviation is the root verb `kimi` itself for starting a new session, which is a natural base command; the pattern is otherwise uniform (kimi_ + verb/noun).

Tool Count5/5

Seven tools cover the full lifecycle of orchestrating a Kimi CLI agent: start, resume, send, list running/all, history, and models. This is well-scoped for the server's stated purpose without redundancy.

Completeness4/5

Core session lifecycle is well covered: start, reply, send while running, list running/all, read history, and list models. Missing an explicit cancel/stop operation for running turns, which is a minor gap but likely handled outside the tool surface.

Maintenance

ActivityMaintained
ResponsivenessNo issues