codex-claude-council
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COUNCIL_CONFIG | No | Path to a custom config file. Set to use a different config file. |
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| council_askA | Get one cross-checked answer from Codex (ChatGPT) and Claude: each answers on its own, then they reply to each other until both agree, and one writes the final answer that the other checks. Use it for decisions, reviews and questions where a second model's check is worth minutes of waiting; for a quick single opinion use council_ask_codex or council_ask_claude, and for the whole discussion use council_debate. It runs the user's local Codex and Claude Code CLIs on their own subscriptions, so it uses both plans' quota, and takes minutes; a call still running after about 50 s returns a job_id for council_result. With workspace, both models read the project but never change it. Each model keeps its session between calls, so it remembers earlier questions. |
| council_debateA | Run the same council as council_ask but return the whole discussion as JSON: both opening answers, every exchange with each model's reply and verdict, the check of the final answer, and the settings used. Use it when the user wants to see where the models disagreed or how they converged; use council_ask when only the answer matters, since the transcript is long. Same cost and timing as council_ask: both plans' quota, minutes, and a job_id for council_result if it is still running after about 50 s. |
| council_ask_codexA | Ask Codex (ChatGPT) alone, through the user's Codex CLI signed in with ChatGPT, and return its answer. Use it for a quick second opinion from ChatGPT; use council_ask when the answer should also be cross-checked by Claude, or council_ask_claude for Claude alone. It uses the user's ChatGPT plan and usually answers within a minute (longer at high effort, when it returns a job_id for council_result). With workspace it reads the project but never changes it; its session carries over between calls. |
| council_ask_claudeA | Ask Claude alone, through the user's Claude Code CLI signed in with a Claude subscription, and return its answer. Use it for a quick second opinion from Claude, for example from Codex or ChatGPT; use council_ask when the answer should also be cross-checked by Codex, or council_ask_codex for Codex alone. It uses the user's Claude plan and usually answers within a minute (longer at high effort, when it returns a job_id for council_result). With workspace it reads the project in plan mode and never changes it; its session carries over between calls. |
| council_joinA | Take part in the council yourself, in this conversation, with everything you already know, instead of a separate session of your model: you are one member and the plugin runs the other model (Codex if you are Claude, Claude if you are Codex), optionally continuing the user's own session of it. The steps are the same as council_ask (answer independently, then reply to each other's latest message until both agree, then write and check the final answer). Whenever it is your turn, this tool (or council_turn / council_result) returns the council's message to you: write your reply yourself and send it with council_turn. Use this when the user wants you to discuss with the other model, or gives the id of their session of the other model; use council_ask instead when the user wants a council of two separate sessions. Only the other model runs a CLI session; your turns are written here, in this conversation. |
| council_turnA | Send your reply to the council's latest message, after council_join, council_turn or council_result returned your turn, and wait for the next step. Only for councils started with council_join; the text is passed to the other model as written, so write the complete reply yourself. If the council is not waiting for you, it says so and you call council_result instead; if the next step takes longer than about 50 s, call council_result with the council_id. |
| council_resultA | Wait for a job that returned status working with a job_id (from council_ask, council_debate, council_ask_codex, council_ask_claude or council_join), and return its answer, or with council_join your next turn. Waits up to about 50 s and returns as soon as something is ready; if the job is still working, call it again. Use it instead of asking the same question again, which would start a second job and use the plans twice. Waiting uses no model quota. |
| council_cancelA | Stop a running job (a council_ask, council_debate, council_ask_codex, council_ask_claude or council_join): its Codex and Claude CLI processes are ended and its progress is discarded, so its answer can no longer be retrieved. Use it when the user asks to stop, or a council is no longer needed; to check on a job instead, use council_result. |
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 8 tools
The tools have largely distinct purposes and the descriptions actively cross-reference each other (single-model asks vs. cross-check vs. transcript vs. self-participation vs. async polling vs. cancel). The main subtlety is council_ask vs council_debate, which run the same council but return the answer versus the full transcript—an agent could occasionally pick the wrong one, though descriptions clarify the tradeoff.
All tools share a consistent council_ namespace prefix in snake_case, and follow an action-focused pattern (council_ask, council_join, council_turn, council_result, council_cancel). Minor irregularity: council_ask_codex / council_ask_claude use a model suffix while the combined council_ask does not, but the scheme is still readable and predictable.
Eight tools is well within the ideal range for this domain. Each earns its place: the three ask variants for single/cross-checked answers, debate for transcripts, join/turn for self-participation, and result/cancel for the async job lifecycle.
The surface covers the full lifecycle: starting single- and dual-model jobs, participating as a model yourself, polling long-running jobs, and cancelling them. The only minor gap is no way to enumerate or list previously started jobs/sessions, but result and cancel let agents recover and manage state adequately.