What can you do with this server?

This server lets your primary AI agent (Claude, Cursor, Cline, etc.) delegate tasks to xAI's Grok via four stateless tools: * grok_chat: Send a one-shot prompt to Grok for quick, single-turn questions or explanations. * grok_review: Get a structured code review on a git diff (auto-generated via git diff ...HEAD or provided manually), returning per-dimension scores (correctness, readability, architecture, security, performance) and a verdict. Supports markdown or JSON output for CI/PR gating. * grok_challenge: Adversarially stress-test code by asking Grok to hunt for bugs, race conditions, edge cases, and security holes—returning severity-ranked issues (Critical/High/Medium/Low) with reproductions and suggested patches. * grok_consult: Conduct multi-turn conversations with Grok by replaying the full message history each call; the caller owns and maintains the conversation thread (server is stateless). All tools support optional model override and timeout configuration. The package also includes a CLI binary (grok-review-ci) and a GitHub Action to automatically review pull requests and fail the check on a block verdict.

How do I use grok-build-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@grok-build-mcp review my current git diff for security flaws" 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.

grok-build-mcp

by howardpen9

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

grok-mcp

npm version MCP Registry

Use Grok as a peer code reviewer and rigorous second-opinion consultant inside Claude Code, Cursor, Cline, OpenClaw, and any other MCP host — talking to xAI's API directly (just an XAI_API_KEY, no install) or via the official Grok CLI.

grok-mcp (npm: grok-cli-mcp) is a Model Context Protocol server for Grok. It gives your primary agent (Claude, Cursor, etc.) four tools so it can delegate to Grok for high-quality second opinions and rigorous validation without leaving the session. As of v0.3.0 it talks to xAI's API directly — no grok binary required — and still supports the CLI for OAuth users:

grok_review — structured diff review with per-dimension scores
grok_challenge — thorough analysis for bugs, races, edge cases and security issues
grok_consult — multi-turn consultation (caller owns history)
grok_chat — one-shot questions

English | 繁體中文

Why grok-mcp?

Most "Grok MCP" packages expose Grok's chat/search/image capabilities so Claude can use Grok. grok-mcp lets your main coding agent (Claude/Cursor/…) ask Grok for a rigorous second opinion on its own work. A different model providing thorough review often catches issues that single-model loops miss.

Related MCP server: Grok Plugin Codex

What you get

Four tools, all stateless, all stdout-only:

Tool	Use it for
`grok_chat`	One-shot prompt → Grok's reply
`grok_review`	Pass a unified diff (or auto-grab `git diff main...HEAD`) and get a per-dimension code review
`grok_consult`	Replay a message history for multi-turn — caller owns the thread
`grok_challenge`	Rigorous analysis: ask Grok to surface bugs, race conditions, edge cases, and security issues

Prerequisites

Node.js ≥ 18
A backend (the server picks one automatically — see Backends):
- API mode (recommended, zero install): an XAI_API_KEY from console.x.ai. The server calls xAI's HTTP API directly — no extra binary needed.
- CLI mode: the Grok CLI installed, used when no XAI_API_KEY is set:
  curl -fsSL https://x.ai/cli/install.sh | bash
  Then authenticate with browser OAuth (run grok once interactively). See Authentication below.

Install

npm install -g grok-cli-mcp
# or use npx — no install needed
npx grok-cli-mcp

Why the npm name is grok-cli-mcp instead of grok-mcp? The bare grok-mcp name on npm was already taken by an unrelated project (a Grok HTTP-API integration). The brand, GitHub repo, and MCP server identity stay grok-mcp; only the npm install identifier is grok-cli-mcp — chosen to highlight that this server wraps the official Grok CLI.

Authentication

There are two auth methods, each tied to a backend:

Method	Backend	Best for	Rate limits
API key (`XAI_API_KEY` env var)	API mode — no `grok` binary needed	MCP / CI / automation	Pay-per-call, no subscription cap
Browser OAuth (`grok` interactive login)	CLI mode	Local interactive use	Subject to your grok.com plan tier

Setting XAI_API_KEY switches the server to API mode, so you can keep your browser login for interactive grok use and use a key just for this MCP server via its env block:

{
  "mcpServers": {
    "grok": {
      "command": "npx",
      "args": ["-y", "grok-cli-mcp"],
      "env": {
        "XAI_API_KEY": "xai-...",
        "GROK_MCP_TIMEOUT": "600000"
      }
    }
  }
}

Treat the key file as a secret — it ends up in your MCP host's config (e.g. ~/.claude.json), which is plain JSON on disk.

Wire it into your MCP host

Claude Code

Recommended — use add-json so the env block parses cleanly:

claude mcp add-json -s user grok '{
  "command": "npx",
  "args": ["-y", "grok-cli-mcp"],
  "env": { "XAI_API_KEY": "xai-...", "GROK_MCP_TIMEOUT": "600000" }
}'

Why add-json not claude mcp add -e ...? The -e KEY=val flag is variadic and will greedily consume the server name as another env value if you pass more than one. add-json sidesteps that footgun entirely.

Or edit ~/.claude.json directly. Minimal (OAuth fallback):

{
  "mcpServers": {
    "grok": {
      "command": "npx",
      "args": ["-y", "grok-cli-mcp"]
    }
  }
}

Cursor

Create .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "grok": {
      "command": "npx",
      "args": ["-y", "grok-cli-mcp"]
    }
  }
}

Cline (VS Code)

Settings → Cline → MCP Servers:

{
  "grok": {
    "command": "npx",
    "args": ["-y", "grok-cli-mcp"]
  }
}

Claude Desktop (local, no hosting needed)

Claude Desktop still supports local stdio servers: Settings → Developer → Edit Config (claude_desktop_config.json), then paste the same JSON block as Claude Code above.

Claude Web / Claude Desktop connectors (remote, v0.4+)

Claude's Settings → Connectors → Add custom connector dialog needs an HTTPS URL, not a command — so deploy the bundled Streamable HTTP server and paste its URL:

# 1. Generate a path secret (keeps strangers from spending your xAI credits)
openssl rand -base64 32 | tr '+/' '-_'

# 2. Deploy anywhere that runs Node (Railway / Fly / Render / a VPS).
#    A multi-stage Dockerfile ships in the repo:
docker build -t grok-mcp . && docker run \
  -e XAI_API_KEY=xai-... \
  -e GROK_MCP_PATH_SECRET=<secret-from-step-1> \
  -p 3000:3000 grok-mcp

# ...or without Docker:
XAI_API_KEY=xai-... GROK_MCP_PATH_SECRET=<secret> npx -y -p grok-cli-mcp grok-mcp-http

Then add the connector in Claude with the URL:

https://your-host.example.com/mcp/<secret-from-step-1>

No OAuth needed — leave the Client ID/Secret fields blank. Claude only starts an OAuth flow if the server asks for it.

Remote-mode notes:

Treat the URL as a credential. The path secret is what stands between the internet and your xAI bill. Rotate it by changing the env var.
grok_review needs an explicit diff over HTTP — the server can't see your local repo, so auto git diff is disabled in remote mode.
Keep GROK_MCP_TIMEOUT below your platform's request timeout (and disable scale-to-zero) — grok-4 reasoning can run for minutes.
GET /health is available for platform health checks; see .env.example for all knobs (GROK_MCP_ALLOWED_HOSTS, GROK_MCP_CORS_ORIGINS, ...).

Any other MCP host

grok-mcp speaks plain stdio MCP. Point any client at npx -y grok-cli-mcp and it works. HTTP hosts can point at the remote endpoint above instead.

Tool reference

`grok_chat`

{ "prompt": "Explain consistent hashing in two sentences." }

Optional: model to override the default Grok model; timeout (seconds) to extend the per-call limit for long grok-4 reasoning. All four tools accept timeout.

`grok_review`

{ "base_ref": "main", "focus": "security" }

If diff is omitted, runs git diff <base_ref>...HEAD in cwd (defaults to your host's working directory). Returns a markdown review by default with verdict, per-dimension scores (correctness / readability / architecture / security / performance), and concrete fix-it items.

Pass "format": "json" to get machine-parseable output suitable for CI gating — see Use as a PR gate.

`grok_consult`

{
  "messages": [
    { "role": "system", "content": "You are a senior backend engineer." },
    { "role": "user", "content": "How would you cache this query?" },
    { "role": "assistant", "content": "Two options..." },
    { "role": "user", "content": "What's the failure mode of option 2?" }
  ]
}

The server is stateless — the caller passes the full thread each time. Most MCP hosts handle this naturally.

`grok_challenge`

{
  "code": "function transfer(from, to, amount) { from.balance -= amount; to.balance += amount; }",
  "context": "Node.js, called concurrently from HTTP handlers"
}

Returns severity-ranked issues (Critical / High / Medium / Low) with concrete reproductions and patches.

Configuration

Env var	Default	Purpose
`XAI_API_KEY`	(unset — falls back to OAuth)	API key from console.x.ai. When set, the server uses API mode (direct HTTP) and bills pay-per-call with no subscription rate cap. See Authentication.
`GROK_MCP_BACKEND`	`auto`	Which backend to use: `api` (direct HTTP), `cli` (shell out to `grok`), or `auto` (API when `XAI_API_KEY` is set, else CLI). See Backends.
`GROK_MCP_MODEL`	`grok-4`	Model used in API mode. (CLI mode reads `~/.grok/config.toml`.)
`GROK_MCP_BASE_URL`	`https://api.x.ai/v1`	API base URL — point at a proxy or compatible gateway in API mode.
`GROK_MCP_BIN`	`grok`	Path to the `grok` binary (CLI mode only)
`GROK_MCP_TIMEOUT`	`300000`	Default per-call timeout in milliseconds

Backends

The server can reach Grok two ways and chooses one at startup (it logs which to stderr):

API mode — calls xAI's OpenAI-compatible /chat/completions endpoint directly using Node's built-in fetch. No grok binary required, cleaner errors, pay-per-call. Selected when XAI_API_KEY is set, or forced with GROK_MCP_BACKEND=api.
CLI mode — shells out to the installed grok binary (supports browser OAuth). Selected when no XAI_API_KEY is set, or forced with GROK_MCP_BACKEND=cli.

Force a mode with GROK_MCP_BACKEND. In API mode, set the model with GROK_MCP_MODEL; in CLI mode, model defaults live in ~/.grok/config.toml.

Timeouts

grok-4 is a reasoning model and long prompts routinely take longer than two minutes. The server's default per-call limit is 300s (5 min). You can change it three ways:

Per call — pass timeout (seconds) to any tool: { "prompt": "...", "timeout": 600 }.
Per server — set GROK_MCP_TIMEOUT (milliseconds) in the MCP server's env.
Host side — the MCP host has its own request timeout that can fire before the server's. If calls still time out after raising the above, raise the host limit too. In Claude Code that's MCP_TIMEOUT (server startup) and MCP_TOOL_TIMEOUT (per tool call), both in milliseconds.

On timeout the error includes any partial output Grok produced before the deadline, so you don't lose a near-complete answer.

Use as a PR gate (CI)

grok-mcp ships a grok-review-ci bin and a composite GitHub Action so Grok can review every PR and fail the check on block.

Drop this into .github/workflows/grok-review.yml in your repo:

name: Grok review
on: { pull_request: { branches: [main] } }
permissions: { contents: read, pull-requests: write }
jobs:
  grok:
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request.head.repo.full_name == github.repository }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - uses: howardpen9/grok-mcp/.github/actions/grok-review@main
        with:
          xai-api-key: ${{ secrets.XAI_API_KEY }}
          gate-on: block      # also accepts: block,request_changes
          # focus: security   # optional
          # min-score: 6      # optional — fail any dimension below this

The action posts a sticky PR comment with verdict + per-dimension scores + concrete blockers, and exits non-zero (failing the check) when the verdict matches gate-on. Full example with comments: examples/workflows/grok-review.yml.

Want JSON straight from the tool instead? Pass format: "json" to grok_review — same schema as the bin emits, suitable for any pipeline:

{
  "verdict": "block",
  "summary": "Unparameterised SQL query in src/db.ts.",
  "scores": { "correctness": 4, "readability": 7, "architecture": 5, "security": 2, "performance": 8 },
  "blockers": [
    { "severity": "critical", "title": "SQL injection", "file": "src/db.ts", "line": 42,
      "reason": "User input concatenated directly into the query.",
      "fix": "Use the parameterised form `db.query(sql, [userId])`." }
  ],
  "notes": []
}

Roadmap

v0.1 — four stateless tools, stdio transport
Discoverability push (v0.1.3, shipped) — naming unification, MCP Registry, Smithery, glama.ai, stronger positioning. See docs/improvement-plan.md and CHANGELOG.md.
v0.2 (shipped) — grok_review JSON mode + grok-review-ci bin + GitHub Action for PR gating.
v0.3 (shipped) — direct xAI API backend (no grok CLI required); GROK_MCP_BACKEND api/cli/auto.
v0.4 (current) — remote MCP mode: grok-mcp-http Streamable HTTP server for Claude Web / Claude Desktop custom connectors, with path-secret auth, Dockerfile, and .env.example.
v0.5 — server-side session persistence so grok_consult can take a conversation_id
v0.6 — streaming responses through MCP progress notifications; OAuth + per-user key store for shared hosted instances

Development

git clone https://github.com/howardpen9/grok-mcp.git
cd grok-mcp
npm install
npm test
npm run build

Contact

Bug reports & feature requests → GitHub issues. DMs welcome on X: @0xHoward_Peng.

License

MIT

Available Tools

4 tools

grok_challengeA

Ask Grok to adversarially break a piece of code: edge cases, race conditions, security holes, adversarial inputs. Returns severity-ranked issues with reproductions.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	The code or design to attack.
`context`	No	Optional context: language, framework, intended behaviour, constraints.
`model`	No
`timeout`	No	Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description bears full responsibility. It states the tool returns severity-ranked issues with reproductions, offering reasonable output transparency. However, it does not disclose side effects, mutation risks, or any operational constraints beyond what the parameters imply.

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 a single sentence with a colon, efficiently conveying purpose and output. Every word is meaningful, with no extraneous content.

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 absence of an output schema and the four-parameter signature, the description provides a reasonable overview of inputs and outputs. However, it lacks details on return format, pagination (if any), and the meaning of the 'model' parameter, leaving some gaps.

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?

The schema provides descriptions for three of four parameters (code, context, timeout), covering 75%. The tool description does not add new parameter insights or explain the missing 'model' parameter. Thus it adds minimal value beyond the schema.

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 identifies the tool as asking Grok to adversarially break code, listing specific types of issues (edge cases, race conditions, security holes, adversarial inputs). This distinguishes it from sibling tools like grok_chat (general chat) and grok_review (code review), giving a clear and specific purpose.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like grok_consult or grok_review. The description does not mention prerequisites, limitations, or when not to use it, leaving the agent without decision-making context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

grok_chatA

Send a one-shot prompt to xAI Grok and return its reply. Stateless — for multi-turn use grok_consult.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	The prompt to send to Grok.
`model`	No	Override default Grok model (e.g. 'grok-4').
`timeout`	No	Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations provided, but the description fully covers behavioral traits: stateless, one-shot, returns reply. No contradictions; the description is sufficient for understanding the tool's behavior.

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?

Two concise sentences with no waste. Every part is necessary and informative, front-loaded with the core purpose.

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

Completeness5/5

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

Given the simple stateless nature, 3 parameters, and no output schema, the description covers all needed context: purpose, statelessness, usage guidance, and parameter details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining model parameter overrides and timeout details ('Defaults to 300. Raise for long grok-4 reasoning'), going beyond the schema.

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 explicitly states 'Send a one-shot prompt to xAI Grok and return its reply', clearly identifying the action and resource. It distinguishes from sibling tools by noting 'Stateless — for multi-turn use grok_consult'.

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?

The description provides clear guidance: use for one-shot stateless queries, and directs to grok_consult for multi-turn interactions, naming the specific alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

grok_consultB

Continue a conversation with Grok by replaying the full message history each call. Stateless on the server side — the caller owns the thread.

ParametersJSON Schema

Name	Required	Description
`messages`	Yes	Conversation history. Caller maintains state across turns.
`model`	No
`timeout`	No	Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations, the description effectively communicates the key behavioral trait: stateless server, caller responsible for maintaining state. It clearly indicates that full message history is replayed each call. However, it omits details on response format, error handling, or limits.

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?

Two concise sentences with front-loaded purpose. Every word is necessary and informative, capturing the essence without redundancy.

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

Completeness2/5

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

No output schema exists, yet the description fails to specify what the tool returns (e.g., an assistant message). It also lacks context on error conditions, token limits, or comparisons to sibling tools. This makes it incomplete for a tool with three parameters and no output schema.

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?

The input schema provides good descriptions for 'messages' and 'timeout' (67% coverage). The tool description does not add parameter-specific info beyond the schema, and the 'model' parameter lacks any description, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's purpose: continuing a conversation with Grok by replaying full message history. It distinguishes the tool's stateless approach but does not explicitly differentiate from sibling tools like grok_chat or grok_review.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description mentions statelessness and caller-owned state, but does not compare to siblings or provide when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

grok_reviewA

Have Grok review a git diff. If no diff is provided, runs git diff <base_ref>...HEAD (default base: main). Returns a per-dimension review. Use format='json' for CI gating (verdict + scores + blockers).

ParametersJSON Schema

Name	Required	Description
`diff`	No	Unified diff to review. If omitted, runs `git diff <base_ref>`.
`base_ref`	No	Git ref to diff against when diff is not provided. Defaults to 'main'.
`focus`	No	Optional focus area (e.g. 'security', 'performance', 'API design').
`format`	No	Output format. 'markdown' (default) returns a human-readable review. 'json' returns a machine-parseable verdict suitable for CI gating.
`model`	No
`cwd`	No	Working directory for git diff. Defaults to process cwd.
`timeout`	No	Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavioral traits. It explains the default git diff behavior and the effect of format parameter, but does not mention potential side effects like reading local files or the execution environment. The timeout parameter's purpose is only in the schema, not reinforced in the description.

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 three sentences, each earning its place: purpose, default behavior, and a key usage hint. It is front-loaded and contains no redundant information.

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

Completeness2/5

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

Despite having no output schema, the description does not explain what 'per-dimension review' means or what dimensions are reviewed. The 'focus' parameter is mentioned in schema but not elaborated. The 'model' parameter lacks any description, leaving the agent without guidance on model selection. This is incomplete for a tool with 7 parameters.

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 high (86%), so the baseline is 3. The description adds value by explaining the default behavior when diff is omitted and emphasizing the json format for CI, but does not significantly elaborate on other parameters beyond what the schema provides.

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: 'Have Grok review a git diff.' It specifies the verb (review), resource (git diff), and mentions the default behavior when diff is omitted. It distinguishes from siblings like grok_chat and grok_consult, which are conversational rather than code-review focused.

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

Usage Guidelines4/5

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

The description explicitly advises when to use format='json' for CI gating, which provides clear usage guidance. However, it does not explicitly state when not to use this tool or compare to alternatives, though the sibling tools are sufficiently different to imply appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.2.0Jun 12, 2026

Changedgrok_challenge1 field changed

addedInput schema / properties / timeout

Added value: +{
+  "description": "Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.",
+  "exclusiveMinimum": true,
+  "minimum": 0,
+  "type": "number"
+}

Changedgrok_chat1 field changed

addedInput schema / properties / timeout

Added value: +{
+  "description": "Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.",
+  "exclusiveMinimum": true,
+  "minimum": 0,
+  "type": "number"
+}

Changedgrok_consult1 field changed

addedInput schema / properties / timeout

Added value: +{
+  "description": "Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.",
+  "exclusiveMinimum": true,
+  "minimum": 0,
+  "type": "number"
+}

Changedgrok_review2 fields changed

addedInput schema / properties / format

Added value: +{
+  "description": "Output format. 'markdown' (default) returns a human-readable review. 'json' returns a machine-parseable verdict suitable for CI gating.",
+  "enum": [
+    "markdown",
+    "json"
+  ],
+  "type": "string"
+}

addedInput schema / properties / timeout

Added value: +{
+  "description": "Per-call timeout in seconds. Defaults to 300. Raise for long grok-4 reasoning.",
+  "exclusiveMinimum": true,
+  "minimum": 0,
+  "type": "number"
+}

4 tool updatesv0.1.0May 26, 2026
- First observedgrok_challenge
- First observedgrok_chat
- First observedgrok_consult
- First observedgrok_review

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-12 19:25 across 4 tools

Disambiguation5/5

Each tool targets a completely different interaction: adversarial challenge, one-shot conversation, multi-turn conversation, and code review. There is no overlap in purpose.

Naming Consistency5/5

All tool names follow the identical pattern 'grok_<verb>' (challenge, chat, consult, review), providing a clear and predictable naming convention.

Tool Count4/5

With four tools, the surface is lean but focused. It covers the main code interaction modes without being too few for a build-oriented MCP server.

Completeness4/5

The set covers challenging, chatting, consulting, and reviewing code. Missing a general code explanation or generation tool, but for the advertised purpose it is reasonably complete.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
mcp-grokOAuth
io.github.AceDataCloud
MCP server for Grok Imagine AI video generation
AI & Machine Learning Image & Video Processing
31
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1

Related MCP Servers

Grok MCP
Autonomous Agents Image & Video Processing Search
merterbak
A
license
A
quality
A
maintenance
Use XAI's latest api functionalities with Grok MCP. It supports image understanding and generation, live search, latest models and more.
Updated 15 days ago (2026-08-29 08:05 UTC)
22
52
MIT
Grok Plugin Codex
Command Line Code Analysis AI & Machine Learning
handong66
A
license
B
quality
B
maintenance
An MCP server that exposes the local Grok CLI to Codex for bounded repo work, reviews, rescue analysis, adversarial checks, session listing/export, and background job management while keeping Codex hidden context out of scope.
Updated 11 days ago (2026-09-02 03:45 UTC)
12
MIT
Grok Build Bridge
Developer Tools Code Analysis
Reederey87
A
license
Not graded
quality
B
maintenance
An MCP server that wraps the local Grok Build CLI, enabling Codex to delegate code reviews, bounded coding tasks, and setup diagnostics to Grok for a second opinion or parallel processing.
Updated 4 days ago (2026-09-09 22:57 UTC)
4
Apache 2.0
Grok Codex
AI & Machine Learning Developer Tools
Meapri
A
license
A
quality
C
maintenance
MCP server for integrating xAI's Grok model into OpenAI Codex Desktop/GUI, enabling direct Grok calls via chat completions or responses with OAuth or API key authentication.
Updated 2 months ago (2026-07-16 03:15 UTC)
9
MIT