Skip to main content
Glama

grok_request_async

Destructive

Initiates an xAI Grok CLI request as a durable background job. Poll with llm_job_status, collect results with llm_job_result.

Instructions

Start an xAI Grok CLI request as a durable background job. Poll with llm_job_status, collect with llm_job_result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
denyNoGrok --deny <RULE>: permission deny rules. Each entry → its own --deny instance.
agentNoGrok --agent <NAME>: agent name or definition file path.
allowNoGrok --allow <RULE>: permission allow rules. Each entry → its own --allow instance.
checkNoGrok --check: append a self-verification loop to the prompt (headless only).
modelNoModel name or alias (e.g. grok-build, latest)
oauthNoGrok --oauth: use OAuth during authentication.
rulesNoGrok --rules <RULES>: extra rules to append to the system prompt. Supports `@file` prefix; gateway passes the value verbatim.
agentsNoGrok --agents <JSON>: inline subagent definitions (JSON string or name → { description, prompt, … } map).
effortNoGrok effort level
noPlanNoGrok --no-plan: disable plan mode.
promptNoPrompt text for Grok (mutually exclusive with promptParts)
singleNoGrok --single <PROMPT>: single-turn prompt (in addition to gateway -p).
bestOfNNoGrok --best-of-n <N>: run the task N ways in parallel and pick the best (headless only).
sandboxNoGrok --sandbox <PROFILE>: sandbox profile for filesystem and network access. Freeform per `grok --help` (no enum constraint); also settable via GROK_SANDBOX env var.
maxTurnsNoGrok `--max-turns N`: cap on agent-loop iterations for cost / latency control (Phase 4 slice δ). Bounded to safe integers ≤ 10000.
noMemoryNoGrok --no-memory: disable cross-session memory.
todoGateNoGrok --todo-gate: enable runtime turn-end TodoGate for this session (session-scoped, not persisted).
verbatimNoGrok --verbatim: send the prompt exactly as given. Also skips gateway optimizePrompt when true.
worktreeNoSlice λ: run this request inside a dedicated git worktree owned by the gateway. `true` creates a fresh worktree at `<repoRoot>/.worktrees/<uuid>` branched from HEAD. `{ name?, ref? }` lets the caller supply a sanitized name and/or a git ref (default: HEAD). When the request carries a sessionId and the session already has a worktree, that worktree is reused. The gateway spawns the child CLI with `cwd: <worktree-path>` — no `-w`/`--worktree` flag is ever emitted to the underlying CLI. On session_delete or TTL eviction the gateway runs `git worktree remove --force`. Successful responses are prefixed with `[gateway] worktree=<absolute-path>\n` so callers can use the path. NOTE: callers should `.gitignore` the `.worktrees/` directory in their repo (the gateway does NOT auto-gitignore — see slice λ spec Q4).
sessionIdNoProvider-native session ID to resume (emits --resume <id>; use resumeLatest for --continue). Note: the gw-* id minted for a brand-new session is not resumable via sessionId; continue with resumeLatest:true.
workspaceNoRegistered workspace alias for remote HTTP/OAuth provider calls. Do not use this field, workspace_list, or workspace_register_existing_repo as a fallback for stdio/local provider path access; pass workingDir/addDir/includeDirs directly instead.
jsonSchemaNoGrok 0.2.73 --json-schema: constrain output to a JSON Schema (string literal or object; implies json output). Set outputFormat:json so the gateway treats the reply as structured output (skips response optimization and warning injection); the default output format is not json, so pass it explicitly.
mcpServersNoMCP server names for approval tracking (Grok manages its own MCP config via `grok mcp`)
promptFileNoGrok --prompt-file <PATH>: single-turn prompt loaded from a file.
promptJsonNoGrok --prompt-json <JSON>: single-turn prompt JSON blocks (string or serializable value).
workingDirNoGrok --cwd <DIR>: working directory for this invocation. Lets headless callers run Grok against a directory other than the gateway process's cwd. Stdio/local callers may pass local paths directly. Remote HTTP/OAuth callers must use relative paths inside a selected registered workspace. Do not call workspace_* tools to fix stdio/local provider path access.
forkSessionNoGrok 0.2.73 --fork-session: when resuming (--resume/--continue), fork into a new session ID instead of reusing the original.
noAltScreenNoGrok --no-alt-screen: run inline without alt screen.
noSubagentsNoGrok --no-subagents: disable subagent spawning.
promptPartsNoCache-aware structured prompt: { system?, tools?, context?, task }. Mutually exclusive with prompt. Stable parts hash into cache_state for prefix-discipline tracking.
restoreCodeNoGrok --restore-code: check out the original session commit when resuming.
worktreeRefNoGrok 0.2.73 --worktree-ref <REF>: git ref (branch/tag/commit) to base the native worktree on. Requires nativeWorktree.
allowedToolsNoAllowed built-in tools (passed as --tools comma list)
forceRefreshNoBypass dedup and force a fresh CLI run even if a recent identical request exists
leaderSocketNoGrok 0.2.32+ --leader-socket <PATH>: custom leader socket path (default ~/.grok/leader.sock). Targets an isolated leader process, e.g. a local/branch Grok build; name it ~/.grok/leader-*.sock to keep `grok leader list/kill` discovery working.
outputFormatNoOutput format (plain|json|streaming-json). Grok default is plain.
resumeLatestNoResume most recent Grok session in cwd (--continue). Note: the gw-* id minted for a brand-new session is not resumable via sessionId; continue with resumeLatest:true.
alwaysApproveNoAuto-approve all tool executions (--always-approve)
correlationIdNoRequest trace ID (auto if omitted)
idleTimeoutMsNoIdle timeout in ms (min 30s, max 1h). Omit = gateway default of 600000ms (10 min) with no output before the process is killed.
approvalPolicyNoApproval policy when approvalStrategy is mcp_managed: strict|balanced|permissive (default balanced). Ignored under legacy strategy.
compactionModeNoGrok --compaction-mode: summary (default) | transcript | segments. Sets GROK_COMPACTION_MODE.
nativeWorktreeNoGrok -w/--worktree: native CLI worktree flag (`true` → bare `--worktree`, string → named). NOT gateway slice λ `worktree`.
optimizePromptNoOptimize prompt before execution
permissionModeNoGrok permission mode: default|acceptEdits|auto|dontAsk|bypassPermissions|plan.
disallowedToolsNoDisallowed built-in tools (passed as --disallowed-tools comma list)
reasoningEffortNoReasoning effort for reasoning models
approvalStrategyNoApproval strategy: legacy (default) lets the provider CLI's own flags decide; mcp_managed routes the run through the gateway approval gate (required for approvalPolicy and approval_list). Under mcp_managed the caller's permissionMode/alwaysApprove may be overridden by the gate.legacy
compactionDetailNoGrok --compaction-detail: segment verbatim detail (none|minimal|balanced|verbose, default verbose). Only affects segments mode. Sets GROK_COMPACTION_DETAIL.
compressResponseNoCompress the response display text when collected via llm_job_result (native compressor; default: [compression].enabled).
createNewSessionNoForce new session
disableWebSearchNoGrok --disable-web-search: disable web search and remote retrieval tools.
experimentalMemoryNoGrok --experimental-memory: enable cross-session memory.
systemPromptOverrideNoGrok --system-prompt-override <PROMPT>: replace the agent's system prompt entirely.
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds that it is a 'durable background job', indicating long-running non-blocking behavior. However, it does not disclose what destructive actions occur, authentication needs, or other side effects beyond the annotations.

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?

The description is only two sentences, front-loading the action and providing the essential follow-up steps. Every sentence is informative with no wasted words.

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

Completeness3/5

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

Given the tool's complexity (54 parameters, nested objects, no output schema), the description is minimal. It adequately covers the async lifecycle (start, poll, collect) but does not explain the vast parameter space or output expectations, leaving room for ambiguity.

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 each parameter already has a detailed description. The tool description adds no additional meaning to parameters; it only provides a high-level usage pattern. With baseline 3 for high coverage, no extra value is contributed.

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 clearly states the tool's purpose: initiating a Grok CLI request as a durable background job, with specific verbs ('Start', 'Poll', 'collect') and resource ('xAI Grok CLI request'). It distinguishes itself from synchronous or other tools by outlining the async workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the post-invocation steps ('Poll with llm_job_status, collect with llm_job_result') but lacks explicit guidance on when to use this tool versus alternatives like grok_request (sync) or other async tools. No exclusions or alternative recommendations are provided.

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/verivus-oss/llm-cli-gateway'

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