codex-claude-council

Overview Schema Source Related Servers Discussions Admin

Discuss with the other model yourself

council_join

Read-only

Join a two-model council in this conversation: write your own turns while the plugin runs the other AI, optionally continuing the user's session of it, until both agree.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`me`	No	Which model you are: "claude" if you are Claude (Claude Code, Claude Desktop), "codex" if you are Codex or ChatGPT. The other model is the one the plugin runs.
`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.
`other_model`	No	Optional model override for the other model. 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, "claude" or "codex" (you or the other model); the other checks it. Omit to write it yourself (the host); pass it only when the user names who should write it.
`other_effort`	No	Optional effort override for the other model (Codex: none, minimal, low, medium, high, xhigh; Claude: low, medium, high, xhigh, max). Omit to use the configured default; set only when the user asks for a specific one.
`other_session_id`	No	Optional: the id or /rename name of the user's own session of the other model (a Codex session if you are Claude, a Claude Code session if you are Codex), or user@host:<id or name> for one on another machine (it runs there through ssh), to continue in place with its memory. Pass it exactly as the user gives it, only when they give one; never your own session.

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.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds real mechanics: only the other model runs a CLI session, your turns are written in this conversation, and the exchange continues (answers, mutual replies, synthesis and check) via council_turn/council_result. It stops short of describing the response payload itself, but that is largely covered by the output schema.

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 key differentiator (you participate here rather than in a separate session) is front-loaded, and the workflow and routing follow in a logical order. It is dense and slightly repetitive around the turn-taking mechanism, but for a multi-turn tool of this complexity little of it is wasted.

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 complex, multi-turn, 11-parameter tool with an output schema and full annotation coverage, the description supplies the missing pieces: the interaction model, who runs which session, how turns are exchanged, and when to choose the sibling. An agent has enough to call and orchestrate it correctly.

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% across 11 parameters, so the schema already documents each one thoroughly. The description only touches parameter semantics lightly (the other model's session id, and the fact that a session id selects this tool over council_ask); it adds little syntax or default detail beyond the schema. Baseline 3 applies.

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 and resource ('take part in the council yourself, in this conversation') and immediately contrasts it with the sibling it is not ('instead of a separate session of your model'). An agent can distinguish it from council_ask and council_debate without opening any schema.

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?

Explicit routing: '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.' It also states the follow-up path (write your reply and send it with council_turn). Both the trigger and the alternative are named.

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

Deploy Server