model-council-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JUDGE_MODEL | No | Judge model ID or 'auto' to use largest council member (default: auto) | auto |
| GROQ_API_KEY | No | Groq API key to enable Groq models (optional) | |
| VLLM_SERVERS | No | Comma-separated list of vLLM servers (name:host:port or name:url format, optional) | |
| RESPONSE_MODE | No | Default response mode: individual, categorized, or deconflicted (default: categorized) | categorized |
| COUNCIL_MODELS | No | Comma-separated list of model IDs for the council (empty means auto-discover) | |
| OLLAMA_ADDRESS | No | Base URL of your Ollama server (default: http://localhost:11434) | http://localhost:11434 |
| OPENAI_API_KEY | No | OpenAI API key to enable OpenAI models (optional) | |
| SGLANG_SERVERS | No | Comma-separated list of SGLang servers (name:host:port or name:url format, optional) | |
| TRTLLM_SERVERS | No | Comma-separated list of TRT-LLM servers (name:host:port or name:url format, optional) | |
| ANTHROPIC_API_KEY | No | Anthropic API key to enable Claude models (optional) | |
| MAX_DECONFLICT_ROUNDS | No | Maximum deconfliction iterations (1-10, default: 3) | 3 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_modelsA | List all AI models available across every configured provider (Ollama, OpenAI, Anthropic, X.AI Grok (API key), vLLM, TRT-LLM, SGLang, plus subscription-CLI providers: Claude, ChatGPT/Codex, Grok). Use the returned model IDs when calling configure_council. |
| configure_councilA | Update the council configuration: select which models form the council, choose a judge model, set the response mode (individual / categorized / deconflicted / pooled / dialectic), and set the maximum deconfliction rounds. Each field supplied is persisted and survives restarts/reloads, same as setup_council's tier choices; a field left unset is untouched. |
| ask_councilA | Send a question to the model council and get a structured response. Mode: individual (each model answers separately), categorized (judge groups responses into agreement/complementary/conflicting), deconflicted (iterative loop — judge orchestrates re-questioning until conflicts resolve, returns a deconfliction score 0–100%), pooled (Delphi-style — members reconsider against a neutral, deduplicated, attribution-free pool of answers; no winner is forced, so genuine divergence is preserved), or dialectic (thesis/antithesis/synthesis — members defend their pick and critique the rest, the judge compiles a pros/cons dossier per option, then members re-select a ranked top-3). Attach images to ask a vision question — only auto-detected vision-capable members are queried; the rest are skipped and reported in visionRouting. For a repo review, pass git_ref (e.g. "uncommitted", "main..HEAD") instead of hand-listing files — the server runs |
| ask_council_asyncA | Start a council run in the background and return a job_id immediately, so a long deconfliction/dialectic run (or a slow local model) does not block. Same inputs as ask_council (mode, context, files, etc.). Poll get_council_result with the job_id to fetch the answer when ready. Jobs are in-memory and do not survive a server reload. |
| get_council_resultA | Fetch a background council run started with ask_council_async. Pass job_id to get its status (running | done | error) and, when done, the full result. Omit job_id (or set list=true) to list recent jobs. |
| get_council_configA | Return the current council configuration: member models, judge model, response mode, and max deconfliction rounds. |
| council_statusA | Report the detected environment and current setup: local Ollama models, whether Ollama cloud is reachable on this plan, whether Claude and Codex are logged in, whether Grok CLI is installed but fail-closed, the current council members, resolved subscription tiers, per-provider concurrency, and a quota warning. Use this as the welcome/status readout — it works in every client and install method. |
| setup_councilA | Set subscription tiers, then re-detect and auto-populate the council with everything usable. Tiers gate cloud availability and per-provider concurrency: chatgpt (free|plus|pro5x|pro20x), claude (free|pro|max5x|max20x), grok (free|supergrok|premiumplus|heavy), ollama (free|pro|max). Choices persist across reloads. Note: registering a NEW subscription provider or changing concurrency takes full effect after a reload. |
| set_council_timeoutsA | Set the per-completion wall-clock timeouts (ms) for council calls, persisted across reloads and overriding the REQUEST_TIMEOUT_MS / REPO_REQUEST_TIMEOUT_MS env defaults. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct operation: model discovery, configuration updates, synchronous query, async query, result retrieval, config retrieval, environment status, initial setup, and timeout management. The only potential overlap between setup_council and configure_council is clearly differentiated by their descriptions (tiers vs. council composition).
Tools follow a consistent snake_case convention with mostly verb_noun patterns (list_models, ask_council, get_council_config). Minor deviations like council_status (noun_noun) and setup_council (compound verb) are still predictable and do not hinder usability.
At 9 tools, the server is well-scoped for a model council management domain. Each tool earns its place, covering discovery, setup, configuration, querying, and maintenance without unnecessary bloat.
The tool set covers the full lifecycle: listing models, setting up with tiers, fine-tuning configuration, synchronous and asynchronous ask, result retrieval, config/status readouts, and timeout adjustment. No critical gaps or dead ends are apparent.