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 continue a Kimi task and return immediately. Use this for long-running or asynchronous work where the caller should receive identifiers before completion. Returns a durable jobId when durable jobs are configured, plus sessionId, promptId, status, and webUrl. After a disconnect or client timeout, recover with kimi_recent_jobs, then use kimi_wait_until_idle and kimi_get_handoff instead of submitting a duplicate prompt. The task may execute commands and modify files in cwd. With swarmMode=true the bridge verifies Kimi swarm mode before submission; final AgentSwarm execution evidence is available from the handoff. Also consider it when the user did not mention Kimi: if part of a request is substantial (would take you several minutes, e.g. researching or comparing many items, reading many documents, building a report or file) and independent of the rest, offer to hand that part to Kimi so it runs while you do the rest; ask first unless kimi_swarm_settings shows offerKimi auto (off: only when asked). If the user agrees, send a self-contained brief here first, then do your part. |
| kimi_delegate_and_waitA | Start a Kimi task and wait until it becomes idle, blocked, failed, aborted, or the caller wait times out. Use this when the caller can remain connected for the expected task duration; prefer kimi_delegate_task for long-running work so the durable jobId is returned immediately. When durable jobs are configured, the result includes jobId. Idle results include handoff and review data; timeout does not abort the underlying Kimi session. After a client-side timeout or disconnect, use kimi_recent_jobs to recover the existing job rather than submitting the task again. |
| kimi_wait_until_idleA | Poll an owned Kimi session until it is idle, awaiting approval, awaiting a question, failed, aborted, or the caller wait times out. Use the sessionId returned by delegation or recovered through kimi_recent_jobs. Returns normalized status and pending approval/question data when applicable. A timeout only ends this wait attempt; it does not abort the Kimi session or mark the durable job timed out. This tool does not modify workspace content. |
| kimi_get_handoffA | Read the current or final handoff for an owned Kimi session. Use after kimi_wait_until_idle reports idle, or directly during recovery when the authoritative Kimi status and result need to be refreshed. Returns the assistant result, changed files, committed and working-tree changes, Git baseline evidence, and a fresh structured swarmEvidence snapshot. When durable jobs are configured, the bridge reconciles the durable status and caches the returned handoff. This tool does not submit another prompt or modify workspace content. |
| kimi_review_packageA | Build a reviewer-oriented snapshot for an owned Kimi session from its handoff, changed files, Git statistics, and review checklist. Use after delegated implementation work when concise review evidence is needed, or when a fresh review snapshot is required after recovery. If kimi_delegate_and_wait already returned reviewPackage, reuse that unless newer evidence is needed. When durable jobs are configured, the package is cached in the job registry. This tool does not modify the session or workspace. |
| kimi_continue_taskA | Submit follow-up instructions to an owned existing Kimi session while preserving prior context. Use for corrections, additional work, or deliberate continuation of a recovered job instead of creating a duplicate session. Returns the new promptId and running status; when durable jobs are configured, the registry is updated to the new prompt and running state. The continuation may execute commands and modify files, and optional model, thinking, and swarm settings apply to the new prompt. |
| kimi_get_diffA | Read the diff for one file in an owned Kimi session workspace. Use after kimi_get_handoff or kimi_review_package identifies a changed path and exact patch content is needed. Returns the requested path and diff content. This tool is read-only and does not modify the file, session, or durable job state. |
| kimi_abortA | Abort an owned Kimi session that should no longer continue running. Use only after confirming the intended session because this interrupts in-flight delegated work and changes session state. When durable jobs are configured, a successful abort is persisted as aborted. Returns the sessionId and explicit abort confirmation. Session history may remain available after the abort. |
| kimi_bridge_statusA | Check bridge and private Kimi-runtime readiness without submitting an LLM task. Use before delegation or when diagnosing connectivity, authentication, backend, or runtime problems. Returns health and auth status, safe Kimi backend/version metadata, diagnostics, and suggested next actions. It does not start a session, run AgentSwarm, expose credentials, or modify workspace content. |
| kimi_recent_jobsA | List recent connector-owned durable jobs from the persistent bridge registry. Use this first after a client timeout, disconnect, bridge restart, or lost response to recover the existing jobId and bound Kimi sessionId without guessing or submitting a duplicate task. Returns status, prompt/session identifiers, workspace, swarm mode, cached result or error data, and timestamps. It does not contact Kimi, so registry recovery remains available when the Kimi runtime is temporarily unavailable. This tool is read-only. |
| kimi_recent_sessionsA | List recent raw Kimi sessions with identifiers, statuses, titles, web links, and workspace metadata. Use this as a discovery fallback when durable job recovery is unavailable; when durable jobs are configured, prefer kimi_recent_jobs because it is connector-owned and persistent. Raw session discovery is not authorization: session-oriented tools still enforce durable ownership when configured. This tool only queries Kimi session metadata. |
| kimi_find_recent_sessionA | Find raw Kimi sessions whose titles contain a requested substring, optionally filtered by status and working directory. Use this only when the exact session is unknown and durable recovery through kimi_recent_jobs is unavailable or insufficient. Once a session is identified, prefer sessionId-based tools. Discovery does not grant ownership; session-oriented tools still enforce durable ownership when configured. This tool does not create or modify a session. |
| kimi_swarm_settingsA | Show or change how many AgentSwarm workers Kimi may use per task. maxAgents is a ceiling: Kimi still decides how many workers each task needs and uses fewer for small tasks. Call with maxAgents when the user asks to raise or lower the agent limit (for example "increase the limit to 20"); call with no arguments to report the current settings. Values above the deployment cap are reduced to the cap. The response also reports concurrency, the number of workers that run at the same time (set by the deployment admin); extra workers queue, which keeps simultaneous ai& requests bounded, and Kimi backs off automatically if ai& rate-limits. offerKimi is the user's preference for Kimi taking independent parts of requests they did not send to Kimi: ask (default: offer and wait for a yes), auto (hand them over and say so) or off (only when the user asks for Kimi); read it before your first offer in a conversation, and save it when the user says to always do it or to stop asking. |
| kimi_model_settingsA | Show or change which ai& models Kimi uses. The coordinator plans the task, delegates to AgentSwarm workers and writes the result; the workers do the parallel work, and most of a swarm's tokens are theirs, so a cheaper worker model cuts cost the most. Call with no arguments to list the available models with prices (USD per million tokens) and the current choice. Call with coordinatorModel and/or workerModel (model ids from the list) when the user asks to switch models; use "default" to return the coordinator to the deployment default and "same" to make workers use the coordinator model. Changes apply to tasks started afterwards; the setting is per user and persists. |
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 14 tools
Tools have largely distinct purposes, but there is some overlap between discovery tools (kimi_find_recent_session vs kimi_recent_sessions) and between delegation variants (kimi_delegate_task vs kimi_delegate_and_wait). The descriptions clarify the differences and intended usage, so selection should be reliable with careful reading.
All tool names follow the consistent 'kimi_' prefix + snake_case verb_noun pattern, such as kimi_delegate_task, kimi_get_handoff, and kimi_swarm_settings. No mixed conventions or inconsistent verb styles are present.
With 14 tools, the server is well-scoped for its bridge role, covering status, delegation, monitoring, recovery, settings, and finalization. Each tool serves a distinct operational need without redundancy or bloat.
The surface covers the full lifecycle of delegating to Kimi: check readiness, delegate (async/sync), wait, retrieve handoff, review, recover after disconnect, continue, and abort. Minor gaps like a separate 'list all sessions with filtering' beyond the raw find are mitigated by kimi_recent_jobs and kimi_recent_sessions.