grok-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GC_DEBUG | No | Enable debug mode (e.g., 'true' or 'false') | false |
| GC_COMPACT | No | Compact handoff mode: short stdout + handoff path | |
| GC_DEBUG_GUI | No | Open a native pywebview debug window | |
| GC_LOG_DEBUG | No | Enable full subprocess debug logging | |
| GC_REPO_ROOT | Yes | Path to the grok-and-claude checkout that has bin/ and .team/ | |
| GC_DEBUG_OPEN | No | Never open browser (set to '0' to disable) | |
| GC_SIGINT_MODE | No | SIGINT handling: 'cancel' or 'cancel_then_exit' | cancel |
| GC_DEBUG_WINDOW | No | Use a browser tab instead of native window (set to '0' to fall back) | |
| GC_BRIDGE_DEBUG_DIR | No | Directory for debug logs | /tmp/grok-bridge-debug |
| GC_DEBUG_FORCE_OPEN | No | Force opening a debug window/tab | |
| GC_DEBUG_IDLE_TIMEOUT | No | Idle timeout in seconds before auto-closing the debug window | 15 |
| GC_FIRST_EVENT_TIMEOUT | No | Timeout in seconds for the first output event | 45 |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| grok_askA | Ask Grok (consult by default; worker=True to let Grok edit/run shell in cwd).
Returns JSON: {"status","class","text","run_id","handoff","cwd"} status is SUCCESS | FAILED(class) | TIMEOUT; text is the reply body. |
| grok_workflowA | Run a named Grok Build workflow (e.g. audit-plan, verify-diff).
Returns JSON: {"workflow","success","summary","run_id","handoff"} |
| grok_workflowsA | List available Grok Build workflows (from .grok/workflows/*.rhai). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: grok_ask handles direct Q&A or worker execution, grok_workflow runs a named workflow, and grok_workflows lists available workflows. There is no overlap or ambiguity among them.
All tools share the 'grok_' prefix, but the second part mixes a verb (ask) with nouns (workflow/workflows). This is a minor inconsistency; the pattern is still predictable and readable.
The server has only 3 tools, which is slightly thin but appropriate for a focused Grok interaction server. The tools cover the core needs without unnecessary bloat.
The domain is Grok interaction, and the surface covers asking, running workflows, and listing workflows. Minor gaps could include viewing workflow details or cancelling runs, but these are not critical for the apparent purpose.