Skip to main content
Glama

Delegate in background (paid)

kimi_delegate_async

Delegate a coding task to Kimi in the background, get a job ID immediately, then poll for a reviewable diff that is not applied to your tree—ideal when a task may exceed synchronous deadlines.

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.
isolationNoWhich skills Kimi loads: 'inherit' (own user/project discovery) or 'ignore-skills' (empty dir). Built-ins load either way; this reduces loading, not isolation. Default: server-configured, per kimi_status. More: kimi://params.
workspace_rootNoAbsolute path to the target repo root — pass it to target the intended repo (MCP roots are unavailable); 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
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses far more than annotations could: it is paid, spends quota on every new call, runs without a sandbox, can push/fetch/install with user privileges, sends the raw task to the provider, reads tracked files, auto-loads AGENTS.md, and only best-effort redacts secrets. It also explains that the job runs to completion or its deadline even if never polled. No contradiction with annotations exists.

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?

Despite being long, every sentence earns its place: purpose is front-loaded, then cost, sync-vs-async tradeoff, lifecycle, requirements, network risk, data handling, and redaction limits. The paragraph structure uses bold semantic labels and makes the critical operational and safety facts scannable without fluff.

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?

Given that this is a paid, asynchronous, side-effectful operation, the description is operationally complete. It covers what is returned (job_id), how the result is delivered (reviewable diff not applied), how to poll/consume/cancel, prerequisites (git repo with at least one commit), deadlines, sandbox absence, and data exposure. An output schema exists, so return-value details are not the description's burden.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter is already well-documented in the schema. The description reinforces key usage points such as passing an absolute workspace_root and using idempotency_key to replay without new spend, but it does not add substantial new parameter-level meaning 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?

Opens with a specific verb-plus-resource statement: 'Delegate a coding task to Kimi in the background and get a job_id back immediately.' It clearly separates this from kimi_delegate (sync) and explicitly names related sibling tools for follow-up, so an agent can distinguish it without opening schemas.

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?

Gives explicit when-to-use guidance: prefer this for substantial/multi-file tasks that may exceed the 300s sync deadline, and use free tools (kimi_delegate_dry_run, kimi_status) first for scope/readiness checks. It also names the companion tools for polling, consuming, and canceling, leaving no ambiguity about the operational workflow.

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

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