METAGROK
BUILD / inspect-grok-build-config-with-grok-inspect

Build

Inspect Grok Build config with grok inspect

inspect-grok-build-config-with-grok-inspect

See exactly which rules, skills, plugins, hooks, and MCP servers Grok Build loaded for the current directory before you debug a missing tool or a wrong model. Official CLI Reference lists grok inspect [--json] as the subcommand that prints the configuration discovered for this working tree, and Grok Build overview recommends running it after you edit ~/.grok/config.toml so custom models and other sources show up before you pick -m or /model. Settings notes the same check when confirming which config scopes were picked up.

What you need

The Grok Build CLI installed (curl -fsSL https://x.ai/cli/install.sh | bash or the Windows install script from the overview), a project directory you can cd into, and optional edits already saved under user ~/.grok/config.toml, project .grok/config.toml, managed configs, or vendor files such as .cursor/mcp.json. Neighboring jobs include Add MCP servers in Grok Build, Diagnose MCP servers with grok mcp doctor, and Use Grok Build hooks for lifecycle automation. More Build jobs live on the Build hub.

Run inspect in the project

  1. Open a terminal in the repo you intend to debug (or pass --cwd on later commands) and confirm the CLI is on your PATH with a version print before you trust any discovery output:
cd /path/to/your-project
grok version
  1. Print the human-readable discovery report for this directory so you can see every config source, instruction file, skill, plugin, hook, and MCP server Grok assembled for the session:
grok inspect

MCP rows should show each server’s origin (user config.toml, project .grok/config.toml, Claude/Cursor compat files, and so on). After adding a custom model block under [model."…"] in ~/.grok/config.toml, confirm that model appears in this report before you call it headlessly with -m or switch to it in the TUI.

  1. Prefer machine-readable output when a script or CI job needs to assert that a server or skill loaded, then pipe the JSON through jq (or your language’s JSON parser) so the job fails when an expected MCP name or skill path is missing:
grok inspect --json
  1. After inspect looks right, exercise the model or MCP path you care about — for example a one-shot headless prompt with an explicit model id, or a doctor run on a stubborn server — and inside the TUI you can still switch models with /model <id> while /mcps or /hooks toggles match what inspect already listed:
grok -p "Hello" -m my-model
grok mcp doctor

How discovery layers stack

Environment variables, user config, project .grok/config.toml (MCP, plugins, permission rules), managed configs, and requirements files all contribute; project servers with the same name as a user server replace the user entry entirely per the MCP docs. Compat loaders also merge ~/.claude.json, .cursor/mcp.json, and project .mcp.json below config.toml unless you disable a vendor with [compat.claude] mcps = false or [compat.cursor] mcps = false. When inspect shows a server you did not expect, check those compat files before deleting a config.toml block that may not be the real source.

Pitfalls

Running grok inspect from the wrong directory hides project .grok/config.toml files that only appear when Grok walks up from the intended cwd to the git root, which makes missing MCP or hook entries look like product bugs. Editing config without re-running inspect (or refreshing /mcps with r in the TUI) leaves you debugging stale assumptions about what the next session will load. grok mcp doctor diagnoses connectivity after inspect proves the server is on the load list, so use both when a tool name never appears in the session even though you believe the server was added.