Skip to main content
Glama

Delegate in background (paid)

kimi_delegate_async

Delegate a coding task to Kimi in the background, receive a job ID instantly, and later retrieve the reviewable diff.

Instructions

Delegate a coding task to Kimi in the background and get a job_id back immediately (does not block on the run).

PAID — this spends Kimi quota on every new call; use kimi_delegate_dry_run or kimi_status (both free) first if you only need to check scope or readiness.

Same propose-tier behavior as kimi_delegate — Kimi works in a throwaway git worktree and the result carries a reviewable diff that is NOT applied — but detached; prefer it for a substantial or multi-file implementation task that can exceed the synchronous deadline (built-in default 300s), since a sync run whose deadline expires loses its partial work (this job's own deadline is separately configured, built-in default 1800s). Starting a job commits to spend (it runs to completion or its wall-clock deadline even if you never poll). Poll kimi_job_status; read/consume with kimi_job_result/kimi_job_consume_result; stop with kimi_job_cancel. Requires a git repo with at least one commit; pass workspace_root (absolute).

NETWORK IS NOT BLOCKED: like kimi_delegate, this has no sandbox — a delegated task CAN push, fetch, install dependencies, or call out, running with your own user's privileges. Scope tasks accordingly and review the returned diff before applying it. The Kimi model call also sends your task (raw) to your configured provider and lets Kimi read tracked files in the worktree and send their content.

Kimi auto-loads the resolved workspace's AGENTS.md and discovers skills from its own config (including extra_skill_dirs, which may point outside the workspace).

Secret redaction is best-effort and does not cover your task or the files Kimi reads for itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesThe coding task for Kimi to implement inside a throwaway git worktree; the resulting diff is returned for review, not applied to your tree. Must be non-blank: empty or whitespace-only is rejected before any model call.
modelNoOverride the Kimi model slug for this call; defaults to the server/Kimi default when unset.
isolationNoKimi skills isolation: which skills Kimi loads — 'inherit' (its own user/project discovery) or 'ignore-skills' (replace those with an empty directory). Kimi's built-in skills load either way. Defaults to the server's configured value (built-in 'inherit'; `kimi_status` reports the resolved one).
workspace_rootNoAbsolute path to the target repo root — pass it (or an MCP root) to target the intended repo; otherwise the call falls back to the server's own cwd and sets meta.workspace_warning.
idempotency_keyNoOptional dedup key scoped to THIS tool + workspace. Same key + same args replays the prior result with no new spend; different args are refused (idempotency_conflict). Sync and _async are separate tools and never share a key. Omit for none; retention is bounded. Lifecycle: kimi://params.
reasoning_effortNoOverride the Kimi reasoning effort for this call (a model_reasoning_effort override); omit or pass null for the server default (MOONBRIDGE_REASONING_EFFORT) or Kimi's own resolution. An open, per-model string the backend validates at run time — commonly minimal|low|medium|high|xhigh; kimi_models lists each model's advertised set (advisory). Rejection and bounds detail: kimi://params.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses critical behaviors: it spends Kimi quota and runs to completion even if never polled, has no sandbox (network can be accessed), sends raw task to provider, reads tracked files, auto-loads AGENTS.md, and has best-effort secret redaction. This rich context far exceeds what the annotations alone convey.

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?

The description is lengthy but every sentence carries essential operational or security information. It is well-structured with bolded warnings (PAID, NETWORK IS NOT BLOCKED) and clear sections. Given the tool's complexity, the length is justified; the front-loading of the core purpose and immediate cost warning demonstrates good structuring.

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?

The description covers purpose, cost, behavior, prerequisites (git repo with commit), alternatives, lifecycle, network implications, privacy, and skill loading. Combined with a rich input schema and output schema, it leaves no significant gap for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds value by highlighting that workspace_root must be passed as an absolute path to target the intended repo, warns about the fallback to server cwd, and notes the job's separate deadline (default 1800s). These specifics are not fully explicit in the schema, so a 4 is warranted.

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+resource: 'Delegate a coding task to Kimi in the background and get a job_id back immediately', clearly distinguishing the async behavior from its sync sibling kimi_delegate. It also notes it is 'detached' and produces a reviewable diff that is NOT applied, making the tool's core function unambiguous.

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?

Explicit when-to-use guidance is given: prefer this for substantial or multi-file tasks that may exceed the 300s sync deadline, use kimi_delegate_dry_run or kimi_status if only checking scope/readiness, and use kimi_job_status/result/consume/cancel for lifecycle. It also warns about the paid quota spend, providing clear alternatives and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/briandconnelly/moonbridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server