CoAgent8
CoAgent8 lets a coding agent call other coding CLIs for second opinions, independent Git reviews, diagnostics, session control, cancellation, and sanitized bug reports.
consult: ask Codex, Claude Code, or Antigravity for a second opinion on a question, design, bug, or plan, with optional task type, context files, specific questions, model, backend, reasoning effort, price limit, and timeout.review: get an independent read-only review of Git changes by scope/target, with optional review instructions, model/backend/reasoning/price controls, and aREADYorBLOCKEDverdict.doctor: inspect each backend’s available models, reasoning efforts, output prices, approval needs, and health/readiness/quota.session: list sessions, page a session’s history, or close a session, optionally deleting its history.cancel: stop a running turn for a session by interrupting or ending the CLI process.issue: prepare a sanitized GitHub bug report, optionally including detected CLI versions but no readiness or quota data.Common controls include workspace path selection, session follow-ups, model/backend routing, price limits, and bounded timeouts.
Allows using Google's Antigravity CLI (agy, which runs Gemini and other models) as a sandboxed backend to request second opinions and independent reviews, with stream-json output and conversation resume.
Allows using OpenAI's Codex CLI as a read-only backend to request second opinions and independent reviews of Git changes, supporting model selection, session continuation, and diagnostics.
CoAgent8 - Cooperating coding agents
CoAgent8 lets the coding agent you work with ask another one. It is an MCP
server that puts Codex, Claude Code and Antigravity (agy, which runs Gemini and
other models) behind the same seven tools: your agent requests a second opinion or
an independent review of your Git changes, or delegates a code change, and gets
the other agent's answer back in the chat. Consultations and reviews run in a
read-only profile; a delegated change edits the workspace. Every agent runs on
your own installed and signed-in CLI.
Contents: Status | Quick start | Features | Tools | Skills | VS Code extension | Configuration | Known limitations | Reporting problems | Contributing
Status
0.7.0 is the current release; 0.6.0 was the first for testers, and 0.8.0
will be the first release candidate. Every version below 1.0.0 is a
preview, with the same version number on GitHub, npm and VS Code. On npm
each release appears first as coagent8@next; latest follows once the
version has proved stable.
In 0.7.0: consultations and reviews by another agent in a read-only profile,
model selection by price with your approval for expensive models, continuable
sessions with history, diagnostics, skills and the VS Code extension. New in
0.8.0, on develop and not released yet: delegating a code change to another
agent, which runs in the background and wakes Claude Code when it ends, with an
optional loop in which CoAgent8 runs your checks and an independent review and
returns failures to the agent; reviews of large changes in parts; and checks
CoAgent8 runs before a review. This README describes develop, so features
marked 0.8.0 are not in the published packages. Several delegated agents can run
at once under one budget, in disjoint scopes of a work tree or in separate Git
worktrees. Not yet available: an agent that itself delegates to others. That is
the next step in the roadmap.
Related MCP server: codex-fusion-mcp
Quick start
You need Node.js 24 or later and at least one of these CLIs, installed and signed in:
CLI | Notes |
Also found inside the OpenAI VS Code extension | |
2.1.289 or later; subscription login or API key | |
Antigravity CLI ( | Also installed by the Google Antigravity VS Code extension ( |
VS Code
Install CoAgent8 (okidev.coagent8-mcp) from the
VS Code Marketplace,
or download coagent8-mcp-0.7.0.vsix from the
GitHub release
and run Extensions: Install from VSIX.... Then:
The first start shows one notice with the CLIs it found, or an offer to set them up. CoAgent8: Manage Coding CLIs installs or signs in a CLI at any time.
CoAgent8 is registered in your user MCP servers (
mcp.json) and appears in MCP: List Servers; start it there, accept VS Code's trust prompt, and enable its tools in your chat.Ask your agent, for example: "Use CoAgent8 doctor with scope health", "Ask CoAgent8 for a second opinion on this plan" or "Have CoAgent8 review my uncommitted changes".
To use CoAgent8 also inside the CLIs' own chats, choose Add CoAgent8 to All CLI Chats (or Add CoAgent8 to Its Chat in one CLI's menu) in CoAgent8: Manage Coding CLIs.
Codex, Claude Code and Antigravity CLIs
One command registers CoAgent8 in the chats of the CLIs you choose and installs its skills:
npx -y coagent8@next setup --clients=codex,claude,agySetup copies the server to ~/.coagent8/runtime/, so the registration does
not depend on the npx cache, and keeps a private backup of every file it
changes. status checks the CLIs. repair checks the registrations and updates the
ones setup wrote and you did not change; an entry you edited is kept.
cleanup shows what it would remove; run it again with the
--apply=<token> it prints to remove the registrations and skills setup added.
npm runs no script on uninstall, so run cleanup before npm uninstall -g coagent8.
Any other MCP host
Add a stdio server to the host's MCP configuration:
{
"mcpServers": {
"coagent8": {
"command": "npx",
"args": ["-y", "coagent8@next", "mcp"]
}
}
}On Windows, a host that starts commands without a shell may need
"command": "cmd" and "args": ["/c", "npx", "-y", "coagent8@next", "mcp"].
coagent8 mcp starts the server; run in a terminal without arguments,
coagent8 shows help. Older entries without mcp keep working, because
coagent8 and coagent8-mcp still start the server when a host pipes their
standard input. coagent8@0.7.0 pins a version. Plain coagent8 (npm latest)
is not a supported channel before 1.0.0.
A host with its own tool deadline can stop a long review early. For Codex, set
tool_timeout_sec = 1800 in [mcp_servers.coagent8] (setup does this). Continue
supports stdio MCP in Agent mode through the same definition, following
Continue's MCP guide.
Features
One MCP server, three coding CLIs. Codex, Claude Code and Antigravity behind the same seven tools, for any stdio MCP host.
Read-only profiles. Every backend runs in a read-only profile; for Codex and Claude Code CoAgent8 verifies it and refuses a turn it cannot confirm.
Second opinion and independent review.
consultanswers a question;reviewchecks Git changes and derives aREADYorBLOCKEDverdict itself instead of trusting the model's word.You decide on expensive models. A model priced high or unknown runs only after you approve it in a form; the calling agent cannot approve it for you. A call can also set a strict price limit.
Sessions you can continue. A follow-up with the session handle keeps the other agent's context; history is paged and scoped to the workspace.
Quiet, bounded processes. No shell, no console windows, only processes CoAgent8 started, bounded buffers and one deadline for the whole call.
Self-diagnosing.
doctorlists models, efforts and prices and checks installation, sign-in and quota;issueprepares a sanitized bug report.Skills and editor integration. One skill per function for each CLI's chat; the VS Code extension manages CLIs, skills and model approvals.
Backends and read-only profiles
Backend | Execution profile |
Codex |
|
Claude Code (2.1.289+) |
|
Antigravity ( | Headless |
Routing
backend:auto(default),codex,claude,agyorsmart_quota. A model name alone also chooses its backend.config.jsoncan fix a default backend or select thesmart_quotastrategy, limited byallowedBackends.autouses the configured default backend when it is eligible. Otherwise it skips backends with an observed rate limit, prefers a CLI other than the one calling, and ranks the rest by measured quota headroom. A measurement older than 15 minutes counts as unmeasured;doctorwithscope: "health"refreshes it.A failed turn is never silently retried on another backend.
Models, prices and approval
A turn uses the call's
model, then the session's model, thenbackends.<id>.defaultModel, then the CLI's own default. CoAgent8 itself names no model.reasoning_effort:none,minimal,low,medium,high,xhighormax, checked against the model's accepted efforts where the CLI lists them.Prices come from OpenRouter's public model list (no key, no user data) or from
coagent8_PRICES_URL. They decide whether to ask; they are not a bill.Your rules in
governance.modelscome first:denynever runs a model,askasks before every turn,allowruns it without asking (denywins overask,askoverallow). Any other model asks when its price is unknown or approximate, at or abovegovernance.askAbovePrice(default 20 USD per million output tokens), or at leastgovernance.priceMultiplier(default 2) times the backend's default.
Review gate
Scopes: uncommitted (default), staged, a commit, a branch or a range, with optional review instructions. Git context is bounded (4 MiB per Git command, 3 MiB snapshot). From 0.8.0, a diff above 200,000 characters is reviewed in parts, each in its own session, then in one turn over all their findings; above 15 parts the review is refused and you narrow the scope.
From 0.8.0,
checks, such asnpm test, are run by CoAgent8 on the reviewed change before the turn, and a check that does not pass blocks the verdict. The reviewing agent itself stays read-only, but the checks run with your account, outside any sandbox, and execute the code under review. A check runs only with your approval: list it inallowedChecksof the configuration, or approve it on the form.The reviewing agent answers in a fixed format: snapshot, coverage, verdict, findings as
[P1|P2|P3] file:line, and the checks it ran.CoAgent8 derives the verdict: an incomplete answer, partial coverage, truncated input, another snapshot, a
[P1]or[P2]finding, or a failed check makes itBLOCKED (reason); a workspace change during the turn is reported only when the snapshot or its completeness changed.A review of unchanged code with the same scope, backend and model starts no new turn and returns the earlier verdict.
Staged, commit and range scopes are reviewed only when their files match the current workspace; otherwise review the uncommitted changes.
Sessions and history
Sessions belong to one workspace and one backend; a follow-up through
session_handlekeeps the session's model and effort.sessionwithaction: "history"pages events withcursorandlimit(up to 100 events and 240 KiB per page). Each event'ssequenceis its position in the stored log, so gaps where streaming deltas were combined do not mean lost events, andactivePididentifies the CoAgent8 server process owning the active turn. MCP resourcescoagent8://sessionsandcoagent8://sessions/{id}/historyshow the connection's workspace only.A session handle expires after two hours without use; a closed session reports that it is closed on a follow-up or
cancel, while its history stays readable until deleted. The history archive is best effort: up to 10 MiB per session and 100 MiB in total, old archives removed after seven days.coagent8_HISTORY=offturns archive files off. Private reasoning and raw tool output are never archived or returned.
Safety and bounds
shell: false; prompts go through stdin, at most 4 MiB.Cancellation and deadlines interrupt Codex and Claude Code through their own protocol, then stop only the process CoAgent8 started (Windows: its handle; POSIX: its process group). Nothing is selected by process ID or name.
Output is bounded: 512 KiB per backend stream, 1 MiB per answer.
timeout_msfrom 100 ms to 30 minutes (default 15 minutes) covers Git, preparation, approval, the turn and teardown, with progress notifications.Answers and archives are redacted for credential formats; diagnostics also hide keyword values and home-directory paths. Errors carry a typed code such as
CLI_NOT_FOUND,AUTH_REQUIRED,MODEL_UNAVAILABLE,RATE_LIMITED,TIMEOUT,POLICY_DENIEDorPRICE_LIMIT.
Tools
Tool | Purpose |
| A second opinion on a question, design, plan or bug; optional architecture, debugging or implementation analysis |
| An independent review of Git changes with a verdict CoAgent8 derives; large changes in parts, and |
| Another agent makes a code change in the workspace, asked to keep to the |
| Models, efforts, output prices, defaults and approval per backend; |
| List the workspace's sessions ( |
| Stop the running turn of a session: interrupt where the CLI supports it, then end the CLI process. From 0.8.0, |
| Prepare a sanitized bug report (attaching detected CLI versions when |
A consultation can be as small as:
{
"proposal": "Is this retry loop safe with concurrent writers? <code>",
"backend": "codex"
}context_files passes paths for the other agent to read, not file contents.
Results are Markdown: the answer or a typed error, then the backend, model,
duration and session_handle=<handle> (<state>). Pass that handle for a
follow-up on the same topic; a call without it starts a fresh agent that
rereads everything. review adds its verdict.
The deprecated analyze, debug and implement aliases and the run gateway
still work but are not listed. Every client receives the same seven tools.
From 0.8.0, delegate needs a Git work tree and, on Windows, the job helper the package carries. Codex writes only inside the workspace
(its sandbox, without network access); Claude Code's Edit and Write are
limited to the workspace but its Bash is not; Antigravity runs without its
sandbox and without a path limit, and only edits files (it runs no commands).
Antigravity can end its turn when it reads a file in another checkout, such as
the main checkout of a Git worktree (observed with agy 1.4.12). CoAgent8 then
retries once inside the workspace, and if that also fails, names the denied
action.
The agent reports each check as PASS, FAIL or NOT_RUN. Codex on Windows cannot
run test runners that start processes from Node, such as node --test, Jest or
Vitest. With loop: true CoAgent8 runs the checks itself after the agent, with
your account and outside any sandbox, then gets an independent review on a backend
other than the agent's (and other than your client's CLI while one remains) and returns failures to the agent for up to two fix rounds; the checks
need your approval as in reviews. Without the loop, run the checks yourself
before accepting the change. On Windows a cancelled agent's child processes end
with it; partial changes stay, so check git status after a cancel or timeout.
Agents can work side by side. Every asynchronous delegate belongs to a root and
returns its root_handle; pass it to the next call to share the limits, which
come from rootLimits in your configuration (maxCalls 64, maxConcurrent 8,
maxChildren 16, maxDepth 3, maxMinutes 240) and which a calling agent cannot raise. At a limit
the call fails with ROOT_LIMIT. parent_task records which task a new one follows
from. session with action: root shows the use and the tasks; a finished agent
does not make the work accepted. A scope is an agreement that the server checks at
the start and observes at the end, not a sandbox: an agent can still reach another
agent's paths (only Claude Code's Edit and Write are held to the scope, unless a
scope entry contains a pattern character such as * or [), a path
another agent held is marked as possibly changed by either, and a check an agent runs
sees the half-finished work of the others. Roots belong to a CoAgent8 data directory:
a client with another one does not see them.
Codex or Claude Code can also coordinate workers on Codex or Claude Code (agy takes no part:
it can start subagents that no limit sees). delegate with coordinate: true gives the agent
an objective; it reads the workspace in read-only turns and ends each turn by asking
for workers or by finishing. CoAgent8 checks each request, runs the workers under the
coordinator's root, with scopes inside its scope (an agreement, as above, not a sandbox),
waits for all of them and resumes it with their reports. It has no CoAgent8 tools and cannot name a root, a parent or a session.
Workers cannot ask you anything: a model that needs your approval, or a check the server
would run in a worker's loop that is not in allowedChecks, is refused and reported to the
coordinator. Without loop, checks are only an instruction to the worker, under its own profile. Cancelling the coordinator's
session or its root stops its workers. After a server restart nothing starts by itself:
delegate with coordinate: true and its session_handle tells it what became of
each worker. Its final report and its workers' changes are still yours to check.
Approving expensive models
The approval is a form CoAgent8 sends through MCP elicitation; your client must
show it to you. Clients that cannot show MCP forms close or decline it without
showing it: headless clients, Codex (0.160.1 and 0.164), the Antigravity chat and
Claude Code 2.1.317 in VS Code did so when measured. CoAgent8 then says the
client answered, not you. CoAgent8 never
accepts an approval relayed by the calling agent, so there the turn fails with
POLICY_DENIED. To use such a model anyway, allow it with CoAgent8: Manage
Model Approvals in VS Code or in governance.models.allow, or call it from a
client that shows MCP forms.
Choosing a model under a price limit
Pass the user's limit as output_price_below, in USD per million output
tokens. It is strict: 5 means below 5. Without model, CoAgent8 chooses the
backend's default if it qualifies, otherwise the most recently released
qualifying model (then higher price, then catalog order; undated models rank
last):
{
"proposal": "Calculate 17 * 23. Reply only with the result.",
"output_price_below": 5
}Only an exact price from a list younger than seven days qualifies. If no model
qualifies, the call fails with PRICE_LIMIT and each backend's reason instead
of running another model; an explicit model over the limit is never replaced.
The footer states the price, its list and date. A model within the limit may
still need your approval.
Every result also shows the tokens the turn used, as the backend reported them,
and what they cost at list price when every count and the model's exact price
are known: Usage: 12,400 input (9,600 cached) - 900 output (300 reasoning) tokens - list price ~0.014 USD (openrouter 2026-10-19).
Unknown counts are left out, never shown as zero. Cache writes are priced by how
long they are kept; agy reports no cache counts, and a turn whose input reached a
size the list prices differently (such as 272,000 tokens for some OpenAI models)
shows counts only. A list price is not your bill: a subscription CLI may charge
nothing per token.
To choose yourself, call doctor: it lists each backend's models with their
accepted efforts, output price (~ approximate, ? unknown), default and
approval tag (ask: <rule>, deny or allow). CoAgent8: Manage Model
Approvals in VS Code and npx -y coagent8@next models (coagent8 models
when installed globally) show the same list. Then name the model and an
accepted effort:
{
"proposal": "Calculate 17 * 23. Reply only with the result.",
"model": "<model ID from doctor>",
"reasoning_effort": "low",
"output_price_below": 5
}Skills
Setup and the VS Code extension install one skill per function into each CLI
where CoAgent8 is registered. Codex lists them in /skills and runs them as
$coagent8-review; Claude Code and the Antigravity CLI offer them as
/coagent8-review commands.
Skill | Use it to |
| Ask another agent for a second opinion on a question, design, plan or bug |
| Have another agent review Git changes and read the verdict |
| See models, efforts and prices, apply a price limit, check backend health |
| List, read, continue, cancel or close sessions |
| Prepare a sanitized CoAgent8 bug report |
| Hand a defined code change to another agent, then check what it changed |
| Plan, get the plan reviewed, implement or delegate, run checks and get an independent review |
Client | Skill directory |
Claude Code |
|
Codex |
|
Antigravity |
|
CoAgent8: Manage Skills in VS Code and npx -y coagent8@next skills
(coagent8 skills when installed globally) in a terminal install, update,
uninstall, enable or disable one or all skills per client. Your choices are
kept, so repair does not bring back a skill you removed. Disabled skills move
to ~/.coagent8/disabled-skills/<client>/. A skill you edited is never
overwritten. Start a new chat to see changes. VS Code chat also reads
~/.claude/skills/ and ~/.agents/skills/, so with both Claude Code and Codex
set up it lists each skill twice.
npx -y coagent8@next skills status --clients=agy
npx -y coagent8@next skills install --clients=agy --skills=coagent8-reviewChanges are shown as a preview first; repeat the command for one client with
--apply=<token> to apply them.
VS Code extension
Press F1 (or Ctrl+Shift+P, Cmd+Shift+P on macOS), type CoAgent8 and
choose a command:
Command | What it does |
| Shows each CLI's state and chat entry. Installs a CLI (VS Code extension or official standalone), signs in, chooses the installation CoAgent8 uses, adds, updates or removes CoAgent8 in a CLI's chat, manages its skills, and removes what CoAgent8 installed |
| Allows, asks for or denies individual models, and sets the price rules for asking |
| Installs, updates, uninstalls, enables or disables skills per client |
| Opens CoAgent8's backend, model, configuration path and Node.js settings |
| Opens the configuration file ( |
| Replaces the file with the defaults after a confirmation, keeping the previous one as |
| Opens MCP: List Servers, where VS Code starts, stops and restarts CoAgent8 and shows its output |
The extension changes only what you choose, keeps private backups of the CLIs'
configuration files, and removes only entries it wrote and that you did not
change. When VS Code offers Restart Extensions after an install, update or
chat change, use it. VS Code restarts the CoAgent8 server by itself when its
settings or bundle change. Settings you save in VS Code take precedence over
config.json, except an empty model, which keeps the file's model; the CLIs
and other hosts read only the file.
Uninstalling the extension removes what it added: its chat entries, skills,
runtime copies and storage, including its sessions and history. Your shared
~/.coagent8/config.json, credentials and the CLIs stay.
Configuration
~/.coagent8/config.json is shared by every host, the CLI and the VS Code
extension. Without the file the defaults apply. An unreadable or invalid file
stops execution with POLICY_DENIED while doctor keeps working.
{
"schemaVersion": 1,
"defaultBackend": null,
"routing": {
"strategy": "fixed",
"allowedBackends": ["codex", "claude", "agy"]
},
"backends": {
"agy": { "executable": "vscode-extension", "defaultModel": "<model the first doctor recorded>" }
},
"governance": {
"priceMultiplier": 2,
"askAbovePrice": 20,
"models": { "allow": [], "ask": [], "deny": [] }
}
}A backend's CLI is backends.<id>.executable when it is set (an absolute
path, ~/..., or vscode-extension for the vendor extension's copy); a
configured CLI that is missing fails instead of falling back. Without it, the
CLI is found on PATH, then in the vendor's VS Code extension. The workspace comes from
workspace_path, the client's roots, or the server's working directory.
Variable | Effect |
| Configuration file path |
| Storage root for sessions, history and caches (default |
|
|
| Price list URL or local file instead of OpenRouter |
| Quota cache file |
| Backend executables; they override |
| Backend configuration locations; setup and cleanup support only the defaults |
The architecture states every contract, bound and error.
Known limitations
Antigravity's own tools. agy gives the other agent your agy MCP servers and plugins, which CoAgent8 cannot turn off;
doctorlists them. Calls back into CoAgent8 are refused.Antigravity readiness.
agymay report not ready in a cached check and still run a turn;doctorwithscope: "health"rechecks readiness.Leftover agy processes on Windows. Cancelling or timing out an agy turn stops agy itself, but a process agy started outside it, such as one of its MCP servers, can keep running until it exits or the CoAgent8 server stops.
Parent crash on macOS and Linux. If the host dies unexpectedly, the processes CoAgent8 started are not cleaned up.
Default model price. A plain
consultwith no model and no price limit runs the backend's default model (still subject to your approval thresholds); passoutput_price_belowor a model to bound the price.Approval forms. Clients that cannot show MCP forms cannot approve an expensive model (see approving expensive models) or the checks of
delegatewithloop: true. Claude Code 2.1.317 in VS Code and Codex 0.164 did not show the check form when measured, so list the exact commands inallowedChecksof the CoAgent8 configuration instead.Host deadlines. A host can stop a tool call before CoAgent8's own deadline; a headless agy client stopped calls after 180 seconds.
Sessions on disk. Every call keeps a session record, even with archives turned off, and the session handle arrives with the result.
Codex sandbox on Windows. CoAgent8 runs Codex in its unelevated Windows sandbox, which reads what your account can read and blocks writes. A PowerShell installed from the Microsoft Store cannot start inside it, so Codex falls back to Windows PowerShell 5.1; install PowerShell 7 another way (for example
scoop install pwshor the MSI) to give Codex version 7.Reviews of another tree. A staged, commit or range review whose files do not match the current workspace is refused rather than reviewed.
Reporting problems
For suspected security vulnerabilities, follow the security policy and report privately. Do not include vulnerability details in public issues.
Ask your agent to run the issue tool: it prepares a sanitized report with
your OS, Node and detected CLI versions (when include_doctor is true, the
default; no readiness or quota) and a link that opens a new GitHub issue with
it. Add the steps and what you expected, and check the text for private data
before you submit it. You can also use the
bug-report form
directly: only "What happened" is required.
Building and contributing
Building from source needs Node.js 24.11+ or 26+:
npm ci
npm run buildThe server is then node <checkout>/dist/index.cjs; npm pack produces the
installable package. A checkout of develop is a development build, not a
release. Restart a running MCP server after rebuilding.
Need | Document |
How to contribute | |
Security support and private reports | |
Planned work and priorities | |
Contracts, limitations and design | |
Contributor rules | |
Branches, pull requests and releases | |
Checks by scope | |
Release history | |
Documentation site: this README, the project documents and the source API |
The npm package does not include docs/ or the contributor rules; these links
work in the repository.
License
Copyright (c) 2026 Oktawian Wybieralski (oki.dev).
The project source, documentation and artwork in this checkout are licensed
under the MIT License. See LICENSE for the terms and warranty
disclaimer. Bundled dependencies retain their own licenses and notices in
dist/THIRD_PARTY_NOTICES.txt.
0.6.1 is the first release under the MIT License. Copies of published 0.6.0 and the withdrawn npm version 1.0.0-beta.1 retain their GPL-3.0-only permissions. This change does not revoke any license previously granted for a distributed copy.
Trademarks. CoAgent8 and the CoAgent8 logo are trademarks of Oktawian Wybieralski (oki.dev). The copyright licenses under which CoAgent8 is or was distributed cover the software, documentation and artwork, including the logo files, and this notice does not limit them. They do not grant rights to use the name or logo as a trademark, for example to brand a modified version or another distribution, or to suggest endorsement. Accurate references to CoAgent8, such as naming it as the origin of a fork or describing compatibility, need no permission.
Created by Oktawian Wybieralski - GitHub repository
Available Tools
6 toolscancelC
Stop the running turn: interrupt if possible, then end the CLI.
| Name | Required | Description | Default |
|---|---|---|---|
| session_handle | Yes | ||
| workspace_path | No | Repository path; omit for client workspace (footer fallback). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the important two-phase escalation: try to interrupt, otherwise terminate the CLI. However, it omits whether this is irreversible, what happens to in-flight work or session state, whether the session_handle becomes invalid, and whether there is any confirmation step — all critical for a terminating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the action front-loaded and no wasted words. It is efficient, though the brevity borders on under-specification for a destructive tool rather than being genuinely complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a terminal, non-read-only operation with zero annotation coverage, no output schema, and an undocumented required parameter, the description should say more about irreversibility and post-conditions. As written, an agent cannot fully predict the consequences of invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% schema coverage and the description adds nothing about parameters. The required session_handle has no description anywhere, so an agent has no guidance on its format or how to obtain it; only workspace_path is documented, and that documentation comes from the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: stop the running turn, with the added detail that it escalates to ending the CLI. This distinguishes it from the sibling read-oriented tools (doctor, consult, review, session, issue), though it never explicitly contrasts with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the mechanism (interrupt then kill) but gives no guidance on when to call it versus alternatives, no preconditions, and no note on when it should not be used. An agent must infer that this is the abort path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consultA
Second opinion on a question, design, bug or plan. Returns the answer, then "CoAgent8:" lines: backend, model, seconds, session handle.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Omit unless the user names a model or price limit. doctor lists models, efforts and prices; unknown names fail. Tag ask: ask the user first, a form follows; deny: never runs. | |
| backend | No | codex: Codex CLI; claude: Claude Code; agy: Antigravity. auto (default): configured provider, else another CLI than yours, most cached quota. | |
| proposal | Yes | Self-contained question or plan; name files instead of pasting them. Bad: "thoughts?" | |
| task_type | No | Omit for a plain question; set to ask for that kind of analysis. | |
| file_paths | No | ||
| timeout_ms | No | Monotonic call budget, ms: Git, prep, consent, CLI turn, teardown. | |
| context_files | No | Workspace paths the agent reads itself; only the paths are sent. | |
| session_handle | No | Same-topic follow-up: footer handle; else a fresh agent rereads all. | |
| workspace_path | No | Repository path; omit for client workspace (footer fallback). | |
| reasoning_effort | No | Omit for the default; doctor lists per-model values. Required where listed, or as a model name suffix. | |
| output_price_below | No | User limit, USD per million output tokens, strict (5 excludes 5). Only verified prices qualify; server picks default or newest. | |
| specific_questions | No | Extra questions or criteria the answer must cover. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape (answer followed by "CoAgent8:" footer lines including backend, model, seconds, and session handle), but it does not mention external CLI invocation, cost/quota implications, consent behavior, or whether it is safe/read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose and followed by the return format. There is no filler; every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description gives the essential purpose and a partial return-value explanation. Combined with the very high schema coverage, this is mostly complete, though it omits sibling differentiation and cost/consent context an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 92%, so the schema already documents nearly all 12 parameters in detail. The description adds no parameter-specific guidance beyond implicitly referencing the returned session handle; baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear specific purpose: "Second opinion on a question, design, bug or plan." It states the resource and the type of output. It does not explicitly distinguish itself from the sibling tool "review," so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "Second opinion" implies usage after forming a proposal, but the description does not state when to use this tool versus siblings such as review or doctor. It gives no explicit exclusions or alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
doctorC
Models per backend: efforts, output prices, approval need; or backend health.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | models (default, cached); health: install, sign-in, quota. | |
| detail | No | ||
| backend | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It never states that this is a read-only diagnostic, whether the cached 'models' data can be refreshed, what permissions or auth the 'health' check requires (install, sign-in, quota are only in the schema), or how expensive/slow a health probe is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single compact sentence with no filler and the mode distinction is front-loaded, but the telegraphic clause-splicing ('efforts, output prices, approval need; or backend health') is cryptic enough that terseness costs comprehension rather than buying it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-optional-parameter tool with no annotations and no output schema, the description should clarify both modes and the effect of detail/backend. It only sketches the models mode's outputs and leaves health-mode behavior and parameter effects to be inferred, which is insufficient given the missing structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — 'scope' is documented in the schema, but 'detail' and 'backend' are bare enums with no explanation in either place. The description hints at 'per backend' and full output contents but does not explain what 'detail: full' adds or what the 'agy'/'codex'/'claude' backends differ in, so the low-coverage gap is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('models per backend') and enumerates specific outputs (efforts, output prices, approval need), plus an alternative mode (backend health). However, it omits an explicit verb and is written as a telegraphic noun phrase, so the agent must infer that this is a diagnostic/reporting tool rather than, say, a configuration setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'or backend health' implies the two modes and roughly matches the scope enum, giving implied usage. But there is no explicit guidance on when to prefer health vs models, and no differentiation from siblings like consult, review, or issue, which an agent would need to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
issueC
Sanitized bug report with GitHub link. Be concise and actionable: reproduction steps, expected/actual behavior, impact, sanitized telemetry (tool/backend/model, CLI versions, errors, timing, scope/check evidence). Mark unknown facts; never invent them. Keep issueUrl verbatim; do not decode or re-escape it.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | What led to it. | |
| error_message | No | ||
| include_doctor | No | Default true: CLI versions only, no readiness/quota. |
Output Schema
| Name | Required | Description |
|---|---|---|
| body | Yes | |
| title | Yes | |
| prompt | Yes | |
| issueUrl | Yes | |
| pasteRequired | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, permissions, and mutation behavior. It does mention sanitization and not inventing facts, but it never says whether the tool submits to GitHub, writes a file, or is otherwise read-only or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the artifact and then lists actionable content requirements in a compact paragraph. Most clauses earn their place, though the long parenthetical telemetry checklist could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but the description still omits core behavioral context: whether this tool files an issue, drafts a report, or performs a write action. The missing explanation for issueUrl, which is not in the schema, further leaves the agent with unresolved questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the schema documents two of three parameters, and the description does not add clear meaning for context, error_message, or include_doctor beyond what is already in the schema. It also references "issueUrl" verbatim even though no such parameter exists in the input schema, which creates confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the artifact as a "Sanitized bug report with GitHub link" but never states the action: whether the tool creates, drafts, formats, or submits an issue. It is not a tautology because it adds the bug-report artifact and GitHub-link scope, but the verb is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives content instructions for what a good bug report should include, but provides no when-to-use guidance relative to siblings such as doctor, consult, or review. There is no explicit condition, prerequisite, or alternative tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reviewA
Independent review of Git changes: findings, then "Verdict: READY" or "Verdict: BLOCKED (reason)". Read-only: runs no checks; an unchanged complete repeat cannot help.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Omit unless the user names a model or price limit. doctor lists models, efforts and prices; unknown names fail. Tag ask: ask the user first, a form follows; deny: never runs. | |
| scope | No | uncommitted (default), staged, a commit, a branch or a range a...b. | |
| target | No | ||
| backend | No | codex: Codex CLI; claude: Claude Code; agy: Antigravity. auto (default): configured provider, else another CLI than yours, most cached quota. | |
| timeout_ms | No | Monotonic call budget, ms: Git, prep, consent, CLI turn, teardown. | |
| instructions | No | Review focus. | |
| session_handle | No | Same-topic follow-up: footer handle; else a fresh agent rereads all. | |
| workspace_path | No | Repository path; omit for client workspace (footer fallback). | |
| reasoning_effort | No | Omit for the default; doctor lists per-model values. Required where listed, or as a model name suffix. | |
| output_price_below | No | User limit, USD per million output tokens, strict (5 excludes 5). Only verified prices qualify; server picks default or newest. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it usefully discloses read-only behavior, that no checks execute, and that identical repeats add nothing. It omits significant traits implied by the schema — that an external CLI provider is invoked (model/backend), with quota cost, latency, and a consent flow ('Tag ask', 'consent' in timeout_ms) — which an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero filler; the verdict format leads and the read-only caveat follows. The closing clause 'an unchanged complete repeat cannot help' is slightly awkward phrasing but still compact and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 optional parameters, 90% schema coverage, and no output schema, the description fills the main gap by specifying the return format (findings plus a verdict line). What it lacks is the operational context of delegating to an external CLI agent (cost/quota, consent, latency), which is the main residual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so nearly every parameter (scope, backend, model, session_handle, timeout_ms) is already documented in the schema itself. The description adds no parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Independent review of Git changes') plus the exact output shape (findings, then a 'Verdict: READY'/'BLOCKED (reason)' line). That is enough to tell it apart from siblings like consult and doctor, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read-only: runs no checks' and 'an unchanged complete repeat cannot help' imply boundaries and a when-not-to-repeat rule. However, no sibling is named as the alternative and there is no explicit 'use this when X, use consult when Y' routing, so the agent must infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sessionC
List, page history or close sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | history. | |
| action | Yes | ||
| cursor | No | history. | |
| delete_history | No | close: drop history. | |
| session_handle | No | history/close. | |
| workspace_path | No | Repository path; omit for client workspace (footer fallback). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it never states that 'close' is a mutating (likely irreversible) operation or that delete_history permanently drops history. It also omits permission requirements and pagination behavior for history paging, which matters for a tool with a mix of read and write modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the operations front-loaded and no wasted words. It is efficient, though the terseness borders on under-specification given the destructive mode it hides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description should at least flag the destructive nature of close/delete_history and clarify the list-vs-history distinction. As written, an agent could invoke a destructive close without warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the structured fields already document most parameters (cursor and limit apply to history, session_handle to history/close, workspace_path fallback behavior). The description adds nothing beyond restating the action verbs, so the baseline 3 applies rather than a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names three concrete operations (list, page history, close) on the resource 'sessions', which maps cleanly onto the action enum. It is clear what the tool does, though it offers no differentiation from the sibling tools (doctor, consult, review, cancel, issue).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It lists the modes but never says when to choose list over history or close, nor what the prerequisites are for closing a session. No exclusions or alternative tools are mentioned, leaving the agent to infer selection from the bare action enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v0.7.0- First observed
cancel - First observed
consult - First observed
doctor - First observed
issue - First observed
review - First observed
session
TDQS
Scored across 6 tools
Each tool has a clearly distinct role: diagnostics, second-opinion consultation, Git review, session management, cancellation, and bug reporting. Consult vs. review is the closest overlap, but the descriptions sharply scope review to Git changes with a verdict while consult is for general questions, designs, bugs, or plans.
All names are lowercase single words, which is readable, but there is no consistent verb_noun or category pattern. The set mixes nouns and verbs (session, issue, doctor vs. consult, review, cancel), making the naming convention only partially predictable.
Six tools is well within a sensible range for this server's apparent consultation/review/session-management purpose. Each tool appears to earn its place without excessive fragmentation.
The surface covers diagnostics, consultation, review, session listing/history/closing, cancellation, and issue reporting, which is strong lifecycle coverage for the apparent domain. Minor gaps remain around explicitly starting/resuming sessions or follow-up interactions, but agents can likely work around them.
Maintenance
Related MCP Connectors
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceMCP server that bridges coding agents (Claude Code, Codex, Gemini CLI) via ACP for pair programming, enabling agents to consult each other as tools.3-
- AlicenseNot gradedqualityBmaintenanceMCP server enabling Claude to consult Codex (GPT-5.x) mid-task for second opinions, plan/diff review, brainstorming, and codebase exploration via structured debates and permission-controlled interactions.2MIT
- FlicenseBqualityDmaintenanceMCP server that gives AI coding agents (Claude Code, Cursor, Cline, etc.) access to multiple AI models through Antigravity CLI and OpenAI Codex CLI, enabling mid-conversation model consultation and code review.8-
- AlicenseAqualityAmaintenanceBridges multiple CLI coding agents (Codex, Cursor, OpenCode, Claude, Antigravity) into any MCP client, enabling delegation of prompts, parallel execution, and code review workflows.662 npmMozilla Public 2.0