claude-concilium
This server integrates with OpenAI via the Codex CLI, enabling general chat interactions and automated code reviews as part of a multi-agent consultation workflow.
openai_chat: Send arbitrary text prompts to OpenAI with configurable working directory (cwd), model override, and timeout (default 90s). Returns structured error responses for quota limits (e.g.,QUOTA_EXCEEDED), enabling fallback to other providers.openai_review: Perform automated code reviews on Git repositories with flexible targeting:Review uncommitted changes (default)
Review changes against a specific base branch
Review a specific commit by SHA
Provide custom review instructions (e.g., "Focus on error handling and race conditions")
Configurable timeout (default 120s) and working directory
Multi-agent use: Works alongside other LLM servers (Gemini, Qwen) within the Claude Concilium framework for diverse, multi-perspective AI consultations, or operates standalone as an MCP server.
Claude Concilium
Multi-agent AI consultation framework for Claude Code via MCP.
Get a second (and third) opinion from other LLMs when Claude Code alone isn't enough.
Claude Code ──┬── OpenAI (Codex CLI) ──► Opinion A
├── Gemini (gemini-cli) ─► Opinion B
│
└── Synthesis ◄── Consensus or iterateThe Problem
Claude Code is powerful, but one brain can miss bugs, overlook edge cases, or get stuck in a local optimum. Critical decisions benefit from diverse perspectives.
Related MCP server: personal-mcp
The Solution
Concilium runs parallel consultations with multiple LLMs through standard MCP protocol. Each LLM server wraps a CLI tool — no API keys needed for the primary providers (they use OAuth).
Key features:
Parallel consultation with 2+ AI agents
Production-grade fallback chains with error detection
Each MCP server works standalone or as part of Concilium
Plug & play: clone,
npm install, add to.mcp.json
Architecture
┌─────────────────────────────────────────────────────────┐
│ Claude Code │
│ │
│ "Review this code for race conditions" │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ MCP Call #1 │ │ MCP Call #2 │ (parallel) │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
└─────────┼──────────────────┼──────────────────────────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ mcp-openai │ │ mcp-gemini │ Primary agents
│ (codex exec)│ │ (gemini -p) │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ OpenAI │ │ Google │ LLM providers
│ (OAuth) │ │ (OAuth) │
└──────────────┘ └──────────────┘
Fallback chain (on quota/error):
OpenAI → Qwen → DeepSeek
Gemini → Qwen → DeepSeekQuickstart
1. Clone and install
git clone https://github.com/spyrae/claude-concilium.git
cd claude-concilium
# Install dependencies for each server
cd servers/mcp-openai && npm install && cd ../..
cd servers/mcp-gemini && npm install && cd ../..
cd servers/mcp-qwen && npm install && cd ../..
# Verify all servers work (no CLI tools required)
node test/smoke-test.mjsExpected output:
PASS mcp-openai (Tools: openai_chat, openai_review)
PASS mcp-gemini (Tools: gemini_chat, gemini_analyze)
PASS mcp-qwen (Tools: qwen_chat)
All tests passed.2. Set up providers
Pick at least 2 providers:
Provider | Auth | Free Tier | Setup |
OpenAI |
| ChatGPT Plus weekly credits | |
Gemini | Google OAuth | 1000 req/day | |
Qwen | OAuth or API key | Varies | |
DeepSeek | API key | Pay-per-use (cheap) |
3. Add to Claude Code
Copy config/mcp.json.example and update paths:
# Edit the example with your actual paths
cp config/mcp.json.example .mcp.json
# Update "/path/to/claude-concilium" with actual pathOr add servers individually to your existing .mcp.json:
{
"mcpServers": {
"mcp-openai": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/servers/mcp-openai/server.js"],
"env": {
"CODEX_HOME": "~/.codex-minimal"
}
},
"mcp-gemini": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/servers/mcp-gemini/server.js"]
}
}
}4. Install the skill (optional)
Copy the Concilium skill to your Claude Code commands:
cp skill/ai-concilium.md ~/.claude/commands/ai-concilium.mdNow use /ai-concilium in Claude Code to trigger a multi-agent consultation.
MCP Servers
Each server can be used independently — you don't need all of them.
Server | CLI Tool | Auth | Tools |
| OAuth (ChatGPT Plus) |
| |
| Google OAuth |
| |
| OAuth / API key |
|
DeepSeek uses the existing deepseek-mcp-server npm package — no custom server needed.
How It Works
Consultation Flow
Formulate — describe the problem concisely (under 500 chars)
Send in parallel — OpenAI + Gemini get the same prompt
Handle errors — if a provider fails, fallback chain kicks in (Qwen → DeepSeek)
Synthesize — compare responses, find consensus
Iterate (optional) — resolve disagreements with follow-up questions
Decide — apply the synthesized solution
Error Detection
All servers detect provider-specific errors and return structured responses:
Error Type | Meaning | Action |
| Rate/credit limit hit | Use fallback provider |
| Token needs refresh | Re-authenticate CLI |
| Qwen auth type not set | Set |
| Model unavailable on plan | Use default model |
Timeout | Process hung | Auto-killed, use fallback |
Fallback Chain
Primary: OpenAI ──────────────► Response
(QUOTA_EXCEEDED?)
│
Fallback 1: Qwen ──┴────────────► Response
(timeout?)
│
Fallback 2: DeepSeek ───────────► Response (always available)When to Use Concilium
Scenario | Recommended Agents |
Code review | OpenAI + Gemini (parallel) |
Architecture decision | OpenAI + Gemini → iterate if disagree |
Stuck bug (3+ attempts) | All available agents |
Performance optimization | Gemini (1M context) + OpenAI |
Security review | OpenAI + Gemini + manual verification |
Docker
Run any server in a container:
# Build
docker build -t claude-concilium .
# Run a specific server (mcp-openai | mcp-gemini | mcp-qwen)
docker run -i --rm -e SERVER=mcp-openai claude-concilium
docker run -i --rm -e SERVER=mcp-gemini claude-conciliumNote: The servers wrap CLI tools (codex, gemini, qwen) that require local authentication. Mount your auth credentials when running:
# OpenAI (Codex)
docker run -i --rm -e SERVER=mcp-openai \
-v ~/.codex:/root/.codex:ro \
claude-concilium
# Gemini
docker run -i --rm -e SERVER=mcp-gemini \
-v ~/.config/gemini:/root/.config/gemini:ro \
claude-conciliumCustomization
See docs/customization.md for:
Adding your own LLM provider
Modifying the fallback chain
MCP server template
Custom prompt strategies
Documentation
Architecture — flow diagrams, error handling, design decisions
OpenAI Setup — Codex CLI, ChatGPT Plus, minimal config
Gemini Setup — gemini-cli, Google OAuth
Qwen Setup — Qwen CLI, DashScope
DeepSeek Setup — API key, npm package
Customization — add your own LLM, modify chains
Changelog
v2.0.0 (2026-03-02)
mcp-qwen:
Prompt delivery via stdin (
-p -) instead of command argument — safe for any content, no length limitsOAuth auth-type support via
QWEN_AUTH_TYPEenv var (e.g.,qwen-oauth)New error detection:
AUTH_NOT_CONFIGURED(catches "no auth type is selected")Graceful shutdown handler (SIGTERM)
mcp-openai:
Default timeout increased from 90s to 180s (codex exec can be slow on complex prompts)
All servers:
Version bumped to 2.0.0
Updated documentation and setup guides
v0.1.0 (2025-12-15)
Initial release with 3 MCP servers (OpenAI, Gemini, Qwen)
Concilium skill with fallback chains
Smoke test suite
Docker support
License
MIT
Available Tools
2 toolsopenai_chatA
Send a prompt to OpenAI via Codex exec. Non-interactive, fast startup (no MCP servers loaded), 180s default timeout. Returns clear error on quota limits. For code review, use openai_review instead.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt to send | |
| model | No | Model override (optional). Note: some models may not be available on ChatGPT Plus | |
| timeout | No | Timeout in seconds (default 180) | |
| cwd | No | Working directory for codex |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-interactive nature, fast startup, 180s timeout, and clear error handling on quota limits. Lacks minor details like return format, but overall strong given no annotations.
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?
Three sentences, each providing essential information without redundancy or fluff.
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?
Covers key aspects: purpose, behavior, timeout, error handling, and alternative. Lacks output format details, but sufficient for a simple prompt tool.
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 coverage is 100% with parameter descriptions, and the description adds no additional semantics beyond restating the default timeout.
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?
Clearly states the tool sends a prompt to OpenAI via Codex exec, and distinguishes from sibling openai_review by specifying not to use for code review.
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?
Explicitly mentions when to use (non-interactive, fast startup) and specifies an alternative for code review (openai_review), providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openai_reviewA
Code review via Codex review (non-interactive). Reviews uncommitted changes or changes against a base branch.
| Name | Required | Description | Default |
|---|---|---|---|
| instructions | No | Custom review instructions (e.g., 'Focus on error handling and race conditions') | |
| uncommitted | No | Review uncommitted changes (default true) | |
| base | No | Review against this base branch | |
| commit | No | Review a specific commit SHA | |
| timeout | No | Timeout in seconds (default 120) | |
| cwd | No | Working directory (git repo root) |
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. It correctly notes that the tool is 'non-interactive' and reviews code changes, but does not disclose whether it is read-only, what side effects exist, or any authorization requirements. Some behavioral context is given but insufficient for full transparency.
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?
The description is a single concise sentence that conveys the core functionality. It is front-loaded and efficient, though it could be slightly expanded to include output or usage guidance without losing brevity.
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?
The description adequately explains the tool's basic use but lacks details about return values (no output schema), how parameters interact (e.g., combining 'uncommitted' with 'base'), and any prerequisites. Given the complexity of 6 parameters and missing annotations, the description is somewhat incomplete.
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?
With 100% schema description coverage, the schema already documents each parameter. The description only adds the context of reviewing uncommitted changes or against a base branch, which partially maps to the 'uncommitted' and 'base' parameters. No additional parameter details are provided beyond the schema.
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 clearly states it is a code review tool using Codex, non-interactive, and specifies the scope (uncommitted changes or against a base branch). This effectively distinguishes it from the sibling 'openai_chat' which is presumably for interactive chat.
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 implies usage for automated code review, but does not explicitly state when not to use it or provide alternatives. The sibling name 'openai_chat' suggests an alternative for interactive tasks, but this is not stated.
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.
1 tool update
v2.0.0- Changed
openai_chat2 fields changed- changed
Input schema / properties / timeout / defaultPrevious value: -90New value: +180 - changed
Input schema / properties / timeout / descriptionPrevious value: -"Timeout in seconds (default 90)"New value: +"Timeout in seconds (default 180)"
2 tool updates
v1.0.0- First observed
openai_chat - First observed
openai_review
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: openai_chat for general prompts and openai_review specifically for code reviews. The description of openai_chat explicitly directs users to openai_review for code review, eliminating any ambiguity.
Both tools follow a consistent pattern: openai_ prefix with a descriptive verb/noun (chat, review). The naming style is uniform and predictable.
With only 2 tools, the server feels minimal but acceptable for a focused purpose (quick, non-interactive OpenAI access). The count is on the low end, but the scope is clearly limited.
The server covers two core use cases: general chat and code review. However, lacking features like model listing, parameter configuration, or other common OpenAI operations leaves notable gaps for a broader 'concilium' purpose.
Maintenance
Related MCP Connectors
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
LLM Orchestration MCP Agent
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server orchestrating local CLI agents (Claude Code, OpenAI Codex, Google Gemini) for cross-validation, second opinions, and persona-driven prompting.18MIT
- FlicenseNot gradedqualityAmaintenanceMCP server that bridges coding agents (Claude Code, Codex, Gemini CLI) via ACP for pair programming, enabling agents to consult each other as tools.3-
- AlicenseNot gradedqualityDmaintenanceAn MCP bridge that enables Claude Code to consult the Kimi AI model in a structured challenge-loop for code review, debugging, and architecture evaluation.15 npm2MIT

polydevofficial
AlicenseNot gradedqualityDmaintenanceQuery GPT-5, Claude, Gemini, and Grok simultaneously through one MCP server for multi-model AI perspectives in your coding agents.98 npmMIT