Grok WorldGrok Build CLI field station

GROK BUILD OPERATING SIGNAL / READ ONLY

Make your LLM fluent in the Grok Build CLI.

When your LLM needs exact Grok Build syntax, model and effort options, permission boundaries, or a safe workflow, it can query this source-checked MCP before acting—without giving the MCP command execution or file access.

Connect Grok Build

Already use Claude Code or Codex? Install only that client instead.

LLM → MCP → CURRENT CLI

The manual enters the decision loop

The LLM asks. The MCP returns product-specific evidence. Grok Build remains the current CLI and keeps its native controls.

  1. LLM / ACTIVE AGENT

    Recognizes the current task and asks for exact Grok Build behavior before choosing a command.

  2. MCP / VERIFIED SIGNAL

    Returns matching syntax, configuration, models, workflows, risk labels, and official sources.

  3. GROK BUILD / CURRENT CLI

    The LLM applies the answer inside your existing sandbox, approval policy, and explicit authority.

supported CLIs
3
source-checked manuals
162
read-only tools
12
Hosted endpoint https://mcp.claude-world.com/mcp HTTP / MCP
00 / OPERATING RANGE

What the LLM can verify before it acts

Six focused capability groups turn CLI documentation into operational context without turning the MCP into an executor.

01 / SYNTAX

Exact Grok commands

Look up command paths, flags, arguments, and examples for the captured Grok Build release instead of guessing from another CLI.

02 / CONFIG

Configuration without exposure

Find documented configuration keys and environment-variable names. The MCP cannot read your local files or setting values.

03 / MODELS

Model and effort fit

Check dated model selectors, supported single-task effort, constraints, and fallbacks—then verify the live account catalog.

04 / AUTHORITY

Permission-aware guidance

Keep read-only and may-edit intent distinct from actual approval, filesystem access, sandboxing, or command execution.

05 / EVIDENCE

Source-visible answers

Carry the captured release, review date, source status, canonical link, and documented drift into every consequential answer.

06 / PLAN

Plans that preserve context

Decompose work around the current CLI first, separate native effort from orchestration, and make every handoff and verification gate explicit.

01 / ACQUIRE

Lock Grok Build onto the signal

Grok Build is the recommended client on Grok World. Install only the one CLI client you actually use—connecting all three is unnecessary.

Claude Code

Add
claude mcp add --transport http --scope user worlds-knowledge https://mcp.claude-world.com/mcp
Check
claude mcp get worlds-knowledge

Codex

Add
codex mcp add worlds-knowledge --url https://mcp.claude-world.com/mcp
Check
codex mcp get worlds-knowledge --json
02 / TRANSMIT

Ask the current Grok CLI question first

This prompt makes the agent verify Grok-specific syntax, model and effort support, and permission behavior before it proposes an action.

I am using Grok Build for this task. Before proposing a command, use worlds_list_cli_versions, worlds_search_cli_reference, worlds_get_cli_command, and worlds_list_cli_models to verify the exact Grok syntax, model selector, supported single-task effort, and permission behavior. Keep Grok Build separate from Claude Code and Codex, preserve my current approval boundary, and cite the returned release and official sources.
03 / CONSULT

Consult Grok’s deepest supported model

For one difficult problem, ask for the provider-local maximum-depth model without enabling orchestration or inventing a universal winner.

Call worlds_advise_hard_problem first for this one difficult problem, then verify it with worlds_list_cli_models and grok models. My active and only CLI is grok-build. Keep execution_intent read-only unless I explicitly authorize edits. Use Grok Build's maximum-depth model and supported single-task effort, show the fallback and POSIX template, and do not widen permissions.
04 / PLAN

Plan the work without silently widening authority

The planner keeps Grok Build active when it fits, separates model depth from orchestration, and makes parallel work, handoffs, permissions, and verification explicit.

Call worlds_list_cli_models, then worlds_plan_cli_work for this task. Treat grok-build as the current and available CLI, decompose the work into bounded workstreams with dependencies and verification gates, and keep every workstream read-only by default. Use may-edit only where I have explicitly authorized workspace changes. Label generated shell templates POSIX, show model and effort fallbacks, and never add permission-bypass flags.
ROADMAP / NEXT KNOWLEDGE LAYER

System operations, after CLI fluency

Version 0.5.0 does not include these system-operations manuals. Today’s primary proposition remains source-checked guidance for the LLM using its current Grok Build CLI.

SHELL / FS

Shell and filesystem

Paths, quoting, permissions, links, archives, safe discovery, and bounded file operations.

GIT / VCS

Git state and history

Worktrees, branches, remotes, diffs, commits, merges, recovery paths, and destructive-operation boundaries.

PROC / NET

Processes and networking

Process inspection, signals, ports, DNS, HTTP diagnostics, local services, and credential-safe network checks.

PKG / BUILD

Packages and builds

Runtime managers, lockfiles, dependency resolution, compilers, task runners, caches, and reproducible verification.

BOX / CLOUD

Containers and cloud CLIs

Images, containers, registries, deployment contexts, identity boundaries, remote state, and irreversible actions.

OS / MATRIX

Platform-specific behavior

Separate macOS, Linux, and Windows paths, tools, services, permissions, and native shell semantics.

05 / BOUNDARY

Read-only by design

  • Your query text and selected filters are sent to the hosted endpoint. Do not include secrets, credentials, or private code.
  • The MCP exposes no local-file, local-setting-value, write, command-execution, or arbitrary-URL-fetch tool.
  • A may-edit planning intent can return a workspace-write template, but it grants no permission, edits no file, and runs no command. Your agent and approval policy remain authoritative.
  • Generated shell templates are labeled POSIX. Adapt and review them before using PowerShell or cmd.exe.
06 / SOURCES

Source policy stays visible

  • Released runtime evidence is preferred, then official documentation; unreleased source evidence stays labeled as preview.
  • The 162-manual corpus and model metadata are reviewed snapshots. Your account’s live catalog is authoritative and may change after publication.
  • Results preserve product, captured release, source status, review date, canonical link, and official sources.
  • Runtime, documentation, and source disagreements remain visible as drift. Recheck consequential guidance against the returned primary source.