codex-claude-council

Overview Schema Source Related Servers Discussions Admin

Ask the Codex–Claude council

council_ask

Read-only

Get a cross-checked answer from Codex and Claude: both answer, debate until they agree, then one writes the final answer and the other verifies. Use for reviews or decisions.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`skill`	No	Optional: the name of an installed skill both models may use for this question, at the steps where they judge it is needed, including any sub-agents it calls for; for several skills, their names separated by commas ("llm-council, caveman"). Pass only skills the user asks to use (by name, or by a phrase the skill says triggers it). Skills of Claude Code's and Codex's enabled plugins can be named too. Installed: none (install with `codex-claude-council skill add <GitHub URL>`). A step that uses it takes much longer and uses much more of both plans.
`network`	No	Optional: whether Codex's shell commands may reach the network (for example to call an API or fetch live data), still read-only on disk. Omit to use the configured default (off unless the user changed it). Pass true only when the user asks for it.
`question`	Yes	The question, with any context the models need.
`workspace`	No	Absolute path of the project folder you are working in. Both models then work in it in plan mode: they read it (files, search, read-only commands such as git log and diff) but never change it. Pass it whenever the question is about the code, a change, a fix, an error or logs in this project. Omit only for questions unrelated to any project (or when passing a session id: the session's own folder is used).
`max_rounds`	No	Optional limit on the exchange. After the two independent answers, each model replies to the other's latest message, round after round, until both agree; then the synthesizer writes the final answer and the other checks it. N (1 or more): at most N exchanges. 0: no limit (can take a long time and use a lot of both plans' usage). Omit to use the configured default (5 unless the user changed it). Set only when the user asks for a number of rounds or for agreement without a limit.
`web_search`	No	Optional: whether the models may search the web and read web pages. Omit to use the configured default (on unless the user changed it). Pass false only when the user asks for no internet access.
`codex_model`	No	Optional Codex (ChatGPT) model override, e.g. gpt-5.6-sol. Omit to use the configured default; set only when the user asks for a specific one.
`synthesizer`	No	Optional: which model writes the final answer ("codex" is ChatGPT); the other checks it. Omit to use the configured default (Claude unless the user changed it).
`claude_model`	No	Optional Claude model override: an alias such as opus, sonnet or fable, or a full model name. Omit to use the configured default; set only when the user asks for a specific one.
`codex_effort`	No	Optional Codex reasoning effort override. Omit to use the configured default; set only when the user asks for a specific one.
`claude_effort`	No	Optional Claude effort level override. Omit to use the configured default; set only when the user asks for a specific one.
`codex_session_id`	No	Optional: a Codex session the user already has: its id (as shown by `/status`) or the name they gave it with `/rename`; on another machine, user@host:<id or name> (runs there through ssh), to continue in place instead of a new session, so the model keeps that session's memory. Pass it exactly as the user gives it, only when they give one. The council's turns are added to that session, in plan mode (nothing is changed).
`claude_session_id`	No	Optional: a Claude Code session the user already has: its UUID (as shown by `/status`) or the name they gave it with `/rename`; on another machine, user@host:<id or name> (runs there through ssh), to continue in place instead of a new session, so the model keeps that session's memory. Pass it exactly as the user gives it, only when they give one. The council's turns are added to that session, in plan mode (nothing is changed).

Output Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	The answer (council_debate: its JSON), or the message to act on; the same as the text content.
`job_id`	No	With working or stopped: the job to wait for, or the one stopped.
`status`	Yes	done: text is the answer. working: still running; call council_result with job_id. your_turn (council_join): text is the council's message; reply with council_turn and council_id. stopped: council_cancel stopped job_id.
`council_id`	No	With your_turn: the council to reply to with council_turn.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.4Oct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare read-only/open-world/non-idempotent; the description adds the material operational facts: it consumes both subscriptions' quota, takes minutes, can hand back a job_id for council_result, runs models in plan mode so the project is read but never modified, and that each model retains session memory across calls. It is consistent with readOnlyHint=true and openWorldHint=true (network is opt-in via the network parameter).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The most important facts - what it is, when to use it, cost, and the job_id fallback - are front-loaded, and every sentence carries information. It is long and dense with several compound clauses, but for a 13-parameter orchestration tool the length is largely earned rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the presence of an output schema, and annotations covering the safety profile, the description covers the remaining agent-facing gaps: cost/quota, latency, the async job_id handoff to council_result, read-only plan-mode workspace behavior, and session persistence. Nothing needed to invoke it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all 13 parameters are already documented in the schema, which sets the baseline at 3. The description reinforces a few semantics ('With workspace, both models read the project but never change it', session memory across calls) but adds no format, default or usage detail beyond what the schema fields already state, so it does not clear the bar for a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Get one cross-checked answer from Codex (ChatGPT) and Claude') and immediately explains the mechanism: independent answers, mutual reply, synthesis, verification. It also explicitly contrasts itself with council_ask_codex, council_ask_claude and council_debate, so an agent can place it correctly without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the positive case ('decisions, reviews and questions where a second model's check is worth minutes of waiting') and names the alternatives with the condition that selects each: quick single opinion -> council_ask_codex/council_ask_claude, whole discussion -> council_debate. It also gives an operational switchover rule: still running after ~50 s, use council_result.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server