mcp-grok-executor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GROK_BIN | No | Path to the Grok CLI | grok |
| GROK_AUTH_PATH | No | Auth file checked by auth_status | ~/.grok/auth.json |
| MCP_GROK_MODEL | No | Default -m passed to Grok (CLI default) | |
| MCP_GROK_CACHE_DIR | No | Job records + logs | ~/.cache/mcp-grok-executor |
| MCP_GROK_TRANSPORT | No | cli (default) or acp (experimental) | cli |
| MCP_GROK_TIMEOUT_SEC | No | Default timeout per Grok run | 600 |
| MCP_GROK_REVIEW_TOOLS | No | Tool allowlist for review_task (read-only set) | |
| MCP_GROK_MAX_OUTPUT_CHARS | No | Truncation budget for inline output | 80000 |
| MCP_GROK_REVIEW_DISALLOWED | No | Tools stripped in review_task (write/shell set) |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| auth_statusA | Check whether Grok CLI is logged in via ~/.grok/auth.json (subscription OAuth). Call this before first use if unsure. |
| review_taskA | READ-ONLY: Ask Grok to analyze code, review a plan/diff, or answer questions without mutating files. Prefer this before execute_task. Grok runs without --always-approve and with write/shell tools disabled. |
| execute_taskA | MUTATING: Delegate implementation to Grok (file edits, tests, shell). Uses --always-approve. Only call after the user approved a plan or explicitly asked to implement. Verify with git diff/tests afterwards. Returns session_id for continue_task. |
| continue_taskA | Continue a previous Grok execution session with a follow-up prompt (e.g. fix failing tests). Prefer session_id from a prior execute_task; otherwise continues the most recent session in cwd. |
| run_taskA | ORCHESTRATED + MUTATING: run a full execute → git-evidence → verify → auto-fix loop server-side and return structured evidence (attempts, changed files, diff, verify output). Same approval bar as execute_task: only after the user approved a plan. Prefer this over execute_task when a test/build command can verify the work. If the result has status 'needs_advisor', answer the question via continue_task with the returned session_id. cancel_task also aborts in-flight grok sub-processes. |
| task_statusA | Poll a background job started with background=true, or list recent jobs if job_id is omitted. |
| cancel_taskA | Cancel a running background Grok job by job_id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| recent-jobs | Last 20 grok job records (newest first) |
TDQS
Scored across 7 tools
Most tools are clearly distinct: auth_status for login, task_status for monitoring, review_task for read-only analysis, execute_task and run_task for mutating work, continue_task for follow-ups, and cancel_task for aborting. The primary ambiguity is between execute_task and run_task, which both delegate implementation to Grok, though the descriptions clarify when to prefer each.
All tools use lowercase_with_underscores and are two-word phrases, but there's a slight inconsistency in suffixes: five tools end in '_task' while two end in '_status'. The pattern is otherwise highly predictable, with verb-led names for actions and noun-led names for status queries, so the deviation is minor.
Seven tools is well-scoped for a Grok executor server. Each tool serves a distinct function in the workflow of delegating tasks, monitoring them, and managing sessions, without feeling bloated or sparse.
The domain of delegating implementation tasks to Grok is well covered: auth check, read-only review, mutating execution (both one-shot and orchestrated), continuation, status polling, and cancellation. A minor gap is the lack of an explicit tool to retrieve full output of a completed job, though task_status may partially address this.