Loading ToolBench
codex-as-mcp exposes 2 tools with clear names (spawn_agent, spawn_agents_parallel) that follow verb_noun conventions. Both tools have descriptions that explain their purpose. However, the implementation has critical gaps in schema completeness, parameter documentation, error handling guidance, and composition patterns. spawn_agents_parallel's input schema is incomplete in the provided source (truncated), making full validation impossible. Input validation is present but error messages lack recovery guidance. No tool annotations (readOnlyHint/destructiveHint/idempotentHint). The tool pair exhibits composition issues: spawn_agents_parallel should perhaps return individual success/failure per agent rather than a single list. Output schemas are documented at a high level but lack structured field definitions. No pagination, no support for resource discovery.
Spawn a Codex agent to work inside the current working directory. The server resolves the working directory via ``os.getcwd()`` so it inherits whatever environment the MCP process currently has.
Spawn multiple Codex agents in parallel. Each spawned agent reuses the server's current working directory (``os.getcwd()``).
spawn_agents_parallel input schema is incomplete/truncated in source. The 'agents' parameter has type 'list' with items defined as dict with 'prompt' property, but the schema definition cuts off at 'items':{"type":"dict","properties":{"prompt". Cannot verify full schema structure, nested property descriptions, or type constraints for dict items.
Parameter descriptions for input parameters lack actionable constraints. 'prompt' parameter described as 'All instructions/context the agent needs for the task' but no mention of max length, format expectations, or examples of what constitutes valid/invalid prompts.
Error handling does not guide recovery. Tool returns error strings like 'Error: Codex CLI not found in PATH' but does not suggest next steps (e.g., 'Install Codex via npm install -g @openai/codex' or 'Check that codex is in your PATH'). LLMs cannot self-correct without actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools have WRITE risk and can modify the filesystem via Codex agent. spawn_agent description states agents work 'inside the current working directory' and can execute arbitrary commands, but no destructiveHint annotation warns the LLM of side effects.
Output schema undocumented. spawn_agent returns 'str' (plain string). spawn_agents_parallel returns 'list[dict[str, str]]' but no specification of dict field names, structure, or meaning. LLMs cannot plan downstream tool calls or extract specific data when output fields are not explicitly documented.
spawn_agents_parallel composition issue: returns 'list[dict[str, str]]' with unspecified keys. Docstring mentions 'index', 'output', and optional 'error' fields but this is inferred from docstring text, not from an explicit response schema. When one agent fails, unclear whether the list includes all results, partial results, or stops at first error.
No idempotency guarantee. spawn_agent calls 'codex e --dangerously-bypass-approvals-and-sandbox' which may create files, modify code, or execute arbitrary commands. If an LLM retries due to ambiguous failure, the agent could run twice, causing duplicate edits. No mention of idempotence or deduplication.
Tool descriptions do not mention prerequisites or dependencies. spawn_agent and spawn_agents_parallel require Codex CLI installed and in PATH, require a working directory with appropriate permissions, and require Codex API/auth setup. These dependencies should be explicitly stated so LLMs can predict failure modes.