kimi-swarm-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIAND_API_KEY | Yes | ai& API key used by the Kimi runtime. | |
| KIMI_THINKING | No | Kimi thinking setting. | high |
| KIMI_MODEL_NAME | No | Model served through ai&. Defaults to moonshotai/kimi-k3. | moonshotai/kimi-k3 |
| KIMI_PERMISSION_MODE | No | Kimi permission mode. | auto |
| KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY | No | Maximum concurrent native AgentSwarm workers. This is a cap only; Kimi decides how many workers a task actually needs. | 4 |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kimi_delegate_taskA | Start or submit a Kimi task and return immediately with session and prompt identifiers plus current status. Use this for asynchronous workflows that will later call kimi_wait_until_idle or kimi_get_handoff; use kimi_delegate_and_wait when the result is needed in one call. The delegated task may run commands and modify files in cwd. With swarmMode=true the bridge verifies Kimi swarm mode before submission, but activation alone does not prove native AgentSwarm execution. |
| kimi_delegate_and_waitA | Start a Kimi task, wait for completion or another wait/terminal state, and return handoff and review data in one call. Prefer this for normal delegated work; use kimi_delegate_task when the caller needs immediate asynchronous control. The task may run commands and modify files. With swarmMode=true, structured swarmEvidence reports observed native AgentSwarm calls, worker counts, and coordinator/worker model-provider bindings when Kimi wire evidence is available. |
| kimi_wait_until_idleA | Poll an existing Kimi session until it is idle, times out, requires approval or a question response, is aborted, or fails. Use after kimi_delegate_task or after an earlier wait timed out. This is read-only with respect to session/workspace content and does not abort the job on timeout. Returns the normalized wait status and pending approval/question data when applicable. |
| kimi_get_handoffA | Read the current/final handoff for one Kimi session, including the assistant result, changed files, committed changes, working-tree changes, and Git baseline evidence. Use after a session finishes when the caller needs the actual result or change details; use kimi_review_package for a condensed reviewer-oriented package. This is read-only and does not modify the session or workspace. |
| kimi_review_packageA | Build a read-only review package for one Kimi session by combining its handoff, changed files, Git statistics, and review checklist. Use after delegated implementation work when a reviewer needs concise evidence; if kimi_delegate_and_wait already returned an embedded reviewPackage, prefer that unless a fresh snapshot is needed. This tool does not modify files or session state. |
| kimi_continue_taskA | Submit follow-up instructions to an existing Kimi session while preserving its prior context. Use for corrections, additional work, or recovery after a failed/aborted task instead of creating an unnecessary duplicate session. The continuation may run commands and modify files, and optional model, thinking, and swarm settings are applied before prompt submission. |
| kimi_get_diffA | Read the diff for one file in a Kimi session workspace. Use after kimi_get_handoff or kimi_review_package identifies a changed path and exact patch content is needed. This is read-only; it does not modify the file or session. The path should refer to a file in the target session workspace. |
| kimi_abortA | Abort an existing Kimi session that should no longer continue running. Use only after confirming the target session ID, because this changes session state and can interrupt in-flight commands or delegated work. Treat the action as destructive to the running job even though persisted session history may remain. Returns the session ID and explicit abort confirmation. |
| kimi_bridge_statusA | Check live bridge and private Kimi-runtime readiness, including health/auth status, Kimi backend/version metadata, safe diagnostics, and suggested next actions. Use before delegation or when troubleshooting connectivity and authentication. This is read-only and does not submit an LLM task, start a swarm, expose credentials, or modify the workspace. |
| kimi_recent_sessionsA | List recent Kimi sessions with identifiers, statuses, titles, web links, and workspace metadata. Use to discover an existing job before waiting, reviewing, continuing, aborting, or creating a possible duplicate; use kimi_find_recent_session when a title fragment is known. This is read-only and only queries Kimi session metadata. |
| kimi_find_recent_sessionA | Find recent Kimi sessions whose titles contain a requested substring, optionally constrained by status and working directory. Use for interruption recovery or dedupe when the exact session ID is unknown; prefer session-ID-based tools once a match is known. This is read-only and returns matching candidates plus status-aware next-step guidance without creating or modifying a session. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool targets a distinct step in the Kimi task lifecycle—submit, wait, retrieve, review, continue, abort, and discover—with clear separations like async vs sync delegation and filtered vs unfiltered session listing. No two tools have overlapping purposes that would cause misselection.
All tools follow a consistent kimi_ prefix with snake_case verb_noun or verb_phrase patterns (e.g., delegate_task, get_handoff, wait_until_idle, recent_sessions). The naming is uniform and predictable, making it easy to infer each tool's role.
Eleven tools is well-scoped for a bridge server that must cover lifecycle management (delegate, wait, retrieve, review, continue, abort), session discovery, and status/diff utilities. Each tool earns its place with no redundancy.
The surface covers the full lifecycle end-to-end: submission (async and sync), waiting, retrieving results, reviewing, continuing, aborting, discovering sessions, and checking bridge health. No obvious gaps or dead ends exist for the intended purpose.