codex-claude-council

Overview Schema Source Related Servers Discussions Admin

Ask Claude only

council_ask_claude

Read-only

Get a quick second opinion from Claude alone through your signed-in Claude Code CLI. Use it when you want only Claude's answer, without a cross-check from Codex.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`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 Claude effort level override. Omit to use the configured default; set only when the user asks for a specific one.
`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 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).
`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.6/5.0

Behavior5/5

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

Annotations cover safety (readOnly, non-destructive, open world), and the description still adds materially: it runs through the user's Claude subscription plan, usually answers within a minute, may return a job_id for council_result at high effort, workspace is plan-mode read-only and 'never changes it', and sessions carry over between calls. These are exactly the operational traits an agent needs before invoking.

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 alternatives, then timing and workspace semantics; no filler sentences. The prose is dense and slightly long for a single paragraph, but each clause carries routing or behavioral information.

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?

With an output schema present, the description needn't document return values, yet it explains the async job_id path and the session/plan-mode behavior anyway. Combined with annotations and full schema coverage, an agent has everything required to call this 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% and the schema text is verbose and self-sufficient (each parameter documents its own omission/default rules). The description's parameter remarks, such as workspace/session_id interaction, largely restate the schema, so the baseline 3 applies rather than a higher value.

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 ('Ask Claude alone ... and return its answer') and immediately names the two sibling alternatives it is distinct from (council_ask for cross-checking, council_ask_codex for Codex alone). An agent can route between the three council ask tools 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 Claude, for example from Codex or ChatGPT') and explicit alternatives with selection conditions. It further scopes sub-cases: pass workspace whenever the question concerns code/logs in the project, omit it otherwise, and omit it when a session id is supplied.

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

Deploy Server