Related Servers

The sync/async pairs are cleanly separated by the _async suffix, and the five job_* tools each have clearly distinct lifecycle roles. The main ambiguity risk is codex_dry_run: its name doesn't indicate it previews only codex_review_changes, while its sibling codex_delegate_dry_run is explicitly named — an agent could easily pick the wrong dry-run tool. codex_job_result vs codex_job_consume_result is subtle but well-documented.

The set follows a consistent codex_<verb> pattern with uniform _async suffixes and a coherent codex_job_* group. The clear deviation is codex_dry_run, which breaks the <verb>_dry_run convention established by codex_delegate_dry_run and omits its target operation; codex_status/capabilities/models as noun-style discovery tools are minor but acceptable deviations.

At 17 tools this is on the heavier side, but the count is structurally justified: three core operations (consult, review_changes, delegate) × sync/async variants, two dry-run previews, a five-tool job lifecycle, and three discovery tools. Each tool earns its place in the architecture — it feels comprehensive rather than bloated.

Coverage of the domain is thorough: readiness/quota checking, capability and model discovery, consult/review/delegate with both sync and async execution paths, dry-run previews for cost-sensitive operations, and a full job lifecycle (list, status, result, consume, cancel). The intentional absence of a consult dry-run is explicitly documented, and the delegate flow's return of an unapplied diff is a deliberate design choice rather than a gap.