Allows using any OpenAI-compatible API as a debate participant in multi-agent discussions.
Click on "Deploy 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., "@ai-discuss debate best order execution strategy for momentum bot"
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.
An MCP server that lets a host AI agent
(Claude Code, opencode, or Codex) trigger a multi-agent debate. The host
calls the discuss tool with a topic + code context; the server fans the
question out to several configured AI models, runs an N-round debate where the
agents critique and refine each other's answers, then a synthesizer produces a
consensus recommendation with ranked, scored options — and returns it so the
host can keep coding.
Models are reached through OpenAI-compatible providers — use OpenRouter (cloud: Claude, GPT, Gemini, DeepSeek, …), Ollama (local, keyless), or both at once in the same debate.
Claude Code / opencode / Codex ──MCP stdio──► ai-discuss
│ round loop (fan-out, timeouts, error isolation)
┌──────────────────────┼───────────────────┐
▼ ▼ ▼
OpenAICompatAdapter OpenAICompatAdapter Synthesizer
(OpenRouter / cloud) (Ollama / local) (a chosen participant)
│ │ │
└───────────────────────┴───► full markdown transcript on diskRound 1: each participant answers independently.
Rounds 2..N: each participant sees the others' previous answers (anonymized by default) and critiques / refines.
Synthesis: the synthesizer scores each option 0–100 and ranks them, with reasoning, consensus, and unresolved disagreements.
Output is returned three ways: a concise summary for the host agent, a
structuredContent object, and a complete markdown transcript written to disk.
Related MCP server: DebateTalk MCP
npm install
npm run buildCopy the example config and edit it:
cp ai-discuss.config.example.json ai-discuss.config.jsonThe config has a providers map (OpenAI-compatible endpoints) and a list of
participants that each pick a provider + model:
{
"providers": {
"openrouter": { "baseURL": "https://openrouter.ai/api/v1", "apiKeyEnv": "OPENROUTER_API_KEY" },
"ollama": { "baseURL": "http://localhost:11434/v1", "apiKeyEnv": null }
},
"participants": [
{ "id": "claude", "provider": "openrouter", "model": "anthropic/claude-sonnet-4" },
{ "id": "qwen-local", "provider": "ollama", "model": "qwen3.6" },
{ "id": "mock", "type": "mock", "enabled": false }
]
}participant | how it connects | key fields |
model | an OpenAI-compatible provider (default |
|
| deterministic echo — for credit-free testing |
|
API keys are never stored in config — a provider's apiKeyEnv names the
env var that holds the key. apiKeyEnv: null marks a keyless provider
(e.g. local Ollama).
An enabled participant whose provider needs a key that isn't set is skipped at runtime — it never crashes the run.
Add or swap a discussant by editing its model (see model ids via the
list_models tool, openrouter.ai/models, or
ollama list).
Top-level options: defaultRounds, defaultSynthesizer, transcriptDir,
perParticipantTimeoutMs, maxConcurrency, anonymizePeers, apiRetries.
The server is a standard stdio MCP server, so it works with any MCP host. Build
first (npm run build), then register. Set OPENROUTER_API_KEY if you use
OpenRouter; for Ollama just have ollama serve running (no key).
Claude Code — .mcp.json in the project, or:
claude mcp add ai-discuss --env OPENROUTER_API_KEY=sk-or-... \
-- node /absolute/path/to/Ai-discuss-mcp/dist/index.jsopencode — opencode.json:
{
"mcp": {
"ai-discuss": {
"type": "local",
"command": ["node", "/absolute/path/to/Ai-discuss-mcp/dist/index.js"],
"enabled": true,
"environment": { "OPENROUTER_API_KEY": "sk-or-..." }
}
}
}Codex — ~/.codex/config.toml:
[mcp_servers.ai-discuss]
command = "node"
args = ["/absolute/path/to/Ai-discuss-mcp/dist/index.js"]
env = { OPENROUTER_API_KEY = "sk-or-..." }discussfield | type | notes |
| string | required — the question/decision to debate |
| string? | code, constraints, background |
| string[]? | candidate approaches to rank (else participants propose their own) |
| number? | 1–6, defaults to config |
| string[]? | filter to these ids, defaults to all enabled |
| string? | participant id for synthesis, defaults to config |
| boolean? | default |
Returns recommendation, rankedOptions[{option, score, reasoning, risks}],
consensus, disagreements, participantsUsed, participantsFailed, rounds,
synthesizerId, degraded, and transcriptPath.
list_participantsLists configured participants (id, provider, model, enabled/available, default
synthesizer). Cheap — reads config only, no model calls. Useful before calling
discuss.
list_modelsQueries each configured provider for the model ids it can serve (OpenRouter
/models, Ollama /api/tags). Useful to discover valid model names. Optional
provider arg narrows to one provider.
Claude Code, after scaffolding a trading bot, calls:
{
"name": "discuss",
"arguments": {
"topic": "Choose an order-execution strategy for a momentum intraday stock bot to minimize slippage on mid-cap tickers.",
"context": "Python bot, Alpaca API, ~50 trades/day, $5k-$20k positions, currently naive market orders.",
"options": ["Market orders", "Marketable limit orders (5bps cap)", "TWAP over 60s", "Adaptive VWAP slices"],
"rounds": 3,
"synthesizer": "claude"
}
}The server returns a ranked recommendation and a transcript path, and the host continues editing the execution module.
npm run dev # tsx watch (no rebuild loop)
npm test # vitest unit suite (no network / no credits)
npm run inspect # MCP Inspector against the built server
npm run typecheck # tsc --noEmitSet every participant (including the synthesizer) to type: "mock" and run the
server through npm run inspect or any MCP client. The full pipeline runs,
writes a transcript, and returns valid structuredContent without any API
calls. (With mock participants the synthesizer can't emit JSON, so you'll see
degraded: true — that exercises the fallback path.)
Adapter pattern — the orchestrator only ever calls participant.ask(); it
never knows whether a participant is a real model or a mock. One
OpenAICompatAdapter serves every provider (OpenRouter, Ollama, …), differing
only by baseURL, optional key, and headers.
Error isolation — ask() never throws; failures are encoded in the
result. Each round fans out with Promise.allSettled + per-participant
timeout/abort, so one dead participant degrades but never aborts the run. A
participant that fails one round is still invited to the next.
Always-valid output — the synthesizer is asked for strict JSON, retried once, and finally falls back to a mechanical synthesis so the tool always returns schema-valid structured content.
stdout is sacred — all logging goes to stderr only; stdout carries the MCP JSON-RPC stream.
Fan out a topic + code context to configured AI participants, run an N-round debate where they critique and refine each other's answers, then return a synthesized, ranked recommendation. Writes a full markdown transcript to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The question or decision to debate, e.g. 'Choose an order-execution strategy for a momentum stock-trading bot.' | |
| rounds | No | Number of debate rounds. Round 1 = independent answers; rounds 2..N = critique/refine. Defaults to config. | |
| context | No | Code, constraints, data, or background the participants should consider. Paste relevant source here. | |
| options | No | Candidate options/approaches to evaluate and rank. If omitted, participants propose their own. | |
| synthesizer | No | Participant id to act as final synthesizer. Defaults to config.defaultSynthesizer. | |
| participants | No | Filter to these participant ids. Defaults to all enabled participants in config. | |
| writeTranscript | No | Whether to write the full markdown transcript to disk. Default true. |
| Name | Required | Description |
|---|---|---|
| rounds | Yes | |
| degraded | Yes | |
| consensus | Yes | |
| disagreements | Yes | |
| rankedOptions | Yes | |
| synthesizerId | Yes | |
| recommendation | Yes | |
| transcriptPath | No | |
| participantsUsed | Yes | |
| participantsFailed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool writes a transcript to disk (side effect) and outlines the debate process. Could mention permissions or error handling, but current detail is sufficient for basic understanding.
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?
Two sentences with no redundancy. First sentence covers core process and output, second notes transcript. Every word earns its place.
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?
For a tool with 7 parameters and an output schema, description explains workflow, output (ranked recommendation), and side effect (transcript). Lacks explicit mention of what output schema contains, but output schema covers that. Adequate given complexity.
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 baseline is 3. Description adds context by mapping 'topic+code context' to specific parameters and mentioning 'N-round debate' for rounds, but does not significantly enhance schema-provided meanings.
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?
Description clearly states the tool runs a multi-agent debate with specific actions: fan out topic+context, run N-round debate, critique/refine, return ranked recommendation, and write transcript. Distinguishes from sibling listing tools (list_models, list_participants).
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?
Description implies use for multi-agent discussion/debate but lacks explicit guidance on when not to use or alternatives. Siblings are listing tools, so context is clear, but no direct usage constraints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query each configured provider (OpenRouter, Ollama, ...) for the model ids it can serve. Useful to discover valid model names before editing the config or choosing participants.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Only query this provider (by name). Default: all configured providers. |
| Name | Required | Description |
|---|---|---|
| providers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the action (query), the scope (all configured providers by default), and the output (model ids). It does not discuss edge cases like unreachable providers or caching, but for a simple query tool, the disclosure is adequate.
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?
Two sentences: first explaining the action, second providing the use case. No unnecessary words, front-loaded, efficient.
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?
Though there is an output schema (not shown), the description does not need to detail return values. It covers purpose, usage context, and parameter behavior adequately for a simple tool. Minor lack of details about error states or configuration prerequisites, but still complete enough.
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% for the single optional parameter 'provider', with a clear description in the schema. The tool description adds no new parameter details beyond restating that it queries each configured provider by default, so no additional value over 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 the verb 'Query' and the resource 'each configured provider for the model ids'. It also provides a use case ('discover valid model names before editing the config or choosing participants'), distinguishing it from sibling tools like 'discuss' and 'list_participants'.
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 context: 'Useful to discover valid model names before editing the config or choosing participants.' It does not explicitly state when not to use or alternatives, but the context is clear and distinguishes from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI participants configured for the ai-discuss server, including type, model, whether they are enabled/available, and which is the default synthesizer. Useful before calling discuss.
| Name | Required | Description | Default |
|---|---|---|---|
| enabledOnly | No | If true, only return enabled participants. Default false. |
| Name | Required | Description |
|---|---|---|
| participants | Yes | |
| defaultRounds | Yes | |
| defaultSynthesizer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry behavioral disclosure. It details output fields and implies read-only operation. It could mention permissions or side effects but is adequate for a list tool.
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?
Two sentences with no redundancy. First sentence states purpose and output; second provides usage context. Every word earns its place.
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?
With an output schema (existing but not shown), description does not need to detail return values. It covers the tool's purpose, output fields, and usage hint, making it complete for an agent.
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% for the single parameter, so description adds no extra meaning beyond schema. Baseline score of 3 is appropriate.
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?
Description clearly states the tool lists AI participants, specifying the fields returned (type, model, enabled/available status, default synthesizer). It distinguishes from sibling tools by noting it is useful before calling discuss, implying preparation.
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?
Description explicitly states 'Useful before calling discuss,' giving clear context for when to use. It does not exclude other use cases or compare to list_models, but the guidance is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0discusslist_modelslist_participantsScored across 3 tools
Each tool serves a distinct purpose: discuss runs the debate, list_models discovers available models, and list_participants shows configured participants. No functional overlap.
All tools use consistent snake_case verb_noun naming (discuss, list_models, list_participants), with a clear pattern.
Three tools is well-scoped for this focused server; each tool plays an essential role without redundancy.
Tools cover the main discussion task and listing of resources, but lack create/update/delete operations for participants or models, leaving configuration management to external means.
Convene a panel of expert AI personas to debate any decision from every side.
Multi-model AI debates: GPT-4o, Claude, Gemini & 200+ models discuss, then synthesize insight.
Commission a multi-model AI spec committee from your agent; get rubric-scored, build-ready specs.
Multiple AIs peer-review and debate your question, then return one fact-checked answer.
