Grok Build native MCP and hooks

Grok Build native MCP and hooks

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

AIWG can opt into Grok Build's native project surfaces without treating Grok as a Claude or Codex compatibility target.

MCP configuration

Register a server in the AIWG MCP registry, then inject it into the reviewed project layer:

Use AIWG to complete this documented outcome: Register a server in the AIWG MCP registry, then inject it into the reviewed project layer
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

AIWG edits only its marked server blocks in `.grok/config.toml`. Comments, unrelated tables, ordering outside those blocks, and operator-owned servers are preserved. A same-name operator server blocks deployment instead of being overwritten. Remove managed entries with:

Use AIWG to complete this documented outcome: AIWG edits only its marked server blocks in .grok/config.toml. Comments, unrelated tables, ordering outside those blocks, and operator-owned servers are preserved. A same-name operator server blocks deployment instead of being overwritten. 
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Use `${NAME}` or `${NAME:-default}` references in URL, command, argument, environment, and header values. Grok expands them while loading; AIWG does not persist the expanded secret in configuration, receipts, or diagnostics.

Project configuration has higher precedence than the user configuration for a same-name server. Organization requirements or managed policy can therefore block a requested project integration; this is reported as `blocked-by-policy`, not as a successful write. Native verification uses `grok inspect the json option`, `grok mcp list the json option`, and `grok mcp doctor <name> the json option`.

Hooks and trust

Hook translation is explicit:

Use AIWG to complete this documented outcome: Hook translation is explicit
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

AIWG writes owned JSON under `.grok/hooks/`. Deployment never edits `~/.grok/trusted_folders.toml`, runs `/hooks-trust`, or launches Grok with the trust option. Review the generated files and grant project trust separately in Grok if appropriate.

AIWG maps `SessionStart`, `SessionEnd`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, and `Stop` to the same Grok events. Unsupported events are reported instead of being silently approximated. Only `PreToolUse` can block, and only an explicit JSON deny decision blocks. Timeouts, crashes, malformed output, non-denial exits, and failures from passive events are fail-open.

Status distinguishes `configured`, `disabled`, `blocked-by-policy`, `untrusted`, `unhealthy`, and `absent` for the native MCP and hook surfaces.