MergeLoop
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MergeLoopCompare AI responses to: explain quantum computing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MergeLoop
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.
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 doctorMost common local stack: Gemini + Ollama first, Codex when you want code-level review.
Related MCP server: CLI Agent MCP
Interactive Setup (Recommended)
Run:
npm run setupSetup wizard features:
detects local CLIs (
codex,gemini,ollama,claude)helps choose host + workers + routing style
writes/merges
mergeloop.settings.jsoncan auto-merge
mergeloopMCP entry into selected host configcreates timestamped backups before file changes
runs
doctor+smokeat 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,codexFor 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,codexSafe repo-local first run:
npm run setup -- --yes --host=generic --workers=gemini,ollama,codexThat 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
A host sends
task,mode, and optional worker hints tomergeloop_run.MergeLoop builds a worker registry from built-ins, config-defined workers, and discovery candidates.
Router scores workers against task profile (coding/research/planning/privacy).
Selected workers run in parallel.
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, orollama)
npm ci
npm test
npm run build
npm run smokeCheck environment:
npm run doctorIf 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
Install/build:
npm ci
npm run build
npm run smokeEnsure Gemini CLI is authenticated (run
geminionce if needed to complete login/auth).Ensure Ollama is running and a model is available:
ollama pull qwen3:latest
ollama serveValidate local workers:
npm run doctorAdd 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"]
}
}
}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 ./MergeLoopPlugin 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:
integrations/openclaw/mcp-server-template.json Recommended path: run
npm run setup -- --yes --host=generic --workers=gemini,ollama,codex, then use the OpenClaw template to register the same MCP server entry.
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_hosthostsworkersdiscoveryroutinglegacy 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_metadatais 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.
Daena sends one task to
mergeloop_run.MergeLoop routes and runs selected workers.
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
Storyboard demo:
regenerate with
npm run demo:renderexport PNG demo assets cross-platform with
npm run demo:export-png
Static demo preview:
Contributing and Roadmap
License
Apache-2.0. See LICENSE.
Available Tools
1 toolmergeloop_runA
Run one or more local model CLIs in single or council mode, capture outputs, identify disagreements, and return a synthesis-ready bundle.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Use one worker or run the selected workers in parallel. | |
| task | Yes | Task prompt to send to the selected workers. | |
| workers | No | Optional worker order. Built-ins include codex, gemini, local, ollama. You can also use discovered/manual workers from configuration. | |
| output_format | No | Controls the text rendering returned alongside structured output. |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
mergeloop_run
TDQS
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.
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.
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.
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
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
Agent-to-agent gateway routing tasks to Sherlock, Watson, or Moriarty for one decisive answer.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
- OctopadOAuthapp.octopad
The back-office workspace for your team's AIs: tasks, knowledge and context shared over MCP.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceOrchestrates 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.-
- AlicenseAqualityFmaintenanceProvides 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.1121MIT
- AlicenseBqualityFmaintenanceEnables 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.141314MIT
- AlicenseNot gradedqualityDmaintenanceUnified 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.1519MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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