Skip to main content
Glama
parisbs

codex-subagent-mcp

by parisbs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delegate a task to Codex

codex_delegate

Delegate coding or analysis tasks to a local Codex CLI for read-only investigation, review, or optional file edits. Set model, reasoning effort, sandbox, and context per request.

Instructions

Delegate a coding or analysis task to the local Codex CLI, choosing model and reasoning effort. Codex runs read-only by default: it investigates and reports. Set sandbox to workspace-write to let it edit files. Codex cannot see this conversation, so pass everything it needs in prompt, context, and target_files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoblocking (default) waits and streams progress; background returns a job_id immediately.
modelNoCatalog slug from list_codex_models. Omitted means the recommendation matrix picks one.
promptYesThe task for Codex. Be specific and self-contained: Codex cannot see this conversation.
contextNoBackground Codex needs: prior findings, constraints, relevant excerpts.
sandboxNoSandbox policy. Defaults to read-only: Codex analyses and reports but cannot modify files.
add_dirsNoAdditional absolute directories that should be writable alongside working_dir.
web_searchNoEnable Codex's native web search tool.
working_dirNoAbsolute path Codex uses as its working root.
auto_approveNoAdds --approve-for-me so Codex auto-approves its own commands. Only applies when sandbox allows writes.
target_filesNoPaths Codex should focus on, relative to working_dir.
use_worktreeNoRun in a managed git worktree so changes never touch the current working tree.
timeout_secondsNoWall-clock budget. Defaults to 1800s.
reasoning_effortNoReasoning depth, independent of model choice. Clamped to what the chosen model supports.
acceptance_criteriaNoConcrete conditions that must hold for the task to be considered done.
skip_git_repo_checkNoAllow running outside a git repository.
system_instructionsNoPersona or extra rules inherited from the orchestrator, layered on the built-in quality contract.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and openWorldHint=true, so the safety bar is lower. The description adds meaningful behavioral context beyond annotations: the default read-only behavior, the workspace-write escape hatch, and the crucial isolation constraint that Codex cannot see this conversation. It doesn't cover timeout defaults or approval implications, which the schema documents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: what the tool does, the safety default, and the isolation constraint. Front-loaded with purpose and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter delegation tool with rich schema and no output schema, the description covers the essential operational facts an agent must know (default read-only, write enablement, context isolation). It leaves timeout defaults and mode semantics to the schema, which is reasonable given the full coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 16 parameters thoroughly. The description reinforces the prompt/context/target_files trio as the isolation-carrying inputs, which adds a little framing but no syntax or format detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delegate) and resource (coding/analysis task) and names the execution backend (local Codex CLI). It distinguishes itself from siblings like list_codex_models and codex_job_status by being the task-submission entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives real context: Codex runs read-only by default and only edits when sandbox is set to workspace-write, which implicitly tells the agent when to use each mode. It doesn't explicitly route to siblings like codex_recommend or codex_follow_up, so it falls short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools