Skip to main content
Glama

grok_delegate_start

Start a coding task in the background and receive a job ID immediately, avoiding client timeout on long-running lanes. Poll the job later to retrieve results.

Instructions

Start grok_delegate in the BACKGROUND and return a job_id immediately. Use this instead of grok_delegate for real lanes: a lane runs for minutes and a synchronous call is killed by the client timeout, leaving an empty worktree. Poll with grok_delegate_poll. Same guarded profile, no push, no merge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoProject directory to work in; must be an allowlisted root
goalYesCoding goal for the executor
laneYesLane slug or grok/<slug> (not dev/master/main)
modelNoOptional model id
rulesNoOptional extra rules appended to system prompt (bounded)
resumeNoResume session: true for most recent, or a session UUID string
sandboxNoOptional sandbox profile override: off|workspace|devbox|read-only|strict (known built-ins only)
base_refNoGit base ref (default origin/dev)origin/dev
max_turnsNoMax agent turns (server hard-capped at 60)
plan_onlyNoIf true, use read-only permission profile
repo_rootNoAbsolute path to a repo root; accepted only if it resolve()s to an entry on GROK_DELEGATE_ALLOWED_ROOTS (or single GROK_DELEGATE_REPO_ROOT pin)
session_idNoUUID for --session-id (new or forked session name)
json_schemaNoOptional JSON Schema object/string for structured output
fork_sessionNoPass --fork-session (requires resume/continue)
lane_verdictNoAttach the lane verdict schema (default true). The run ends when the executor emits that object, so on a goal it must read the codebase to start, it emits one describing intent and the lane closes empty. Set false for exploration-heavy goals: the executor then works to natural completion and reports prose in summary instead of a parsed verdict.
lanes_parentNoOptional parent dir for worktrees; rejected if inside repo_root or outside GROK_DELEGATE_LANES_PARENT when that env is set
no_subagentsNoIf true, pass --no-subagents
continue_sessionNoPass --continue (most recent for cwd)
reasoning_effortNoOptional reasoning effort (low|medium|high|…)
disable_web_searchNoIf true, pass --disable-web-search
Install Server

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses genuinely useful behavior: background execution, immediate job_id return, long-running lanes, and a guarded profile with 'no push, no merge.' Gaps remain around failure behavior and job cleanup, but for an async-start tool this is above-average disclosure.

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?

Four compact sentences, each earning its place: purpose, why this variant exists, how to consume the result, and the safety profile. The purpose is front-loaded and there is zero redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 20-parameter tool with no annotations and no output schema, the description covers the essential lifecycle: it starts a job, returns a job_id, and directs the agent to poll. It does not describe error responses or cancellation, but the key contract (start → job_id → poll) is fully stated.

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%, so the baseline of 3 applies. The description does not add parameter-level detail beyond the schema, but it doesn't need to — the schema already documents all 20 parameters in depth (e.g., lane_verdict and repo_root have rich 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?

The description opens with a specific verb-resource-mode: 'Start grok_delegate in the BACKGROUND and return a job_id immediately.' It differentiates from the sibling grok_delegate, and the mention of a job_id makes the async contract unmistakable.

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?

It states an explicit when-to-use condition: 'Use this instead of grok_delegate for real lanes', explains why (the synchronous call is killed by client timeout, leaving an empty worktree), and names the follow-up tool to poll with (grok_delegate_poll). This is exemplary routing guidance.

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/zai-one/grok-build-mcp'

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