Loading ToolBench
A Codex plugin that delegates bounded work and isolated Grok-native search to the official Grok Build CLI.
Strong tool definitions with complete schemas, clear descriptions, and thoughtful parameter design. All 12 tools have explicit JSON Schema with type constraints and descriptions. Tool names follow verb_noun convention (grok_spawn_*, grok_search_*, grok_status, etc.). Descriptions are substantive (100-250 chars typical), explaining WHAT the tool does and WHEN to use it. Parameters include enums (platform, depth, access_mode), bounds (timeout_seconds: 30-1800), and confirmation gates (confirm_write_scope, confirm_interactive_handoff) for destructive operations. Annotations present for all tools (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Output schemas not explicitly documented in source, inferred from descriptions but not formally specified. Error handling guidance present in descriptions but not structured as recovery patterns. Some parameter descriptions could be more explicit about format/constraints (e.g., 'cwd' and 'worktree' accept absolute paths but format not stated).
Cancel the active turn for a Grok agent while keeping its ACP session available.
Terminate a Grok agent process and remove it from the bridge.
Open an independent interactive Grok Build TUI in a new macOS Terminal window. Codex hands off the prompt and does not supervise the session.
List all Grok agents currently owned by this bridge process.
Get a Grok agent's accumulated public answer. Optionally wait briefly for the current turn to finish.
Run an isolated Grok 4.5 research task with X Search, web search, and web fetch from a private directory outside the current repository. Use for X/Twitter, Reddit, community sentiment, and real-time public research.
Output schemas not formally documented. Tool descriptions infer return structure (e.g., 'Returns immediately after ACP setup', 'Get accumulated public answer') but no explicit response schema is visible in source. LLMs cannot reliably plan downstream tool calls without knowing what fields to expect.
Path parameters (cwd, worktree) lack explicit format constraints. Descriptions say 'Absolute project directory' and 'Absolute path to linked Git worktree' but do not state format, validation rules, or what happens if relative paths are passed. LLMs may pass invalid paths.
Error handling guidance not structured as recovery patterns. Descriptions mention prerequisites (e.g., 'Requires explicit confirmation') but do not provide actionable error messages or recovery steps. If a tool fails, the LLM has no guidance on what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List retained isolated Grok search runs.
Read the full retained answer from a previous Grok search run.
Send a focused follow-up prompt to an idle Grok agent in the same ACP session.
Start an authenticated Grok Build agent in an OS-enforced read-only sandbox. Returns immediately after ACP setup while the prompt runs in the background.
Start Grok Build with workspace write access, but only inside a linked Git worktree. Requires explicit confirmation of write scope.
Inspect one Grok agent's lifecycle and visible progress. Optionally wait for a newer progress revision.
grok_status and grok_result descriptions are terse (75 chars). 'Inspect one Grok agent's lifecycle and visible progress' and 'Get a Grok agent's accumulated public answer' lack context on when to call each vs the other, what 'progress revision' means, or what 'wait_seconds' does.
grok_list and grok_search_list descriptions are minimal (70 chars). No explanation of what structure is returned, how many items, or pagination behavior. LLMs cannot infer whether results are paginated or capped.