Grok Build 插件

grok-build-plugin: Grok Build for any coding agent

Want Claude Code, Codex, or Cursor to drive Grok Build? If you already pay for a Grok subscription, this gives any of those agents live X search and data right in their context. A couple of ways to wire it up.

Bring Grok Build's live X (Twitter) + web search (and its coding agent) into the tools you already use. Two ways to consume it:

• An MCP tool (grok_search): works in any MCP-capable agent: Claude Code, OpenAI Codex, Cursor, and others. This is the cross-agent, real-time-search core.
• A Claude Code / Grok plugin: convenience slash commands (/grok:search, /grok:review, /grok:rescue, and more) plus a delegation subagent, with the MCP tool auto-wired in.

Grok Build has native, real-time access to X and the web, strong for breaking news, social sentiment, current package/version facts, and anything where "what's true right now" matters, which a model's training cutoff can't provide. This project is a thin, auditable wrapper around your local grok CLI.

Install

Add the marketplace in Claude Code:

/plugin marketplace add VasiHemanth/grok-build-plugin

Install the plugin:

/plugin install grok@grok-build-plugin

Reload plugins:

/reload-plugins

Then run:

/grok:setup

/grok:setup reports whether Grok is installed and authenticated. If it is installed but not signed in, run !grok login and rerun setup.

Per-agent setup

Tested live with the npx launch (both github: during development and the published grok-build-x-search-mcp): OpenAI Codex, Antigravity (agy), Gemini CLI, plus the standalone server handshake. Any other MCP client (Cursor, opencode, Copilot) uses the same JSON config.

Why `npx grok-build-x-search-mcp` (preferred) or `npx github:...`

MCP clients resolve plugin paths differently. Claude Code and Grok substitute ${CLAUDE_PLUGIN_ROOT}, but Codex does not, so a ${CLAUDE_PLUGIN_ROOT}-based manifest fails there. Using the published package (npx -y grok-build-x-search-mcp) or npx -y github:VasiHemanth/grok-build-plugin sidesteps all of it: npm hands every harness a correct absolute path, and the server resolves its own imports relative to itself (not the working directory). One manifest, every agent.

The published package on npm gives the fastest cold start (no git clone). The github: form still works as a fallback / for development and always points at the latest from the repo.

Publishing the MCP server part to npm as grok-build-x-search-mcp (distinct from the plugin marketplace name) is now complete for v0.1.0+. The repo is grok-build-plugin on GitHub (was previously grok-mcp). The Claude/Grok plugin is installed via the marketplace using the repo name.

Cross-harness: install in Grok too

This plugin follows the shared plugin spec, so it installs into Grok Build as a native plugin as well as into Claude Code. Grok reads Claude-format marketplaces, scans ~/.claude/skills/, honors ~/.claude/settings.json, and maps a plugin's commands/ into its own skill/slash-command system. Verified with grok plugin validate and a full install cycle.

```bash

Install locally into Grok (trusts hooks/MCP)

grok plugin install ./plugins/grok --trust

Quick start: add `grok_search` to your agent

Works today in any MCP-capable agent, no install or publish step. You just need the Grok Build CLI signed in (grok login).

// drop into your agent's MCP config (see the per-agent table below for the path)
{
  "mcpServers": {
    "grok": { "command": "npx", "args": ["-y", "grok-build-x-search-mcp"] }
  }
}

Or one line for OpenAI Codex:

codex mcp add grok -- npx -y grok-build-x-search-mcp

Then just ask your agent to "search X for ..." and it will call grok_search. Verified live in Codex, Antigravity (agy), and Gemini CLI. Full per-agent paths are in Per-agent setup.

Usage

Environment variables

Validate against Grok's plugin spec

grok plugin validate ./plugins/grok

FAQ

Do I need a separate Grok account? No. The plugin uses your local grok CLI authentication. If you're already signed in (grok login), it works immediately.

Does it use a separate Grok runtime? No. It delegates to your local grok CLI on the same machine, with the same auth, config, and repository checkout.

Is the review really read-only? Yes. Review and search runs are restricted to read-only tools, so Grok cannot edit files or run shell commands during them. /grok:rescue is write-capable by default (use --read-only to restrict it).