MCO
A CLI-first orchestration layer for AI coding agents: run your chosen agents and models in parallel, compare raw answers, then act.
- Source repo
- mco-org/mco
- Stars
- ★ 540
- Last updated
- 19d ago
- License
- MIT
- Primary language
- Python
- FA score
- 73/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An engineer wanting cross-model opinions before merging: run mco review --providers claude,codex,pi for a read-only high-risk bug review.
- Not a fit if
- Teams that want a tool that works without installing and authenticating each provider CLI
- Users who need OS-level sandboxing from the orchestrator itself
- Workflows needing MCO to manage worktrees or merge parallel writers
- Source review
- 73/100 · Some gaps
What does this agent do, and when should you use it?
MCO (mco-org/mco, MIT licensed) is a lightweight, CLI-first orchestration layer that turns coding agents such as Claude Code, Codex, Gemini, and Pi into a review or execution team. You explicitly pick the agent team with --providers, and MCO dispatches the task in parallel while retaining each invocation's complete raw answer and operational status. It deliberately keeps answer text opaque: it does not convert natural-language output into findings, severity, confidence, consensus, or automatic decisions, leaving judgment to the human. Permissions map a single execution profile (read_only, write, yolo) onto each provider's native flags, with review read-only and run write by default. Installation bundles an mco-cli Skill so calling agents like Claude Code or Codex can drive MCO, and output is available as text, JSON, JSONL, or Markdown artifacts. Each provider CLI remains responsible for its own installation, authentication, and sandboxing, so MCO itself provides no OS-level sandbox.
MCO reads a repository via --repo and a prompt via --prompt, and dispatches the same task in parallel to selected provider CLIs (claude, codex, gemini, opencode, qwen, copilot, hermes, pi, grok, cursor), or named/model combos via --agent (e.g. fast=pi:model-a). It translates one execution mode into each provider's native permission flags (read_only, write, yolo), and can partition scope with --divide files (round-robined, non-overlapping sorted files) or --divide dimensions (rotating review lenses), plus --debate / --synthesize for debate-and-synthesis and --chain for file-backed chained stages. Output keeps each invocation's raw answer and status, returned as text, JSON, JSONL, or Markdown artifacts; --stream live / l provide live or machine-readable events and --dry-run previews the plan. Provider processes are isolated behind a shared adapter contract (detect, run, poll, cancel, transport decode), so one invocation failure does not discard successful answers. mco doctor checks locally available agents; mco agent models discovers provider models.
- An engineer wanting cross-model opinions before merging: run mco review --providers claude,codex,pi for a read-only high-risk bug review.
- A developer splitting implementation work across models: use mco run --execution-mode write with --divide files to give parallel writers non-overlapping file scopes.
- Someone benchmarking models on the same task: use --agent fast=pi:model-a --agent careful=pi:model-b to compare answers side by side.
- CI integrators: consume --stream l machine-readable events and the documented machine-readable error contract.
- Users who want Claude Code, Codex, or another calling agent to drive MCO: install the mco-cli Skill and let the agent read mco -h, confirm the team, and execute.
- Anyone troubleshooting their setup: run mco doctor -- to check locally available agents and skill health.
How do you install or deploy this agent?
Prerequisites: Python 3.10+, npm/npx, and at least one provider CLI (e.g. claude, codex, pi); provider installation and authentication are each provider's responsibility. Install:
npx @tt-a1i/mco@latest installThis installs the CLI plus the bundled mco-cli Skill; to choose which calling agents receive the Skill:
npx @tt-a1i/mco@latest install --agent codex --agent claude-code --yesThen run mco doctor -- to verify available agents. For development from source: git clone https://github.com/mco-org/mco.git then python3 -m pip install -e .
How do you use this agent?
Read-only multi-agent review:
mco review --repo . --prompt "Review this repository for high-risk bugs." --providers claude,codex,piCoding task with write access:
mco run --repo . --prompt "Implement the requested change and run the relevant tests." --providers codex,pi --execution-mode writePin models for one run:
mco review --providers codex,pi --provider-models-json '{"codex":"gpt-5.4","pi":{"provider":"seal","model":"deepseek-v4-pro"}}' --prompt "..."Preview without executing with --dry-run --; watch live progress with --stream live or get machine-readable events with --stream l. Without --providers or --agent, a top-level providers config entry is used as the saved default; with neither, the team must be selected explicitly.
What are this agent's strengths and limitations?
- Raw, opaque answers: MCO does not fabricate findings, severity, or consensus scores — reviewers see each invocation's complete original text and can judge independently.
- Ten built-in providers (claude, codex, gemini, opencode, qwen, copilot, hermes, pi, grok, cursor) and no auto-inference from detected binaries; team selection is explicit and auditable.
- Provider processes are isolated behind a shared adapter contract, so a single invocation failure does not discard successful answers — valuable in CI settings.
- Clear permission model: read_only / write / yolo profiles map to each provider's native flags, and yolo is explicit opt-in only.
- Operation depends on each provider CLI being locally installed and authenticated; MCO does not manage installation, model access, or credentials, so setup cost sits with the user.
- --allow-paths only validates MCO's requested scope and is not an OS sandbox; isolation strength depends on the underlying provider CLI, limiting security guarantees.
- MCO does not create or manage worktrees; parallel writers must be partitioned with non-overlapping --target-paths or edits can conflict.
- Special paths carry extra constraints — Hermes oneshot bypasses approvals and requires explicit --execution-mode yolo; ACP terminal access is a trusted-agent capability — so the provider permission reference must be read before adoption.
How does this agent compare with similar options?
The README points to Hive (hivehq.dev), a browser workbench with persistent agent identity and a shared task graph; MCO is the lighter CLI-first option for local orchestration and raw-answer comparison, while Hive suits persistent task-graph workflows.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| MCO This agent | 73 · Some gaps | CLIFree + model costs | ★ 540 | 19d ago | Python | Codex · Claude Code |
| Maestro Orchestration Platform | 75 · Some gaps | Agent plugin / skillFree + model costs | ★ 484 | 7d ago | JavaScript | Codex · Claude Code |
| Concord MCP | 67 · Some gaps | — | ★ 707 | 1d ago | TypeScript | Codex · Claude Code |
| NTM (Named Tmux Manager) | 73 · Some gaps | CLIFree + model costs | ★ 462 | today | Go | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows a clear three-tier execution model (read_only/write/yolo) with yolo requiring explicit opt-in, and explicit disclaimers that --allow-paths is not an OS sandbox and providers are never inferred — good least-privilege and confirmation design. However, sensitive-data handling and rollback are entirely unaddressed in the files, and the core runtime code is absent, so the actual enforcement of permission claims cannot be verified. Attribution is weak: authors are anonymous 'mco maintainers' and the npm package lives under the personal scope @tt-a1i with an unverified publisher.
Docs claim isolated invocation failures do not discard successful answers, plus a machine-readable error contract and version-alignment checks — internally consistent. Actual error-handling code is not in evidence, so scores stay at 2.
Audience, scenarios, and environments (terminal or called from other coding agents) are clearly described; ten providers are enumerated with their sandbox boundaries. Trigger precision rests on documentation assertions only, with no implementation shown.
Excellent documentation architecture: layered guides/reference/contracts, bilingual README, CHANGELOG/RELEASING references, consistent MIT licensing, and a version-alignment check script. CHANGELOG content itself is not provided, the package name @tt-a1i/mco diverges from the mco-org repository name, and known limitations are scattered rather than collected.
The raw-answer-retention, no-automatic-synthesis design is a clear differentiator; output formats (text/JSON/JSONL/Markdown) are well specified. Cost/benefit is only qualitative — the token cost of parallel multi-agent runs is never quantified.
Most claims trace to specific documentation and contract files, and CI workflows corroborate the testing/packaging pipeline. The core runtime and error-contract bodies are absent from the evidence, limiting cross-source corroboration; facts and inferences must be kept separate.
- Static review only — no code was executed. The read_only/write/yolo permission translation and sandbox behavior are unverified at runtime; confirm policy resolution with dry-run before use.
- yolo mode activates each provider's broadest bypass profile, and ACP terminal access is designated a trusted-agent capability — use isolation for untrusted agents or prompts.
- --allow-paths is not an OS sandbox; partition parallel writers with non-overlapping --target-paths or expect edit conflicts.
- Publisher identity is unverified and the npm package sits under the personal scope @tt-a1i; the installer injects a Skill into calling agents, so inspect skills/mco-cli contents before installing.
- No rollback story or sensitive-data handling (e.g., transmission/storage of proprietary code in prompts) is documented; assess independently before enterprise adoption.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
MCO v0.12.1 adds Antigravity CLI support and publishes the Windows, MCP, and Ollama reliability fixes merged since v0.11.0. Added - Built-in Antigravity CLI (agy) adapter with model selection, execution modes, authentication checks, and permission-risk reporting (#127). - MCP progress notifications during long runs and per-call timeout overrides (#125). Fixed - Install locked Node dependencies before the release tests. The initial v0.12.0 release attempt failed before npm publication; v0.12.1 includes the same product changes with the corrected publish workflow. …View on GitHub ↗ -
Release notes excerpt
v0.11.0 - Invocation-native runtime Status: breaking release guidance This release changes MCO from a findings/decision pipeline into a raw-answer invocation runtime. Legacy findings-driven design documents remain available for context but are superseded by the [invocation runtime v1 contract](https://github.com/mco-org/mco/blob/v0.11.0/docs/contracts/invocation-runtime-v1.md); this note is the migration guide for callers adopting the new public surface. New behavior - Use repeatable --agent [alias=]provider:model for explicit Agent identity and multiple models from one Provider. …View on GitHub ↗ -
Release notes excerpt
What's Changed * docs: add npm release guide by @tt-a1i in https://github.com/mco-org/mco/pull/96 * feat: add GitHub Copilot CLI adapter by @anxkhn in https://github.com/mco-org/mco/pull/98 * feat: ship agent-native ergonomics in v0.10.7 by @tt-a1i in https://github.com/mco-org/mco/pull/100 * feat: add explicit agent selection and execution modes by @tt-a1i in https://github.com/mco-org/mco/pull/101 * feat: add installer and skill sync workflow by @tt-a1i in https://github.com/mco-org/mco/pull/102 New Contributors …View on GitHub ↗