mco refuses to guess which agents you meant

It will not infer a team from the binaries it finds

Most orchestration tools scan your machine, find whatever agent CLIs are installed, and dispatch to them. This one refuses, and the refusal is stated as a rule rather than a limitation.

MCO never infers a provider and model team from detected binaries. If you supply neither a providers list nor an agent declaration, it falls back to a saved providers entry in configuration, and if that is absent too, it requires you to choose explicitly.

That means the common failure mode of these tools, where a review goes to an account you forgot was authenticated, is designed out. The cost is a slightly longer command line.

The default shape of a run is short. A read-only review takes a repository, a prompt and a list of providers:

mco review \
  --repo . \
  --prompt "Review this repository for high-risk bugs." \
  --providers claude,codex,pi

When another agent is the caller rather than you, the documented expectation is that it still shows and confirms the resolved provider and model team with you before dispatching, so the confirmation happens even when the prompt was written by something else.

A doctor command reports which agents are actually available on the machine, which is how you find out what you can name before naming it.

Answers stay opaque, and that is the load-bearing constraint

The most consequential decision in the design is what the tool declines to do to an agent's output.

MCO keeps answer text opaque. It does not convert natural language into findings, severity scores, confidence values, consensus, or an automatic decision. A review produces reviews, plural, and the comparison is left to whoever is reading.

That is a deliberate refusal of the feature most people would ask for first. A summarised report with severity labels looks more useful and is strictly less trustworthy, because you cannot tell which claim came from which agent or whether the summariser invented a finding that nobody raised.

The workflow it supports instead is four steps: choose the agents, dispatch them in parallel or as a chain or with divided scope, compare the complete raw answer and operational status from each, then decide after inspecting evidence, disagreements and failures.

Scope division supports two shapes, and both only rearrange the prompt or the file set. Dividing by files excludes ignored, local and build directories, then round-robins the remaining sorted repository files with no overlap between agents. Dividing by dimensions rotates review lenses in declaration order without touching which files are targeted.

Both are visible in a dry run, and neither changes what comes back: the returned answers remain raw.

Ten provider CLIs, each still in charge of its own access

The provider list is broad, covering coding agents from several vendors plus a few others: Claude Code, the Codex CLI, Gemini CLI, OpenCode, Qwen Code, the GitHub Copilot CLI, Hermes, Pi, Grok Build and the Cursor CLI.

Each one is addressed by a short provider identifier that matches its own command name, which keeps the configuration readable. Cursor is the only slightly awkward case, since it answers to two local command names.

The boundary of responsibility is explicit: each provider CLI remains responsible for its own installation, authentication, model access and native sandbox behaviour. MCO does not log you into anything, does not manage credentials, and does not wrap a provider's security model. It is an orchestrator sitting above tools it does not replace.

That design is what lets a workflow mix providers freely, and it is also why you should not read MCO's permission settings as a complete security story.

Model selection is per run and does not alter provider defaults, so you can pin a specific model for one invocation:

mco review \
  --providers codex,pi \
  --provider-models-json '{"codex":"gpt-5.4","pi":{"provider":"seal","model":"deepseek-v4-pro"}}' \
  --prompt "Review this repository for bugs."

The pinning accepts a plain string for one provider and an object with provider and model for another, which is how you route two agents to the same local CLI but different backends.

Three execution modes, and the broadest one must be asked for

One execution profile is translated into each provider's own native flags, so you choose an intent and the tool works out the per-provider spelling.

Read-only is for inspecting and reviewing without mutating the workspace, and it is the default for the review command. Write is for creating and editing files in the workspace, and it is the default for the run command.

The third is a bypass profile using the provider's broadest permissions, and it is opt-in only. Nothing defaults into it.

One provider needs it spelled out: the Hermes oneshot path bypasses approvals, so using it requires explicitly selecting that execution mode rather than inheriting a default.

Two other capabilities are flagged as trusted-agent territory. Terminal access over the agent protocol is described as a capability to use only with agents and prompts you trust, with isolation recommended for anything else.

Worktrees are the fourth boundary, and it is the one most likely to bite. MCO does not create or manage worktrees. If you run several write-mode agents against the same checkout, they will edit the same files, so the documented guidance is to partition ownership with non-overlapping target paths and warn about possible edit conflicts.

In other words parallel writers are supported but the isolation is your responsibility to arrange.

allow-paths validates scope, it does not contain anything

One line in the permissions documentation deserves to be read twice, because the flag name suggests a guarantee it does not provide.

The allow-paths flag validates the scope MCO is requesting. It is not an operating system sandbox.

So a path allow-list expresses intent and catches configuration mistakes, and it does not stop a process from doing something outside that list if the underlying provider CLI would allow it. The next line reinforces the point: how strong the sandbox actually is depends on the provider command underneath, which MCO does not control.

Read together, those two lines relocate the security boundary. It sits with each provider's own sandbox behaviour, and MCO's contribution is to translate one intent into whatever that provider happens to offer, plus enough validation to catch a mistyped path.

The workflow documentation makes the same point from the calling-agent side: the command line is self-describing, so an agent can read the help, resolve saved defaults, confirm the team with you, preview the policy, and only then execute. Previewing before executing is the recommended sequence, and a dry run with machine-readable output is available for exactly that.

The installer and the runtime select different things

There are two agent flags in this tool and they mean unrelated things, which is a reliable source of confusion.

The installer's agent flag chooses which calling agents receive the MCO skill, so it decides where the instructions get installed. A single command can install for several at once and skip the prompts.

At runtime, the providers list, a saved providers configuration entry, or runtime agent declarations choose the task invocations, meaning which agents actually answer your prompt.

So installing the skill for a coding agent and then invoking a different set of agents in a run are not contradictory, they are two separate selections that happen to share a word.

npx @tt-a1i/mco@latest install --agent codex --agent claude-code --yes
mco doctor --skill-health --json

The doctor command has a skill health mode that checks the installed skill rather than the available agents, and it reports in JSON so a script can act on it.

That split is what lets one machine have Claude and Codex receiving instructions while a particular run dispatches to a completely different set of providers.

The Python package declares no dependencies at all

The packaging is split across two ecosystems and the split is unusually clean.

The npm package is described plainly as a node wrapper for the command line tool, with a python runtime required. It carries the installer wizard, the launcher, the runtime files and the skill, and it has exactly two dependencies: a prompt library and a cross-platform spawn helper. Node 18 or newer is required.

The python package underneath is where the tool actually lives, and its required dependency list is empty. The console entry point comes from the runtime module, and the only optional extra is an MCP client for a memory feature, version constrained to a single major release.

Supported python versions are 3.10, 3.11 and 3.12, and the classifiers describe it as a console tool that is operating system independent, filed under quality assurance and testing rather than under developer tooling.

So the tool that shells out to ten different agent CLIs has no runtime library dependencies, which is a reasonable position for a process orchestrator and makes installation cheap on the python side.

The repository keeps its conventions in files an agent will read, alongside a Chinese translation of the readme, a changelog, a release process document and a top-level reports directory. The last push to main is dated 2026-08-14.

Editorial conclusion

mco suits review work where you want to see disagreement rather than a summary, because the opacity guarantee means you are comparing what each agent actually said instead of a generated consensus you cannot audit. It is a poor fit for automation that needs a parsed verdict, since nothing here produces one by design. Before running a write mode, read the permissions boundaries rather than assuming a path allow-list is isolation, and if you dispatch parallel writers, partition the target paths yourself, because the tool will not create worktrees for you.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mco-org/mco on GitHub
4. README
5. Releases