codex-claude-council

Overview Schema Source Related Servers Discussions Admin

Codex–Claude debate transcript

council_debate

Read-only

Run two AI models through a full multi-round debate and return the whole discussion as JSON, so you can see where they disagreed and how they converged.

Instructions

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.

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?

Beyond the annotations (readOnly/openWorld/non-idempotent), it discloses the async execution model ('a job_id for council_result if it is still running after about 50 s') and the cost profile ('both plans' quota, minutes'), plus the practical warning that the transcript is long. These are the traits an agent cannot derive from the structured fields.

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?

Three front-loaded sentences with no filler; the return shape, selection rule, and cost/timing come in that order. Slightly dense but every clause adds information an agent needs.

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?

For a 13-parameter, asynchronous, non-idempotent tool, the description covers selection, cost, polling via job_id, and transcript scope; the return values are further specifiable via the output schema, so nothing essential is 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 description coverage is 100%, so every parameter is already documented in the schema, and the description only alludes to 'the settings used' being returned. The baseline of 3 applies when the schema carries the parameter burden.

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?

States a specific verb plus resource ('Run the same council as council_ask but return the whole discussion as JSON') and then enumerates the returned contents (opening answers, exchanges with replies and verdicts, final check, settings). An agent can distinguish it from council_ask purely from the description.

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?

Explicitly routes: '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.' Names the alternative sibling and the condition that selects each — no inference required.

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

Deploy Server