Skip to main content
Glama

CoAgent8 - Cooperating coding agents

CI npm next Status License

Node.js Platforms MCP Backends

TypeScript Coverage gate Conventional Commits

Documentation

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

Codex CLI

Also found inside the OpenAI VS Code extension

Claude Code

2.1.289 or later; subscription login or API key

Antigravity CLI (agy)

Also installed by the Google Antigravity VS Code extension (~/.gemini/bin)

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:

  1. 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.

  2. 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.

  3. 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,agy

Setup 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. consult answers a question; review checks Git changes and derives a READY or BLOCKED verdict 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. doctor lists models, efforts and prices and checks installation, sign-in and quota; issue prepares 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

app-server with sandbox_mode="read-only" and approval_policy="never"; the thread's read-only state is verified, every inherited MCP server is disabled and verified per thread, server approval requests are rejected, interrupt via turn/interrupt

Claude Code (2.1.289+)

-p --restricted --tools Read,Glob,Grep --permission-mode dontAsk, hooks disabled, strict empty MCP configuration; startup tools, MCP and permission mode verified before any content; native session resume and control interrupt

Antigravity (agy)

Headless --sandbox --output-format stream-json, prompt on stdin, explicit model, native --conversation resume; inherits your agy MCP servers and plugins (see known limitations), recursion into CoAgent8 refused

Routing

  • backend: auto (default), codex, claude, agy or smart_quota. A model name alone also chooses its backend.

  • config.json can fix a default backend or select the smart_quota strategy, limited by allowedBackends.

  • auto uses 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; doctor with scope: "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, then backends.<id>.defaultModel, then the CLI's own default. CoAgent8 itself names no model.

  • reasoning_effort: none, minimal, low, medium, high, xhigh or max, 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.models come first: deny never runs a model, ask asks before every turn, allow runs it without asking (deny wins over ask, ask over allow). Any other model asks when its price is unknown or approximate, at or above governance.askAbovePrice (default 20 USD per million output tokens), or at least governance.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 as npm 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 in allowedChecks of 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 it BLOCKED (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_handle keeps the session's model and effort.

  • session with action: "history" pages events with cursor and limit (up to 100 events and 240 KiB per page). Each event's sequence is its position in the stored log, so gaps where streaming deltas were combined do not mean lost events, and activePid identifies the CoAgent8 server process owning the active turn. MCP resources coagent8://sessions and coagent8://sessions/{id}/history show 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=off turns 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_ms from 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_DENIED or PRICE_LIMIT.

Tools

Tool

Purpose

consult

A second opinion on a question, design, plan or bug; optional architecture, debugging or implementation analysis

review

An independent review of Git changes with a verdict CoAgent8 derives; large changes in parts, and checks CoAgent8 runs first (both 0.8.0)

delegate (0.8.0)

Another agent makes a code change in the workspace, asked to keep to the scope paths (changes outside them are reported, not prevented) and to run checks; with loop: true CoAgent8 runs the checks and an independent review and returns failures to the agent. The call returns once the agent runs, with a task handle and a wait command; mode: "sync" waits instead; the result adds the files CoAgent8 saw change in Git, with warnings for changes outside the scope, to files that already had uncommitted changes, and commits. Agents in a work tree must have disjoint scopes: an overlapping start is refused, and no scope or loop: true takes the whole work tree. root_handle puts agents under one budget; it never commits

doctor

Models, efforts, output prices, defaults and approval per backend; scope: "health" checks installation, versions, sign-in and quota; detail: "full" returns data

session

List the workspace's sessions (mine: true for your own), page a session's history (cursor and limit) or its messages only, read a delegation's task, or close a session

cancel

Stop the running turn of a session: interrupt where the CLI supports it, then end the CLI process. From 0.8.0, root_handle stops every delegated agent of a root instead

issue

Prepare a sanitized bug report (attaching detected CLI versions when include_doctor is true, the default) and a GitHub bug report form link to paste it into

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

coagent8-consult

Ask another agent for a second opinion on a question, design, plan or bug

coagent8-review

Have another agent review Git changes and read the verdict

coagent8-doctor

See models, efforts and prices, apply a price limit, check backend health

coagent8-session

List, read, continue, cancel or close sessions

coagent8-issue

Prepare a sanitized CoAgent8 bug report

coagent8-delegate (0.8.0)

Hand a defined code change to another agent, then check what it changed

coagent8-loop

Plan, get the plan reviewed, implement or delegate, run checks and get an independent review

Client

Skill directory

Claude Code

~/.claude/skills/

Codex

~/.agents/skills/

Antigravity

~/.gemini/config/skills/

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-review

Changes 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

CoAgent8: Manage Coding CLIs

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

CoAgent8: Manage Model Approvals

Allows, asks for or denies individual models, and sets the price rules for asking

CoAgent8: Manage Skills

Installs, updates, uninstalls, enables or disables skills per client

CoAgent8: Open Settings

Opens CoAgent8's backend, model, configuration path and Node.js settings

CoAgent8: Open Configuration (config.json)

Opens the configuration file (~/.coagent8/config.json unless coagent8.configPath or coagent8_CONFIG names another), creating it with defaults if missing, with completion and validation (a file in another location needs a $schema entry, which new files get)

CoAgent8: Reset Configuration (config.json)

Replaces the file with the defaults after a confirmation, keeping the previous one as config.json.backup

CoAgent8: Show MCP Servers

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

coagent8_CONFIG

Configuration file path

coagent8_DIR

Storage root for sessions, history and caches (default ~/.coagent8)

coagent8_HISTORY

off turns archive files off

coagent8_PRICES_URL

Price list URL or local file instead of OpenRouter

coagent8_QUOTA_CACHE

Quota cache file

CODEX_PATH, CLAUDE_PATH, AGY_PATH

Backend executables; they override backends.<id>.executable

CODEX_HOME, CODEX_CONFIG_PATH, CLAUDE_CONFIG_DIR, GEMINI_CLI_HOME

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; doctor lists them. Calls back into CoAgent8 are refused.

  • Antigravity readiness. agy may report not ready in a cached check and still run a turn; doctor with scope: "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 consult with no model and no price limit runs the backend's default model (still subject to your approval thresholds); pass output_price_below or 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 delegate with loop: 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 in allowedChecks of 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 pwsh or 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 build

The 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

Contributing

Security support and private reports

Security policy

Planned work and priorities

Issues, Roadmap

Contracts, limitations and design

Architecture

Contributor rules

AGENTS.md

Branches, pull requests and releases

Git workflow

Checks by scope

Quality gate

Release history

Changelog

Documentation site: this README, the project documents and the source API

oktawianwybieralski.github.io/coagent8

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 tools
cancelC

Stop the running turn: interrupt if possible, then end the CLI.

NameRequiredDescriptionDefault
session_handleYes
workspace_pathNoRepository path; omit for client workspace (footer fallback).

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

NameRequiredDescriptionDefault
modelNoOmit 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.
backendNocodex: Codex CLI; claude: Claude Code; agy: Antigravity. auto (default): configured provider, else another CLI than yours, most cached quota.
proposalYesSelf-contained question or plan; name files instead of pasting them. Bad: "thoughts?"
task_typeNoOmit for a plain question; set to ask for that kind of analysis.
file_pathsNo
timeout_msNoMonotonic call budget, ms: Git, prep, consent, CLI turn, teardown.
context_filesNoWorkspace paths the agent reads itself; only the paths are sent.
session_handleNoSame-topic follow-up: footer handle; else a fresh agent rereads all.
workspace_pathNoRepository path; omit for client workspace (footer fallback).
reasoning_effortNoOmit for the default; doctor lists per-model values. Required where listed, or as a model name suffix.
output_price_belowNoUser limit, USD per million output tokens, strict (5 excludes 5). Only verified prices qualify; server picks default or newest.
specific_questionsNoExtra questions or criteria the answer must cover.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
scopeNomodels (default, cached); health: install, sign-in, quota.
detailNo
backendNo

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose3/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
contextNoWhat led to it.
error_messageNo
include_doctorNoDefault true: CLI versions only, no readiness/quota.

Output Schema

NameRequiredDescription
bodyYes
titleYes
promptYes
issueUrlYes
pasteRequiredYes

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

NameRequiredDescriptionDefault
modelNoOmit 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.
scopeNouncommitted (default), staged, a commit, a branch or a range a...b.
targetNo
backendNocodex: Codex CLI; claude: Claude Code; agy: Antigravity. auto (default): configured provider, else another CLI than yours, most cached quota.
timeout_msNoMonotonic call budget, ms: Git, prep, consent, CLI turn, teardown.
instructionsNoReview focus.
session_handleNoSame-topic follow-up: footer handle; else a fresh agent rereads all.
workspace_pathNoRepository path; omit for client workspace (footer fallback).
reasoning_effortNoOmit for the default; doctor lists per-model values. Required where listed, or as a model name suffix.
output_price_belowNoUser limit, USD per million output tokens, strict (5 excludes 5). Only verified prices qualify; server picks default or newest.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
limitNohistory.
actionYes
cursorNohistory.
delete_historyNoclose: drop history.
session_handleNohistory/close.
workspace_pathNoRepository path; omit for client workspace (footer fallback).

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 6 tool updatesv0.7.0
    • First observedcancel
    • First observedconsult
    • First observeddoctor
    • First observedissue
    • First observedreview
    • First observedsession

TDQS

B3.2/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    B
    maintenance
    MCP server that bridges coding agents (Claude Code, Codex, Gemini CLI) via ACP for pair programming, enabling agents to consult each other as tools.
    3
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP 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.
    2
    MIT