Loading ToolBench
MCP server for Codex CLI with Ollama backend support. Provides multi-model profile routing for code execution tasks.
This server has significant definition quality gaps that would not pass production code review. Tool descriptions are brief but present; however, schema completeness is inconsistent, parameter descriptions vary widely, and error handling lacks recovery guidance. Most critically, file system tools lack path validation documentation and the Codex tools lack crucial parameter constraints (enums for profile values, bounds for timeout). The server conflates multiple concerns (Codex CLI automation + filesystem access) without clear separation. Per the production baseline (avg 194 chars for descriptions, 100% of A+ tools document params), this server falls short.
List available Codex profiles and their Ollama models
Resume the last Codex session with additional input.
Run a task with Codex CLI via Ollama backend. Returns output when complete.
List files in the work directory
Read a file from the work directory
Write a file to the work directory
Profile parameter lacks enum constraint. 'profile' in codex_run and codex_resume accepts free-form strings instead of declaring the valid set {default, fast, heavy, reasoning, coder, security}. LLMs will hallucinate invalid profile names.
Timeout parameter unbounded. 'timeout' in codex_run has no minimum/maximum specified. LLMs could pass negative values, zero, or excessively large timeouts causing hangs or resource exhaustion. Should constrain to e.g. 1 - 3600 seconds.
Path traversal validation not documented. fs_read, fs_write, and fs_list perform `path.startsWith(WORKDIR)` checks in code, but the tool descriptions do NOT warn users/agents about sandboxing or mention the WORKDIR boundary. Undocumented constraints cause confusion and potential misuse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Error responses lack recovery guidance. When fs_read fails with 'Path outside workdir' or codex_run encounters a timeout, the error message is raw and does not tell the LLM what to do next (retry, ask user, use alternate tool, etc.). Per pattern:recovery-guide, errors must be actionable.
No output schema documented. Tool descriptions do not specify what fields/structure callers should expect. e.g., codex_run returns {code, stdout, stderr} but the description omits this. LLMs cannot plan downstream steps without knowing output structure.
Model parameter description incomplete. The 'model' param in codex_run says '(optional)' but does not explain what happens if omitted (falls back to profile.model), what format is expected, or which models are valid. Underdocumented parameters invite hallucinated values.
No idempotency guarantees. codex_run spawns a Codex process with side effects (tasks executed, files modified) but does NOT document whether repeated calls with same args are safe or produce duplicates. Per pattern:idempotent-operation, tools with side effects must state idempotency or lack thereof.
WORKDIR dependency implicit. Tools assume CODEX_WORKDIR environment variable is set and valid, but this constraint is never documented in tool descriptions. If an agent is deployed without WORKDIR, all filesystem tools silently fail or error cryptically.
Output truncation behavior undocumented. trimOutput() truncates codex_run stdout to 50KB and stderr to 5KB, but tool descriptions do NOT warn that large outputs are silently capped. LLMs may miss critical output and incorrectly assume the task fully completed.