NomArmy

What nomArmy MCP server does

The nomArmy MCP server delegates coding tasks to workers called noms and treats each worker's completion report as an unverified claim. A General agent supplies the task, acceptance criteria, and tests. nomArmy then inspects the actual Git diff, runs the repository's verification profile, and decides whether the work can be committed.

Verified work is committed on the nom's own branch rather than merged into the developer's branch. Review and integration remain separate steps. The system can also run verification without starting a worker or consuming model tokens by using mode: verify against an existing branch.

A /feature run covers planning, implementation, review, and acceptance and returns a branch for integration. Verification results can be included in a pull-request report, printed with nomarmy stats --share, or represented by a README badge created with nomarmy stats --badge.

How it works

The nomArmy MCP server creates a Git worktree and starts the worker inside a Podman sandbox. The default execution model has no network access and does not expose host credentials, with the README noting a specific exception for a Claude subscription. Supported repository harnesses cover Go, Rust, Python, Node, mixed repositories, Playwright browser tests, and fake services such as a mock login server.

After the worker finishes, nomArmy reads the real diff instead of relying on the worker's description. It runs the configured tests in a new sandbox, then reverts the production change and runs those tests again. If the tests still pass after the change is removed, the result goes to review rather than being committed. Secret detection, suspicious test weakening, and code that nothing calls can also block or flag work.

Repository policy is stored in .nomarmy.yml. For new repositories, the policy is enabled by default and makes verification and the revert check mandatory for each job. Optional validators add review flags for mutation testing, Jev-based evidence checks, and a model judge; they do not replace the core verification process.

Setup and configuration

Install Git, Node 24.16 or later (or Node 26.1 or later), and Podman. On macOS, the documented setup gives the Podman machine 8 GiB of memory. Windows uses the container engine through WSL2. A supported coding client must also be installed and signed in.

Install the package globally, change to a project directory, and run:

npm install -g nomarmy
nomarmy setup

The setup command presents the next configuration step and can resume after being stopped. It can configure hosted agents, repository settings, and installation checks. Claude Code users can instead install the provided plugin; Codex is also listed as supporting the plugin path. nomarmy doctor checks the machine, nomarmy health checks nomArmy's running components, nomarmy update upgrades it, and nomarmy sizing helps assess local-model hardware.

Agents may use hosted APIs, subscriptions, another OpenClaw provider, or a local llama.cpp model. A shared model server and Bedrock are also documented installation options. The project identifies itself as beta software at version 0.1.0-beta, so configuration compatibility should be considered during upgrades.

Tools and capabilities

• Delegate implementation and review work to configured agents and roles.
• Run end-to-end /feature workflows.
• Verify an existing branch without launching a worker.
• Execute repository-specific tests in isolated harnesses.
• Check test effectiveness by rerunning after reverting the change.
• Detect secrets and suspicious test or code changes.
• Produce shareable verification statistics and badges.

Limitations and notes

Verification does not automatically merge changes into the current branch. Delegation can use substantially more General-agent tokens than directly fixing a small, already-diagnosed issue; the README reports a measured range of four to eight times more tokens in such cases. Local models avoid per-token charges but require suitable hardware and may trade speed for cost. Failing verification remains failed, while malformed worker reports may be recovered when independent checks find valid repository changes.