Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-grok-executor Implement the new login API endpoint and run tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that turns Grok CLI into the execution agent for Claude Code.
Claude plans, reviews, and verifies. Grok implements, runs tests, and fixes failures. This server is the bridge: it exposes Grok's headless CLI as a set of MCP tools — including a fully orchestrated execute → verify → auto-fix loop — so the advisor model never has to babysit the executor.
You ──► Claude Code (advisor: plan / review / judge evidence)
│
│ MCP (stdio)
▼
mcp-grok-executor
│ grok -p … --always-approve (subscription OAuth)
▼
Grok CLI (executor: edit files / run tests / fix)
│
▼
your project (cwd)Pairing two models works best with a clear division of labor: a strong reasoning model that owns the design and the acceptance criteria, and a fast execution model that grinds through implementation. Doing that by hand means endless copy-paste. This server makes the loop native to Claude Code:
You approve a plan.
Claude calls run_task with a prompt and a verify_command (e.g. npm test).
The server runs Grok, collects git status + diff, runs your verify command, and — if it fails — automatically sends the failure output back to the same Grok session, up to max_fix_attempts times.
Claude receives a single structured result: every attempt, the diff, the changed files, the verify output. It judges the evidence instead of orchestrating the steps.
Related MCP server: cc-agent
Node.js ≥ 20
Grok CLI on your PATH, logged in via subscription OAuth:
grok login
grok --no-auto-update -p "Say ok." # sanity checkNo XAI_API_KEY needed — auth comes from ~/.grok/auth.json.
Claude Code (or any MCP client that speaks stdio).
git clone https://github.com/emigrete/mcp-grok-executor.git
cd mcp-grok-executor
npm install
npm run buildGlobally (recommended) — available in every project:
claude mcp add --scope user grok -- node /absolute/path/to/mcp-grok-executor/dist/index.jsPer project — drop a .mcp.json in the project root:
{
"mcpServers": {
"grok": {
"command": "node",
"args": ["/absolute/path/to/mcp-grok-executor/dist/index.js"]
}
}
}If the grok binary is not on the PATH Claude Code inherits, add "env": { "GROK_BIN": "/path/to/grok" }.
Tool | Mutates? | Purpose |
| No | Check Grok login ( |
| No | Read-only analysis: Grok runs with write/shell tools disabled |
| Yes | One-shot implementation run ( |
| Yes | Orchestrated loop: execute → git evidence → verify → auto-fix |
| Optional | Follow-up prompt into a previous Grok session |
| No | Poll background jobs, read the live activity log. Job records survive server restarts and are also exposed as MCP resources ( |
| No | Cancel a running background job (kills the whole process tree) |
Every Grok-running tool takes:
prompt (string, required) — self-contained task brief for Grok
cwd (string, required) — absolute path to the target project
model, max_turns, timeout_sec (optional) — per-run overrides
background (optional bool) — return a job_id immediately; poll with task_status
run_task — the orchestrated looprun_task({
prompt: "Fix the failing suite. Don't touch the tests.",
cwd: "/abs/path/to/project",
verify_command: "npm test", // omitted → git evidence only
max_fix_attempts: 2, // default 2; 0 disables auto-fix
verify_timeout_sec: 300 // default 300
})Returns structured evidence:
{
"ok": true,
"status": "completed",
"sessionId": "…",
"totalTokens": 12345,
"attempts": [
{
"type": "execute",
"exitCode": 0,
"summary": "…",
"durationMs": 12314,
"usage": { "numTurns": 3, "totalTokens": 4200 }
}
],
"git": {
"isRepo": true,
"changedFiles": ["src/foo.js"],
"statusAfter": " M src/foo.js\n",
"diff": "diff --git a/src/foo.js …",
"noChanges": false
},
"verify": { "command": "npm test", "ran": true, "exitCode": 0, "output": "…", "attemptsUsed": 1 }
}status is one of completed | failed | needs_advisor:
completed — Grok succeeded and verify passed (or no verify was requested).
failed — Grok or verify failed after retries were exhausted.
needs_advisor — the executor hit a genuinely ambiguous or destructive decision. Nothing is changed; the result includes a question for the advisor. Answer via continue_task with the returned session_id (and your decision in the prompt).
totalTokens (and per-attempt usage) surface cost so the advisor can see how expensive the loop was.
Loop policy:
Auto-retry triggers only on verify_command failure. Each retry continues the same Grok session with the failure output and a fixed instruction to fix the underlying issue (never to weaken or delete tests).
A failed Grok run aborts immediately — there is no verification signal to feed back.
An empty diff never consumes retries; it is reported as git.noChanges: true for the advisor to judge (it may be legitimate).
A verify timeout counts as a failure and enters the fix loop.
ok is true only when Grok succeeded and the final verify passed (or none was requested).
The server runs Grok with --output-format streaming-json and parses the stream as it arrives. Two layers of visibility:
MCP progress notifications — during any synchronous call, Grok's narration ([thought] …, [grok] …) streams into the client's progress UI. In Claude Code you watch it think and act in the tool spinner.
Live job log — every event is appended to the job log in real time. For background jobs, task_status returns the growing feed, or just:
tail -f ~/.cache/mcp-grok-executor/jobs/<job_id>.logACP transport — set MCP_GROK_TRANSPORT=acp to run execute_task / run_task (and fix retries) over grok agent stdio instead of the CLI stream. Visibility upgrades from narration to real tool events: [tool] run_terminal_command — npm test, per-file writes with paths, and status updates as tools complete. review_task, background jobs, and continue_task / recent-session resume still use the CLI transport.
execute_task and run_task return a sessionId. Pass it to continue_task for stateful follow-ups ("now update the changelog", "fix the two remaining test failures") — Grok resumes with full context of what it just did.
Variable | Default | Meaning |
|
| Path to the Grok CLI |
|
| Auth file checked by |
|
| Default timeout per Grok run |
|
| Truncation budget for inline output |
| (CLI default) | Default |
|
| Job records + logs |
|
|
|
| read-only set | Tool allowlist for |
| write/shell set | Tools stripped in |
CLAUDE.md ships the advisor/executor policy for Claude Code: plan first, delegate after approval, prefer run_task with a verify_command, always judge the returned evidence. Copy it (or merge it into your own CLAUDE.md) in projects where you want the full workflow, and optionally install agents/fable-advisor.md into ~/.claude/agents/.
npm run typecheck # tsc --noEmit (includes tests)
npm test # unit tests (node:test + tsx)
npm run build # compile to dist/ (tests excluded)
npm run smoke # build + tests + real grok hello + MCP round-tripThe test suite covers the stream parser, the runner (against a fake grok binary), git evidence, the shell runner, the orchestrator loop policy, and progress-notification throttling.
execute_task and run_task run Grok with --always-approve — treat them like giving an autonomous agent full access to cwd. Gate them behind manual approval in your MCP client; leave review_task/auth_status unrestricted.
Concurrent run_task calls on the same cwd are rejected by a per-cwd lock (avoids two agents fighting over the same tree).
cancel_task kills the whole process tree of the background job, not just the top-level process.
verify_command is arbitrary shell executed in cwd — same trust level as the execution tools. Only pass commands you'd run yourself.
review_task disables Grok's write and shell tools and injects a read-only constraint, but it still runs a model with read access. Spot-check git status if in doubt.
Never add --debug / --debug-file to the Grok invocation: the Grok debug log prints the OAuth bearer token in plaintext.
Job logs under ~/.cache/mcp-grok-executor contain prompts and outputs — don't put secrets in prompts.
ACP for review_task via restricted profiles (tool visibility without write/shell).
Interactive needs_advisor over MCP elicitation (in-band Q&A instead of return-and-continue_task).
Session/load-based continue_task over ACP (resume the same agent session without falling back to CLI).
Check whether Grok CLI is logged in via ~/.grok/auth.json (subscription OAuth). Call this before first use if unsure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the check operates via a local file (~/.grok/auth.json) and clarifies the OAuth type, implying a read-only operation. It could have added detail about return values or failure behavior, but for a simple auth status check, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediate usage guidance. Every word earns its place; there is no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers purpose, usage, and the underlying mechanism. The sibling tools are all task-related, and this auth check is clearly positioned as a prerequisite, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds context by referencing the specific auth file path, which is meaningful even though no parameters exist. There is no schema coverage issue since the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource: whether Grok CLI is logged in via ~/.grok/auth.json. It specifies the exact file path and mentions subscription OAuth, making it easy to distinguish from the sibling task-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this before first use if unsure.' This tells the agent exactly when to invoke this tool, which is especially useful given the sibling tools are all task-related and auth_status is a preliminary check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running background Grok job by job_id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Background job id to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action but does not disclose side effects, reversibility, permission requirements, or behavior for non-existent or completed jobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Cancel', and contains no wasted words. It is concise and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description states the essential action, but it lacks details on return values, error handling, and idempotency. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter job_id, and the description adds minimal extra context ('Grok', 'by job_id') without adding significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Cancel' with the resource 'background Grok job' and the parameter method 'by job_id'. This clearly distinguishes it from sibling tools like run_task or task_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for canceling running jobs but does not explicitly state when not to use it or mention alternatives like task_status for checking status. The word 'running' provides an implied constraint but no formal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the target project working directory | |
| model | No | Optional Grok model id (defaults to CLI / MCP_GROK_MODEL) | |
| mutate | No | If true (default), run as execution with --always-approve. If false, continue in review/read-only mode. | |
| prompt | Yes | Task instructions for Grok (be specific about files, tests, constraints) | |
| max_turns | No | Max agentic turns for Grok | |
| background | No | If true, start Grok in background and return job_id immediately | |
| session_id | No | Session UUID returned by a previous execute_task | |
| timeout_sec | No | Timeout in seconds (default 600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions session continuation but does not disclose whether the tool may execute code with --always-approve (implied by the 'mutate' parameter in the schema), possible destructive effects, or what happens if no session is found. The description omits safety-critical information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and includes an example. Every word earns its place—there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly explains the tool's main purpose and session selection logic, which is the core context needed. However, it fails to mention return values (e.g., job_id when background is true), side effects, or failure modes, which are important given the tool's 8-parameter complexity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by providing an example for the prompt ('fix failing tests') and clarifying the priority of session_id over the most recent session in cwd. This extra semantic guidance justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to continue a previous Grok execution session with a follow-up prompt. The example 'fix failing tests' adds context, and the use of 'continue' distinguishes it from sibling tools like execute_task or run_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool: when continuing a prior session. It explicitly recommends preferring session_id from a prior execute_task and explains the fallback to the most recent session. However, it doesn't explicitly contrast with alternatives like execute_task for new tasks, though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the target project working directory | |
| model | No | Optional Grok model id (defaults to CLI / MCP_GROK_MODEL) | |
| prompt | Yes | Task instructions for Grok (be specific about files, tests, constraints) | |
| max_turns | No | Max agentic turns for Grok | |
| background | No | If true, start Grok in background and return job_id immediately | |
| session_id | No | Optional UUID to create/resume a named Grok session for multi-step work | |
| timeout_sec | No | Timeout in seconds (default 600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It opens with 'MUTATING:', clearly flags side effects, and reveals the 'Uses --always-approve' behavior. It also mentions the scope of actions (file edits, tests, shell) and output (session_id). Missing some details like reversibility, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding distinct value: mutation warning, purpose, usage condition, verification, and output. It is front-loaded with 'MUTATING' and avoids filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no output schema, the description covers approval prerequisites, verification steps, and the returned session_id. It does not elaborate on background execution or timeout behaviors, but the schema covers those. The description is sufficiently complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 7 parameters, so the baseline is 3. The description does not add parameter-specific semantics, but it doesn't need to given schema richness. It mentions the session_id return value, which relates to an output concept, not parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delegate implementation to Grok (file edits, tests, shell)'. It distinguishes itself from siblings by noting it 'Returns session_id for continue_task', implying a handoff workflow. However, it does not explicitly contrast with the sibling run_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: 'Only call after the user approved a plan or explicitly asked to implement'. It also gives post-usage guidance: 'Verify with git diff/tests afterwards'. This is clear, actionable, and addresses when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the target project working directory | |
| model | No | Optional Grok model id (defaults to CLI / MCP_GROK_MODEL) | |
| prompt | Yes | Task instructions for Grok (be specific about files, tests, constraints) | |
| max_turns | No | Max agentic turns for Grok | |
| background | No | If true, start Grok in background and return job_id immediately | |
| timeout_sec | No | Timeout in seconds (default 600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses READ-ONLY status, confirms no file mutations, and specifies that Grok runs without --always-approve and with write/shell tools disabled, providing critical safety expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'READ-ONLY,' and contains no filler. Every clause adds meaningful context, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only review tool with six schema-documented parameters, the description provides the essential behavioral safety context and sibling differentiation. The absence of an output schema is mitigated by schema-documented background/job_id behavior, making the description sufficient and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented in the schema. The description adds no additional parameter-specific detail beyond what the schema provides, thus the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as asking Grok to analyze code, review a plan/diff, or answer questions without mutating files. It explicitly differentiates from execute_task, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to prefer this tool before execute_task, and explains that Grok runs without write/shell tools enabled. This gives clear when-to-use guidance and a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the target project working directory | |
| model | No | Optional Grok model id (defaults to CLI / MCP_GROK_MODEL) | |
| prompt | Yes | Task instructions for Grok (be specific about files, tests, constraints) | |
| max_turns | No | Max agentic turns for Grok | |
| background | No | If true, start Grok in background and return job_id immediately | |
| session_id | No | Optional UUID to create/resume a named Grok session | |
| timeout_sec | No | Timeout in seconds (default 600) | |
| verify_command | No | Shell command run in cwd after execution (e.g. 'npm test'). Omitted → git evidence only. | |
| max_fix_attempts | No | Auto-fix rounds when verify_command fails (default 2; 0 disables) | |
| verify_timeout_sec | No | Timeout in seconds for each verify_command run (default 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It clearly labels the tool as 'MUTATING', discloses the approval requirement, describes the server-side orchestration loop, and explains side effects on sub-processes via cancel_task. It also states the structured return content, giving the agent a clear picture of what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence is purposeful: it states the core loop, the approval requirement, the preferred alternative, the needs_advisor handling, and the cancel behavior. It front-loads the most important identifiers ('ORCHESTRATED + MUTATING') and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex tool with 10 parameters, no output schema, and no annotations, the description nevertheless covers the workflow, approval constraints, conditional branching via status, and alternative tool selection. It is complete enough for an agent to decide when to invoke it and how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description adds workflow-level meaning by explaining how verify_command relates to the auto-fix loop and how session_id is used with continue_task. This connects parameters to the overall flow, exceeding the baseline without needing to repeat schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'run a full execute → git-evidence → verify → auto-fix loop server-side and return structured evidence.' It clearly distinguishes the tool from execute_task while listing concrete outputs (attempts, changed files, diff, verify output). This goes well beyond a generic 'runs a task' statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Prefer this over execute_task when a test/build command can verify the work.' It also states the same approval bar as execute_task, specifies how to handle 'needs_advisor' via continue_task, and notes cancel_task aborts in-flight sub-processes. This is model guidance, not just a hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a background job started with background=true, or list recent jobs if job_id is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | Job id returned by execute_task/review_task with background=true | |
| include_log | No | Include truncated log tail (default true when job_id set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. 'Poll' and 'list' strongly imply read-only operations, and the description adds context about background jobs. However, it doesn't explicitly state non-modification or error behavior, though implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose and conditional usage. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return format and edge cases. It explains the two modes but lacks response structure, pagination details, and error behavior, which are notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both job_id and include_log are already described in the schema. The description adds no extra parameter semantics beyond referencing background=true, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls a background job started with background=true or lists recent jobs when job_id is omitted. This specific verb+resource+scope distinguishes it from sibling tools like execute_task and cancel_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: for background jobs started with background=true, and explains behavior when job_id is omitted. It doesn't mention alternatives or when not to use, but the context is clear enough given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0auth_statuscancel_taskcontinue_taskexecute_taskreview_taskrun_tasktask_statusMost 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for Grok Imagine AI video generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/emigrete/mcp-grok-executor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
