PluginBench
MCP Server
Active

Forge Orchestrator MCP Server

io.github.nxtg-ai/forge-orchestrator

Orchestrate Claude Code, Codex, and Gemini on shared repos with file locking and multi-tool coordination.

What is the Forge Orchestrator MCP server?

The Forge Orchestrator MCP server coordinates multiple AI coding tools (Claude Code, Codex CLI, Gemini CLI) working on the same repository. It provides file locking, task planning, knowledge capture, and drift detection to prevent conflicts and maintain alignment across tools. Exposes 11 MCP tools via stdio for orchestration state and governance.

Forge Orchestrator solves the multi-tool coordination problem: when Claude Code, Codex, and Gemini work on the same codebase without shared state, they conflict like uncoordinated teams. This server adds orchestration infrastructure—file locking, task planning, knowledge flywheel, and drift detection—so multiple AI agents can safely collaborate on shared repositories. It's a single 4.7 MB Rust binary with zero runtime dependencies.

How to install Forge Orchestrator

Copy-paste configuration for popular MCP clients.

transport: stdio
Config generated by PluginBench — verify against the source before use.
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "forge-orchestrator": {
      "command": "https://github.com/nxtg-ai/forge-orchestrator/releases/download/v1.6.0/forge-mcp-server-linux-x86_64.tar.gz",
      "args": []
    }
  }
}

Tools & capabilities

Tools this server exposes to the agent.

  • File locking — Exclusive locks prevent multiple tools from editing the same file simultaneously, with timeout and deadlock detection
  • Task planning — Generates dependency-aware task graphs from specifications and decomposes work across tools
  • Knowledge capture — Auto-classifies and stores decisions, patterns, and learnings across tool sessions for reuse
  • Drift detection — Compares in-progress work against specifications and flags divergence early
  • Task board — Tracks dependency-aware tasks, tool assignments, and progress monitoring
  • Multi-tool adapters — Integrates Claude Code (MCP stdio), Codex CLI, and Gemini CLI through unified orchestration
  • Status and state queries — Exposes current orchestration state, lock status, and project health via MCP tools
  • Plan generation — Converts SPEC.md or README into structured task graphs with tool assignments
  • Headless execution — Autonomous mode for CI/CD pipelines via `forge run` command
  • TUI dashboard — Live monitoring of tool panes, task status, and lock state via `forge dashboard`
  • Verification and UAT — Automated acceptance testing and interactive UAT test runner

Use cases

  • Coordinate three AI coding tools on the same codebase without file conflicts or lost work
  • Generate task plans from specifications and automatically assign work across Claude Code, Codex, and Gemini
  • Capture architectural decisions and coding patterns so knowledge persists across multiple tool sessions
  • Detect when in-progress changes diverge from specifications and alert tools early
  • Run autonomous multi-tool development workflows in CI/CD pipelines with `forge run`

Forge Orchestrator MCP server FAQ

What is the Forge Orchestrator?

It's an MCP server that orchestrates multiple AI coding tools (Claude Code, Codex CLI, Gemini CLI) working on the same repository. It prevents file conflicts through locking, generates task plans, captures knowledge, and detects drift from specifications.

Is Forge Orchestrator free?

Forge is source-available under the Functional Source License 1.1 (FSL-1.1-ALv2), converting to Apache License 2.0 on 2028-03-18. The binary is free to use.

How do I install it?

Run `curl -fsSL https://forge.nxtg.ai/install.sh | sh` to install the single 4.7 MB binary. Then `forge init` to initialize a project. Pre-built binaries are available for Linux x86_64, macOS aarch64, and Windows x86_64.

Does it require authentication?

The orchestrator itself has no external auth. It can use an OpenAI API key for the planning brain (optional; rule-based mode is free). Each connected tool (Claude Code, Codex, Gemini) manages its own credentials.

How does it prevent file conflicts?

It uses exclusive file locks in `.forge/locks/` with timeout and deadlock detection. When one tool edits a file, others are queued with notifications of who holds the lock.

Can I use it with just one AI tool?

Yes, but it's designed for multi-tool scenarios. Single-tool use still benefits from task planning, knowledge capture, and drift detection.

README (reference)

Source of truth, from the repository.

<p align="center"> <img src="assets/forge-logo.png" alt="Forge" width="120"> </p>

forge-orchestrator

MCP Registry License: MIT Version CI GitHub stars crates.io

Orchestrate Claude Code, Codex CLI, and Gemini CLI on shared repos — single Rust binary, zero deps.

Multi-agent inside a single tool works fine. Claude Code runs 20 subagents and they stay aligned because the tool manages that orchestration internally. The problem is multi-tool: Claude Code, Codex CLI, and Gemini CLI on the same repo with no shared state. That's what the orchestrator solves.

It adds file locking, knowledge capture, task planning, drift detection, and multi-tool orchestration to your development workflow. Three tools reading from and writing to a single state directory. An 11-tool MCP server exposes the full orchestration state to any connected AI client.

The orchestrator exists because I ran two AI tools on the same codebase and watched them fail in the same ways human teams fail. Claude refactored a module. Codex updated tests against the pre-refactor interface. Both saved. Tests failed. Neither tool knew the other existed. I'd spent 23 years watching this exact scenario with talented human teams. The solution was always the same: orchestration infrastructure.

Install

curl -fsSL https://forge.nxtg.ai/install.sh | sh
forge init

Single binary. 4.7 MB. No runtime dependencies.

Quick Demo

Four commands from zero to task board:

# 1. Initialize — creates .forge/ directory with state, event log, knowledge base
forge init

# 2. Configure the AI brain — choose 'openai' (needs API key) or 'rule-based' (free)
forge config brain openai

# 3. Generate tasks — reads your SPEC.md or README, creates dependency-aware task graph
forge plan --generate

# 4. See the result — task board with assignments, dependencies, and project health
forge status

From here you can:

  • forge run — execute tasks headlessly (autonomous mode, great for CI)
  • forge dashboard --pty — launch the TUI dashboard with interactive agent panes

Real-World Result: Stargate Mode

From a 94-line specification, the orchestrator coordinated three AI coding tools to build a complete CLI toolkit:

SPEC.md (94 lines) → forge plan --generate → 15 tasks

Claude Code:  6 design tasks     → completed
Codex CLI:    6 implementation   → completed
Gemini CLI:   3 test/doc tasks   → completed

Result: 5,306 lines of working code
        10 auto-committed git entries
        13 Python files (CLI + tests)
        Zero file conflicts

Three companies. Three tools. One orchestrator. One command:

forge dashboard --pty

What You Get

FeatureWhat It Does
File lockingExclusive locks prevent tools from editing the same file simultaneously
Knowledge flywheelCaptures decisions, patterns, learnings across tools. Auto-classified and searchable.
Plan generationforge plan --generate decomposes specs into dependency-aware task graphs
Drift detectionCompares in-progress work against specs, flags divergence early
Task boardDependency-tracked tasks, tool assignment, progress monitoring
Multi-tool adaptersClaude Code (MCP stdio) + Codex CLI + Gemini CLI (filesystem)
TUI dashboardforge dashboard: live tool panes, task status, lock state
Headless modeforge run: autonomous execution for CI/CD pipelines
MCP server11 tools accessible by any connected AI tool via stdio

Key Commands

forge init                     # Initialize Forge in a project
forge plan --generate          # Generate task plan from spec
forge dashboard                # Live TUI dashboard
forge dashboard --pty          # TUI with interactive agent panes (Stargate)
forge run                      # Headless autonomous mode
forge status                   # Current state summary
forge verify                   # Run automated acceptance tests
forge uat                      # Interactive UAT test runner
forge ship                     # Release ceremony: changelog, archive, tag

Architecture

The orchestrator is the policy core of Forge. All governance rules, file locks, and orchestration logic live here. The plugin (L1: Vibe Coder) and UI (L3: Ship Lord) are adapter surfaces. They present the orchestrator's state through different interfaces but don't make policy decisions.

┌──────────────────────────────────────┐
│        forge-orchestrator            │
│        (Rust, 4.7 MB, 378 tests)      │
│                                      │
│  File locking · Task planning        │
│  Knowledge · Governance · MCP        │
│  Multi-tool adapters                 │
│                                      │
│  Policy enforced here.               │
│  Nowhere else.                       │
└───────────┬──────────────────┬───────┘
            │                  │
   ┌────────┴────────┐  ┌────┴────────┐
   │  forge-plugin   │  │  forge-ui   │
   │  (L1 Safety)    │  │  (L3 MC)    │
   │  Claude Code    │  │  React      │
   │  adapter        │  │  dashboard  │
   └─────────────────┘  └─────────────┘

Communication: .forge/ filesystem + MCP stdio. No daemon. No database. State is files.

Tool adapters: Claude Code uses MCP stdio. Codex CLI and Gemini CLI use filesystem conventions. Each tool reads its own config format. No Forge-specific configuration language.

How File Locking Works

File locking exists because I've watched teams lose days to conflicting edits.

When Claude Code starts editing a file, the orchestrator acquires an exclusive lock in .forge/locks/. Codex CLI requesting the same file is queued with a notification of who holds the lock. Locks include timeouts (crashed tools don't hold locks forever) and deadlock detection.

378 tests cover concurrent access, timeout behavior, multi-adapter locking, and edge cases.

How the Knowledge Flywheel Works

The knowledge flywheel exists because I've watched decisions evaporate between sprints.

Every decision, pattern, and learning from tool sessions is captured in .forge/knowledge/. Entries are auto-classified by category. Search across sessions and across tools. Knowledge captured during a Claude Code session is available to Codex CLI the next day.

After a week, the system knows your conventions better than you remember them. New sessions start with context instead of from scratch.

Upgrade Path

The TUI dashboard shows everything. Forge UI shows it better.

Visual dashboards. Governance HUD. Real-time agent collaboration network. And the Infinity Terminal: sessions that survive browser close, network drops, and server restarts. If you've lost a 3-hour agent session to a disconnected SSH pipe, you know why this matters.

git clone https://github.com/nxtg-ai/forge-ui && npm install && npm run dev

58 components. 4,165 tests. 87% coverage.

Links

License

Source available under the Functional Source License 1.1 (FSL-1.1-ALv2). Converts to Apache License 2.0 on 2028-03-18. See LICENSE.md for full terms.

Related MCP servers

MUMukoko News logo

Mukoko News

Maintained

Pan-African news & analytics for Zimbabwe and 15 African countries: briefings and trends.

1
TypeScript
View repository →

Read-only MCP over the Mzizi design system registry — nodes, components, ownership.

View repository →

Search, read, and ask the Nyuchi docs (docs.nyuchi.com); send feedback or raise issues.

0
MDX
View repository →

Free scam checks for links, wallets, emails, and breach exposure. No signup.

Breach, SIM swap, infostealer, domain lookalikes, MCP registry risk, prompt-injection detection.

0
Python
View repository →
FIFigma MCP Server logo

MCP server enabling AI assistants to interact with Figma designs via natural language commands

1
JavaScript
ISC
View repository →