codex-claude-council

Overview Schema Source Related Servers Discussions Admin

Ask Codex (ChatGPT) only

council_ask_codex

Read-only

Ask ChatGPT alone through your signed-in Codex CLI to get a quick second opinion on a question, returning one model's answer.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`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.
`effort`	No	Optional Codex reasoning effort override. Omit to use the configured default; set only when the user asks for a specific one.
`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).
`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).
`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.

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

Behavior5/5

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

Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds behavior they cannot express: it bills against the user's ChatGPT plan, typically answers within a minute but goes longer at high effort and then returns a job_id for council_result, workspace access is plan-mode read-only, and session memory carries over between calls. The async job_id path is operationally important and not derivable 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?

Front-loaded with purpose, then siblings, then behavioral facts; no filler sentences. The third sentence is a dense semicolon chain, but every clause (plan usage, latency, job_id, read-only workspace, session carryover) carries distinct information an agent needs.

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

Completeness4/5

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

With an output schema present, return values need not be explained, and the async job_id note is a bonus. Annotations and the 100%-covered 8-parameter schema handle the rest; the only mild gap is that rate/plan-limit behavior beyond 'uses the user's plan' is left implicit.

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

Parameters4/5

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

Schema description coverage is 100%, so the 3 baseline applies and the detailed schema already carries model/effort/network/skill semantics. The description goes slightly beyond by tying workspace to 'questions about the code, a change, a fix, an error or logs' and noting read-only plan mode plus session carryover, adding usage context rather than repeating field docs.

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 (ask) and resource (Codex/ChatGPT via the user's Codex CLI) and immediately distinguishes the tool from its siblings by naming council_ask and council_ask_claude and the condition that selects each. An agent can route between the three 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 when-to-use ('quick second opinion from ChatGPT') plus explicit alternatives and their selection criteria (council_ask when cross-checking with Claude is wanted, council_ask_claude for Claude alone). This is the strongest form of routing guidance.

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

Deploy Server