Skip to main content
Glama

MergeLoop

MergeLoop Wordmark

One prompt. Many models. One answer.

MergeLoop is a host-agnostic model council for MCP, CLI, and optional API workers. It routes tasks across selected workers and returns one unified answer.

Bring your own host. Bring your own workers. Use your subscriptions first, then add API adapters only when you need them. MergeLoop is not Claude-only, not limited to fixed built-in workers, and not a quota bypass. Provider and host quotas still apply.

MergeLoop Hero

Static fallback: docs/demo/hero-static.svg

Quick links: Quickstart · Setup · Gemini · Ollama · Integrations

Get Started

npm ci
npm run build
npm run setup
npm run doctor

Most common local stack: Gemini + Ollama first, Codex when you want code-level review.

Related MCP server: CLI Agent MCP

Run:

npm run setup

Setup wizard features:

  • detects local CLIs (codex, gemini, ollama, claude)

  • helps choose host + workers + routing style

  • writes/merges mergeloop.settings.json

  • can auto-merge mergeloop MCP entry into selected host config

  • creates timestamped backups before file changes

  • runs doctor + smoke at the end (unless dry-run)

Auto-config status:

  • first-class auto-config: Gemini settings

  • experimental auto-config: Antigravity config

  • documented/manual via template write: generic MCP JSON

  • manual start command: Claude Code plugin path

Common host-specific setup commands:

# Gemini settings auto-config
npm run setup -- --yes --host=gemini --workers=gemini,ollama,codex

# Antigravity MCP config auto-config
npm run setup -- --yes --host=antigravity --workers=gemini,ollama,codex

# Repo-local generic MCP config for safe testing
npm run setup -- --yes --host=generic --workers=gemini,ollama,codex

For Cursor, Windsurf, OpenClaw, VS Code, Zed, Neovim, and JetBrains, use the generic/manual integration path after setup. MergeLoop can still be used there, but those hosts are template/manual integrations in this repo, not auto-written first-class host configs.

Useful flags:

npm run setup -- --dry-run
npm run setup -- --yes --host=gemini --workers=gemini,ollama,codex

Safe repo-local first run:

npm run setup -- --yes --host=generic --workers=gemini,ollama,codex

That path writes mergeloop.settings.json and .mcp.json inside the repo so you can validate setup before touching home-directory host configs.

Docs:

Why This Exists

Most teams already pay for multiple model subscriptions and run local tools, but still operate them one-at-a-time. MergeLoop adds a single orchestration layer so one prompt can produce:

  • parallel worker outputs

  • explicit agreement/disagreement signals

  • a merged recommendation and next verification checks

What MergeLoop Is

  • An MCP-native orchestration runtime (mergeloop-hub)

  • A host-agnostic middle layer (not tied to one editor/agent)

  • A worker registry with discovery + routing heuristics

  • A runtime that can combine MCP servers, CLI workers, local runtimes, and optional API adapters

  • A bundled Claude Code plugin path in this repo (without making Claude the only host path)

What Makes MergeLoop Different?

Many workflows force everything through one provider or one model path. MergeLoop keeps hosts and workers separate, so one request can combine:

  • MCP-connected workers

  • CLI workers (for example Codex CLI and Gemini CLI)

  • local runtimes like Ollama

  • optional API workers when you choose to add them

This is practical for teams already paying for subscriptions and running local tooling. You can start subscription-first and local-first, then add API adapters only if and when they help.

What MergeLoop Is Not

  • Not a quota bypass

  • Not a credential harvester

  • Not a guarantee of universal IDE/agent compatibility

  • Not an official adapter for providers that are only listed as planned

How It Works

  1. A host sends task, mode, and optional worker hints to mergeloop_run.

  2. MergeLoop builds a worker registry from built-ins, config-defined workers, and discovery candidates.

  3. Router scores workers against task profile (coding/research/planning/privacy).

  4. Selected workers run in parallel.

  5. MergeLoop returns one output bundle: results, synthesis_inputs, disagreements, recommended_next_checks.

Workflow visuals:

Hosts vs Workers

  • Host: where the user starts work (Claude Code, generic MCP host, CLI wrapper).

  • Worker: execution target MergeLoop calls (Codex CLI, Gemini CLI, Ollama, custom CLI/MCP/API worker definitions).

  • MergeLoop Core: the orchestration layer between host and workers.

  • Worker selection is registry + routing based, not locked to a fixed worker list.

Details: docs/architecture.md

Supported Today / Manual / Experimental / Planned

First-Class

  • MergeLoop core runtime + MCP server

  • Claude Code plugin bundle in this repo

  • Built-in CLI workers: codex, gemini, local, ollama

Manual (Documented Templates)

  • VS Code, Cursor, Windsurf, OpenClaw templates

  • Zed, Neovim, JetBrains manual integration docs

  • Generic MCP host registration

Experimental

  • API worker model in config (not the default path)

  • Community worker templates requiring local validation

Planned

  • Additional first-class host adapters beyond current plugin bundle

  • Additional verified worker adapters when implemented and tested

  • Perplexity host path only after a real tested adapter lands

Support matrix visual: docs/demo/support-matrix.svg

Quickstart (Windows/macOS/Linux)

Requirements:

  • Node.js 20+

  • At least one worker CLI installed/authenticated (for example codex, gemini, or ollama)

npm ci
npm test
npm run build
npm run smoke

Check environment:

npm run doctor

If doctor fails only because vendor CLIs are missing, install/auth those CLIs or disable those workers in config. Missing worker CLIs are external local dependency checks, not MergeLoop build failures.

Windows note: native Node is supported. WSL is recommended if your worker CLIs are Linux-first.

Fast Local Test: Codex + Gemini + Ollama

  1. Install/build:

npm ci
npm run build
npm run smoke
  1. Ensure Gemini CLI is authenticated (run gemini once if needed to complete login/auth).

  2. Ensure Ollama is running and a model is available:

ollama pull qwen3:latest
ollama serve
  1. Validate local workers:

npm run doctor
  1. Add MergeLoop to Gemini MCP config (~/.gemini/settings.json):

{
  "mcpServers": {
    "cloudrun": {
      "command": "npx",
      "args": ["-y", "@google-cloud/cloud-run-mcp"]
    },
    "mergeloop": {
      "command": "node",
      "args": ["D:/Ideas/MergeLoop/dist/server.js"]
    }
  }
}
  1. Restart/reload Gemini, then prompt:

Use mergeloop.mergeloop_run in council mode with workers gemini, local, codex.
Task: review this migration plan and return disagreements plus next checks.

Guides:

Claude Code Quickstart

claude --plugin-dir .

From the parent directory instead:

claude --plugin-dir ./MergeLoop

Plugin files:

Other Host Integration Paths

Generic MCP Host

{
  "mcpServers": {
    "mergeloop-hub": {
      "command": "node",
      "args": ["/absolute/path/to/MergeLoop/dist/server.js"]
    }
  }
}

Gemini Host Path (documented/manual)

Gemini MCP settings file: ~/.gemini/settings.json

Guide:

VS Code (documented/manual)

Template: integrations/vscode/mcp.json

Cursor (documented/manual)

Template: integrations/cursor/mcp.json Recommended path: run npm run setup -- --yes --host=generic --workers=gemini,ollama,codex, then adapt the generated/local MCP entry into your Cursor config using the template above.

Windsurf (documented/manual)

Template: integrations/windsurf/mcp_config.json Recommended path: run npm run setup -- --yes --host=generic --workers=gemini,ollama,codex, then copy the MergeLoop MCP entry into your Windsurf config.

OpenClaw (documented/manual)

Guides/templates:

Zed (documented/manual)

Template: integrations/zed/settings.json

Neovim (documented/manual)

Guide: integrations/neovim/README.md

JetBrains (documented/manual)

Guide: integrations/jetbrains/README.md

Manual/template integrations require local host verification; see integrations/README.md for tested scope and known-good local test steps.

Configuration Model

Primary file: mergeloop.settings.json

Top-level sections:

  • active_host

  • hosts

  • workers

  • discovery

  • routing

  • legacy compatibility fields (codex_command, worker_registry, custom_workers, etc.)

Read more:

How Discovery Works

  • Reads configured MCP config files and CLI candidate lists.

  • Requires explicit metadata hints when require_worker_metadata is enabled.

  • Applies include/exclude/disabled rules.

  • Merges built-in, discovered, and manual workers into one typed registry.

How Routing Works

  • Classifies each task (coding/research/planning/sensitive/general).

  • Scores workers by role tags, privacy mode, cost hint, fallback order, and health.

  • Selects one worker (single) or top workers (council) without blasting every worker by default.

mergeloop_run Example

{
  "task": "Review this migration plan and list rollback risks.",
  "mode": "council",
  "workers": ["codex", "gemini", "ollama"],
  "output_format": "json"
}

Example Unified Output (short)

{
  "results": [{ "worker_name": "codex" }, { "worker_name": "gemini" }, { "worker_name": "ollama" }],
  "synthesis_inputs": [{ "worker_name": "codex" }, { "worker_name": "gemini" }, { "worker_name": "ollama" }],
  "disagreements": ["gemini flagged rollback risk not covered by codex"],
  "recommended_next_checks": ["run rollback drill in staging", "verify migration checksum diff"]
}

Why Not Just Use One Model?

For low-risk tasks, one model is often enough. For higher-impact work, council mode gives cross-checking, disagreement visibility, and concrete verification steps before action.

What Happens If Claude Is Capped?

Use another configured host path. MergeLoop is host-agnostic, but each host and worker still has its own limits and policies.

Use Your Subscriptions First, API Optional

MergeLoop is designed for subscription-first and local-runtime-first workflows. Use your subscriptions first. Add APIs only when you want or need them. For many workflows, direct API setup is optional, not required. Host and provider quotas still apply.

Perplexity / Future Hosts

Perplexity is not listed as supported in this repo today. It is only a planned target until a tested adapter is implemented and documented here.

Ollama Local Path

Ollama is a first-class local worker in MergeLoop. It can be used for privacy-sensitive tasks and as a fallback in council mode. Default public config uses local as a compatibility alias backed by local_command: "ollama run qwen3:latest".

Guide: docs/ollama.md

Daena Add-On Mode

MergeLoop can run as an orchestration middle layer for Daena.

  1. Daena sends one task to mergeloop_run.

  2. MergeLoop routes and runs selected workers.

  3. Daena consumes disagreements and next-check suggestions.

Examples:

Security, Trust, and Compliance

  • Worker CLIs must be installed/authenticated separately.

  • MergeLoop does not scrape credentials or imitate vendor auth.

  • MergeLoop orchestrates workers; it does not mint extra quota.

  • Discovery is metadata-driven; not every MCP server is automatically treated as a worker.

See:

Limitations and Known Constraints

  • Worker quality and uptime depend on local environment and external CLIs.

  • Some host integrations are manual templates, not end-to-end verified adapters.

  • API worker adapter is configuration-ready but not the core runtime path.

  • Capability metadata is explicit; MergeLoop does not infer full behavior from arbitrary MCP servers.

Demo Assets

Demo Preview Workflow Discovery and Routing Support Matrix Output Example

Storyboard demo:

Static demo preview:

Contributing and Roadmap

License

Apache-2.0. See LICENSE.

Available Tools

1 tool
mergeloop_runA

Run one or more local model CLIs in single or council mode, capture outputs, identify disagreements, and return a synthesis-ready bundle.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYesUse one worker or run the selected workers in parallel.
taskYesTask prompt to send to the selected workers.
workersNoOptional worker order. Built-ins include codex, gemini, local, ollama. You can also use discovered/manual workers from configuration.
output_formatNoControls the text rendering returned alongside structured output.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosing behavior. It transparently outlines the operational pipeline: running CLIs, capturing outputs, identifying disagreements, and returning a bundle. However, it does not disclose potential side effects such as spawning external processes, resource consumption, failure modes, or prerequisite setup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence captures all essential behavior with no filler. Every phrase contributes a new piece of meaning: execution, mode options, output handling, and return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity of 4 parameters with 2 enums and no output schema, the description sufficiently conveys the tool's purpose and outcome. It mentions the synthesis-ready bundle, which serves as the return-value context, and the schema covers parameter choices. Minor gaps remain around default worker behavior and execution times, but the core invocation is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description is not required to add parameter-level meaning. It reinforces the mode semantics ('single or council') and the output purpose ('synthesis-ready bundle'), but does not add information beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Run') with a clear resource ('local model CLIs'), and enumerates distinct behaviors: single/council mode, capturing outputs, identifying disagreements, and returning a synthesis-ready bundle. This precisely defines the tool's scope despite the absence of sibling tools to differentiate from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys clear usage context by defining the two modes ('single or council') and the intended purpose ('capture outputs, identify disagreements'). There are no explicit exclusions or alternative tools listed, but since no siblings exist, the guidance is clear for the available context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedmergeloop_run

TDQS

A4.1/5.0
Disambiguation5/5

With only one tool in the set, there is no possibility of confusing it with another. The single tool's purpose is clear and distinct simply because it is the only entry point.

Naming Consistency5/5

The single tool name follows a clear server_action pattern ('mergeloop_run'). With only one tool, there are no internal inconsistencies or mixed conventions to confuse the naming scheme.

Tool Count3/5

One tool for this narrow orchestration workflow is borderline but workable. However, the tool bundles multiple responsibilities (running, capturing, detecting disagreements, bundling) that could benefit from being split into smaller, more granular tools.

Completeness4/5

The tool covers the core workflow of running local model CLIs and producing a synthesis-ready bundle. Minor gaps exist around inspecting past runs or customizing the synthesis process, but these are acceptable given the tight scope.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    Orchestrates multiple AI models (Gemini, OpenAI, Claude, local models) within a single conversation context, enabling collaborative workflows like multi-model code reviews, consensus building, and CLI-to-CLI bridging for specialized tasks.
    -
  • A
    license
    A
    quality
    F
    maintenance
    Provides unified access to multiple CLI AI agents (Codex, Gemini, Claude, and OpenCode) through a single MCP interface with real-time task monitoring, enabling specialized code analysis, UI design, implementation, and prototyping workflows.
    11
    21
    MIT
  • A
    license
    B
    quality
    F
    maintenance
    Enables orchestrating multiple AI CLI agents (Claude Code, Codex, Gemini CLI, Copilot CLI) through a unified MCP interface for task delegation, cross-agent comparison, and specialized tools like code review and debugging.
    14
    13
    14
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Unified CLI multiplexer for AI coding agents, enabling orchestration of multiple coding CLI tools through a single interface with session persistence, cost tracking, and MCP tool support.
    15
    19
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mas-AI-Official/MergeLoop'

If you have feedback or need assistance with the MCP directory API, please join our Discord server