ai-cli-mcp
This server lets LLMs run and manage multiple AI CLI coding agents (Claude, Codex, Gemini/Antigravity, Grok, OpenCode, Pi) as background processes.
Run AI agents: Start coding/model tasks using a wide range of Claude, Codex, Gemini, Grok, OpenCode, and Pi models.
True async multitasking: Launch multiple agents in parallel, each returning a PID immediately.
Wait for completion: Block until one or more PIDs finish, with configurable timeout, and return combined results.
Check results: Retrieve compact or verbose output, status, exit code, model, session ID, and tool history via
get_result.Peek at live events: Observe messages and normalized tool-call events during a short observation window.
Manage processes: List all processes, kill individual processes, and clean up completed/failed runs.
Resume sessions: Pass a
session_idto continue previous Claude, Codex, Gemini, OpenCode, Grok, or Pi sessions.Diagnose setup: Run
doctorto check CLI binary availability and path resolution.Discover models: List supported models, dynamic OpenCode/Pi models, and effective aliases.
Use custom aliases: Define reusable model aliases with default reasoning efforts via CLI or MCP.
File/code/git/terminal work: Agents can read/edit files, refactor code, run terminal commands, handle Git workflows, web search, and more.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ai-cli-mcpRun sonnet to refactor the backend code"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI CLI MCP Server
📦 Package Migration Notice: This package was formerly
@mkxultra/claude-code-mcpand has been renamed toai-cli-mcpto reflect its expanded support for multiple AI CLI tools.
An MCP (Model Context Protocol) server that allows running AI CLI tools (Claude, Codex, Gemini, OpenCode, Grok, and Pi) in background processes with automatic permission handling.
Did you notice that Cursor sometimes struggles with complex, multi-step edits or operations? This server, with its powerful unified run tool, enables multiple AI agents to handle your coding tasks more effectively.
Demo

Related MCP server: all-agents-mcp
Overview
This MCP server provides tools that can be used by LLMs to interact with AI CLI tools. When integrated with MCP clients, it allows LLMs to:
Run Claude CLI with all permissions bypassed (using
--dangerously-skip-permissions)Execute Codex CLI with approvals and sandbox bypassed (using
--dangerously-bypass-approvals-and-sandbox)Execute Gemini models through Antigravity CLI (
agy --print,stream-json, and--dangerously-skip-permissions)Execute Grok Build CLI headlessly with
streaming-messages-json, automatic tool approval, and automatic updates disabledExecute OpenCode in non-interactive JSON mode (using
opencode run --format json --dir <workFolder> <prompt>)Execute Pi in non-interactive JSON mode with tool approval enabled for unattended runs
Support multiple AI models: Claude (sonnet, sonnet[1m], opus, opusplan, fable, haiku), Codex (gpt-6-astra, gpt-6-sol, gpt-6-luna, gpt-5.4, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5, gpt-5.4-mini, gpt-5.3-codex, gpt-5.3-codex-spark, gpt-5.2), Gemini (gemini-3.8-flash-high/medium/low, gemini-3.7-flash-high/medium/low, gemini-3.6-flash-high/medium/low, gemini-3.1-pro-high/low), Grok (
grok,grok-4.6,grok-4.5), OpenCode (opencodeplusoc-<provider/model>), and Pi (pipluspi-<provider/model>)Manage background processes with PID tracking
Parse and return structured outputs from both tools
Usage Example (Advanced Parallel Processing)
You can instruct your main agent to run multiple tasks in parallel like this:
Launch agents for the following 3 tasks using acm mcp run:
Refactor
src/backendcode usingsonnetCreate unit tests for
src/frontendusinggpt-5.3-codexUpdate docs in
docs/usinggemini-3.1-pro-highWhile they run, please update the TODO list. Once done, use the
waittool to wait for all completions and report the results together.
Usage Example (Context Caching & Sharing)
You can reuse heavy context (like large codebases) using session IDs to save costs while running multiple tasks.
First, use
acm mcp runwithopusto read all files insrc/and understand the project structure.Use the
waittool to wait for completion and retrieve thesession_idfrom the result.Using that
session_id, run the following two tasks in parallel withacm mcp run:
Create refactoring proposals for
src/utilsusingsonnetAdd architecture documentation to
README.mdusinggpt-5.3-codexFinally,
waitagain to combine both results.

Benefits
True Async Multitasking: Agent execution happens in the background, returning control immediately. The calling AI can proceed with the next task or invoke another agent without waiting for completion.
CLI in CLI (Agent in Agent): Directly invoke powerful CLI tools like Claude Code or Codex from any MCP-supported IDE or CLI. This enables broader, more complex system operations and automation beyond host environment limitations.
Freedom from Model/Provider Constraints: Freely select and combine the "strongest" or "most cost-effective" models from Claude, Codex (GPT), Gemini, OpenCode, Grok, and Pi without being tied to a specific ecosystem.
Prerequisites
The only prerequisite is that the AI CLI tools you want to use are locally installed and correctly configured.
Claude Code:
claude doctorpasses, and execution with--dangerously-skip-permissionsis approved (you must run it manually once to login and accept terms).Codex CLI (Optional): Installed and initial setup (login etc.) completed.
Antigravity CLI (Optional, for Gemini models): Install
agyand sign in once; tested with 1.2.5. See the migration instructions below.Grok Build CLI (Optional): Install and authenticate Grok locally (tested with 1.0.13 and OAuth). Discovery checks
~/.grok/bin/grok, thenPATH;GROK_CLI_NAMEoverrides either with a command name or absolute path.OpenCode (Optional): Installed and configured. This integration uses
opencode run --format json, and explicit provider/model selection follows theoc-<provider/model>wrapper syntax exposed byai-cli models.Pi (Optional): Install and authenticate Pi locally (tested with 0.86.1). Run
pi --list-modelsto see the provider/model pairs available to your account.PI_CLI_NAMEoverrides the binary name or path.
Installation & Usage
Antigravity CLI for Gemini models
The Gemini backend uses Google's Antigravity CLI (agy, tested with 1.2.5). On macOS/Linux:
curl -fsSL https://antigravity.google/cli/install.sh | bash
~/.local/bin/agy # Sign in once interactively
agy models
ai-cli run --cwd /path/to/project --model gemini-ultra --prompt "Review this project"On Windows, follow the official PowerShell instructions. Discovery checks ~/.local/bin/agy on macOS/Linux or %LOCALAPPDATA%/agy/bin/agy.exe on Windows, then PATH. Set ANTIGRAVITY_CLI_NAME to override this path.
The backend key remains gemini in doctor, models, and process results. The built-in gemini-ultra selects gemini-3.8-flash-high. Update custom aliases targeting old Gemini CLI names with ai-cli alias add; agy models lists the names available to your account. A supplied reasoning_effort must match the model suffix (for example, gemini-3.8-flash-medium with medium). Other Antigravity model families are not routed through this backend.
peek reads incremental assistant text and optional tool start/completion events. get_result/ai-cli result return the final response and expose Antigravity's conversation_id as session_id; pass it to the next run to resume with --conversation. Old Gemini CLI output parsing and session resumption are not supported.
This integration sets Antigravity's run limit to two hours (2h) by default. Set ANTIGRAVITY_PRINT_TIMEOUT=1h (or another positive duration) in the environment of ai-cli or the MCP server to override it. Antigravity's 0 means an immediate timeout. ACM wait(timeout: 0) only removes the waiting deadline and does not change this separate run limit.
There are now two primary ways to use this package:
ai-cli-mcp: MCP server entrypointai-cli: human-facing CLI for background AI runs
MCP usage with npx
The recommended way to use the MCP server is via npx.
Using npx in your MCP configuration:
"ai-cli-mcp": {
"command": "npx",
"args": [
"-y",
"ai-cli-mcp@latest"
]
},Using Claude CLI mcp add command:
claude mcp add ai-cli '{"name":"ai-cli","command":"npx","args":["-y","ai-cli-mcp@latest"]}'Human CLI usage with global install
If you want to use the production CLI directly from your shell, install the package globally:
npm install -g ai-cli-mcpThis exposes both commands:
ai-cliai-cli-mcp
Examples:
ai-cli doctor
ai-cli models
ai-cli run --cwd "$PWD" --model sonnet --prompt "summarize this repository"
ai-cli run --cwd "$PWD" --model opencode --prompt "summarize this repository with OpenCode defaults"
ai-cli run --cwd "$PWD" --model oc-openai/gpt-5.4 --session-id ses_123 --prompt "continue this session with an explicit OpenCode model"
ai-cli run --cwd "$PWD" --model pi-openai-codex/gpt-6-astra --reasoning-effort high --prompt "review this repository with Pi"
ai-cli ps
ai-cli result 12345
ai-cli result 12345 --verbose
ai-cli peek 12345 --time 10
ai-cli wait 12345 --timeout 300
ai-cli wait 12345 --timeout 0
ai-cli wait 12345 --verbose
ai-cli kill 12345
ai-cli cleanup
ai-cli-mcpHuman CLI usage with npx
Because the published package name is still ai-cli-mcp, the shortest npx form for the CLI is:
npx -y --package ai-cli-mcp@latest ai-cli run --cwd "$PWD" --model sonnet --prompt "hello"
npx -y --package ai-cli-mcp@latest ai-cli run --cwd "$PWD" --model oc-openai/gpt-5.4 --prompt "hello from OpenCode"Important First-Time Setup
Forge CLI support has been removed. models and doctor no longer include Forge, and model: "forge" is rejected. In your user configuration, remove aliases targeting forge or change their targets to supported models. FORGE_CLI_NAME is no longer used.
For Claude CLI:
Before the MCP server can use Claude, you must first run the Claude CLI manually once with the --dangerously-skip-permissions flag, login and accept the terms.
npm install -g @anthropic-ai/claude-code
claude --dangerously-skip-permissionsFollow the prompts to accept. Once this is done, the MCP server will be able to use the flag non-interactively.
For Codex CLI:
For Codex, ensure you're logged in and have accepted any necessary terms:
codex loginFor Antigravity CLI (Gemini):
Start Antigravity once interactively to sign in:
agymacOS might ask for folder permissions the first time any of these tools run. If the first run fails, subsequent runs should work.
CLI Commands
ai-cli currently supports:
runpsresultpeekwaitkillcleanupdoctormodelsalias list/alias add/alias rmmcp
Example flow:
ai-cli doctor
ai-cli models
ai-cli run --cwd "$PWD" --model gpt-5.4 --prompt "use the default Codex model"
ai-cli run --cwd "$PWD" --model codex-ultra --prompt "fix failing tests"
ai-cli run --cwd "$PWD" --model opencode --session-id ses_existing --prompt "continue this OpenCode session"
ai-cli run --cwd "$PWD" --model oc-openai/gpt-5.4 --prompt "run with an explicit OpenCode backend model"
ai-cli run --cwd "$PWD" --model pi --prompt "run with Pi's configured default model"
ai-cli run --cwd "$PWD" --model pi-openai-codex/gpt-6-astra --reasoning-effort xhigh --prompt "run Pi with an explicit model"
ai-cli ps
ai-cli peek 12345 --time 10
ai-cli peek 12345 12346 --time 10
ai-cli wait 12345
ai-cli wait 12345 --verbose
ai-cli result 12345
ai-cli result 12345 --verbose
ai-cli cleanuprun accepts --cwd as the primary working-directory flag and also accepts the older aliases --workFolder / --work-folder for compatibility.
OpenCode model selection accepts either:
opencodefor the CLI's configured default modeloc-<provider/model>for an explicit OpenCode provider/model, for exampleoc-openai/gpt-5.4
ai-cli models runs opencode models and returns opencode plus discovered names such as oc-openai/gpt-6-astra in the opencode array. Each name can be passed directly to run. Discovery status and errors are available in dynamicModelBackends.opencode.discovery.
Codex model selection uses gpt-5.4 as the default advertised model. Select gpt-6-sol for the new Sol model or gpt-6-luna for the new Luna model. Both accept low, medium, high, xhigh, and max reasoning; Sol also accepts ultra. For example: ai-cli run --cwd "$PWD" --model gpt-6-sol --reasoning-effort ultra --prompt "Review this project".
doctor checks only binary availability and path resolution. Its JSON output includes a checks block that marks login state and terms acceptance as unchecked.
Pi CLI
Install Pi and sign in once before starting ai-cli or the MCP server. This integration was verified with Pi 0.86.1.
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
pi # use /login if authentication is not configured
pi --list-modelsUse pi to let Pi select its configured default model. Use pi-<provider/model> for an explicit model, for example pi-openai-codex/gpt-6-astra. ai-cli models runs pi --list-models and includes these names after pi in its pi array. dynamicModelBackends.pi.discovery reports discovery status; reasoningEfforts.pi lists off, minimal, low, medium, high, xhigh, and max. Omitting reasoning_effort leaves the choice to Pi.
ai-cli run --cwd "$PWD" --model pi --prompt "Explain this project"
ai-cli run --cwd "$PWD" --model pi-openai-codex/gpt-6-astra --reasoning-effort xhigh --prompt "Review this change"
ai-cli alias add pi-coding pi-openai-codex/gpt-5.6-terra --effort high
ai-cli run --cwd "$PWD" --model pi-coding --session-id <session_id> --prompt "Continue"Runs use pi --mode json --approve, optional --model, --thinking, and --session, followed by -p -- <prompt>. The --approve flag lets Pi load project resources and execute its configured tools without an interactive confirmation. The existing workFolder and process isolation rules still apply.
peek accumulates Pi text_delta events and optionally reports normalized tool_execution_start / tool_execution_end events. Thinking deltas, tool updates, and raw tool output are excluded. get_result and wait return the final text, provider, model, usage, stop reason, and Pi session ID. Passing that ID to the next run resumes the same session with --session. Verbose results include detailed tool history; compact results omit it. Failed runs preserve diagnostic stderr, and cancellation uses the same process-tree termination used for Grok and Antigravity.
Grok Build CLI
See the Grok headless guide for authentication and CLI setup.
With no user alias named grok, both MCP and ai-cli route grok and native grok-* names to Grok. grok omits --model, using the Grok CLI configuration; explicit names select that model. models includes grok: ["grok", "grok-4.6", "grok-4.5"] and reasoningEfforts.grok with the accepted levels. Other native names are forwarded, with common low/medium/high effort validation; model availability is determined by Grok.
ai-cli run --cwd "$PWD" --model grok --prompt "Explain this project"
ai-cli run --cwd "$PWD" --model grok-4.6 --reasoning-effort xhigh --prompt "Review this change"
ai-cli alias add grok-coding grok-4.6 --effort high
ai-cli run --cwd "$PWD" --model grok-coding --session-id <session_id> --prompt "Continue"A preexisting user alias named grok keeps precedence, including aliases that target OpenCode. It remains visible in models and alias list and does not affect unrelated runs or MCP tool discovery. Explicit grok-4.6 / grok-4.5 always select the native backend. To use the CLI-configured provider default, rename that alias or explicitly remove it with ai-cli alias rm grok; upgrades never edit your configuration.
The same alias and model, reasoning_effort, and session_id fields work in MCP run. Aliases use the existing user configuration. With no effort supplied, Grok decides the effort. The provider key grok accepts low/medium/high; select grok-4.6 explicitly for xhigh. grok-4.5 accepts low/medium/high. Neither accepts max or ultra.
Commands use grok --single=<prompt> --cwd <workFolder> --output-format streaming-messages-json --always-approve --no-auto-update, plus optional model, effort, and --resume=<session_id>. Attached values preserve leading hyphens and newlines. At the ai-cli surface use --prompt="--text" / --session-id="--id" for values starting with --, or use a prompt file. This follows the existing unattended tool approval policy. Authenticate with Grok before use; doctor.grok checks binary discovery only. The Grok 1.0.13 models command can show an unauthenticated banner even when OAuth headless execution works, so that banner is not used as an authentication test.
peek observes whole assistant messages during the call, plus optional normalized tool start/completion events. Thinking, token deltas, and raw tool output are excluded. get_result and wait return the final answer and session ID, or available assistant text while running. When present, Grok model/usage/cost metadata and terminal is_error, subtype, errors, and stop_reason are retained. Failures also preserve diagnostic stderr, including after a partial answer. Verbose results include detailed tools. kill/kill_process terminate the tracked process and its tool descendants; POSIX cancellation uses ps and signals, and Windows uses taskkill /t /f. If ps is unavailable, it still signals the tracked PID and its owned group, verifies exit and escalates to SIGKILL if needed; the kill response and failure stderr warn that descendants in other groups may survive. The MCP host stops tracked work on SIGINT/SIGTERM/SIGHUP and stdin/transport closure. Group signals target only groups created for tracked work, never the MCP host group.
During MCP cancellation, the Grok root may report failed/143 while its tool descendants are still stopping. Overlapping kill_process calls and host shutdown await the same tree termination; cleanup_processes retains the entry until that operation settles. If the first signal fails before any signal is delivered, the error is returned and later natural completion keeps its actual status and exit code.
User Model Aliases
Save a model and its default reasoning effort under a name you can use across projects. CLI and MCP share the same user configuration.
Manage and use aliases from the CLI
The built-in aliases sol and luna select gpt-6-sol and gpt-6-luna. They do not set a reasoning effort: omit --reasoning-effort to use the Codex CLI default, or specify it for a run. For example, ai-cli run --cwd "$PWD" --model sol --prompt "Review this project". User aliases with the same names override these defaults; removing the user override with ai-cli alias rm sol restores the built-in target.
ai-cli alias add codex-coding gpt-5.6-terra --effort xhigh
ai-cli alias add claude-review opus --effort max
ai-cli alias list
ai-cli run --cwd "$PWD" --model codex-coding --prompt "fix failing tests"Here, codex-coding runs gpt-5.6-terra with xhigh reasoning. Override the effort for a single run with --reasoning-effort low.
alias list prints JSON with configPath and an aliases array containing the effective built-in and user aliases. Each entry has name, resolvesTo, agent, and optional defaultReasoningEffort, matching the aliases in ai-cli models. Listing does not create or modify the config file. Use ai-cli models to include the supported model catalog as well.
alias add <name> <model> [--effort <level>] creates the config file and its parent directories if needed, including an explicitly selected AI_CLI_CONFIG_PATH. Reusing a name replaces its definition; omitting --effort clears any previous alias effort. --reasoning-effort and --reasoning_effort are also accepted. Invalid definitions leave the file unchanged.
# Update the default effort
ai-cli alias add codex-coding gpt-5.6-terra --effort high
# Clear the alias effort and use the target CLI's default
ai-cli alias add codex-coding gpt-5.6-terra
# Remove the user alias
ai-cli alias rm codex-codingalias rm <name> removes only a user definition. Removing an override such as codex-ultra restores the built-in default. Removing an unknown name or a built-in alias without a user override returns an error. Successful commands print JSON with the config path and the change made. Use ai-cli alias --help for usage.
# Override a built-in alias
ai-cli alias add codex-ultra gpt-5.6-terra --effort xhigh
# Restore its built-in gpt-6-astra / ultra definition
ai-cli alias rm codex-ultraUse aliases through MCP
After registering codex-coding as above, pass its name to the MCP run tool:
{
"workFolder": "/absolute/path/to/project",
"model": "codex-coding",
"prompt": "fix failing tests"
}Add "reasoning_effort": "low" to override the effort for that request. ai-cli models and the MCP models tool expose the effective aliases as aliases entries with name, resolvesTo, agent, and optional defaultReasoningEffort fields.
Config is read for each run, models, and MCP tool-list request. Changes apply to subsequent requests without restarting the MCP server, provided CLI and MCP use the same config path.
Configuration file and rules
The commands above edit ~/.config/ai-cli/config.json. You can also edit it directly; for example, this file defines both aliases from the first example:
{
"model_aliases": {
"codex-coding": {
"model": "gpt-5.6-terra",
"reasoning_effort": "xhigh"
},
"claude-review": {
"model": "opus",
"reasoning_effort": "max"
}
}
}modelis required;reasoning_effortis optional. The backend is selected from the target model, regardless of the alias name.Effort precedence is: explicit run argument → alias default → target CLI default. Effort must be supported by the target model; Antigravity effort must match the model suffix; OpenCode aliases must omit it.
User entries can override built-in aliases such as
codex-ultra. Each entry replaces the entire definition; omittingreasoning_effortuses the target CLI's default rather than inheriting the built-in effort.Targets must be native model names such as
gpt-5.6-terra,opus, oroc-openai/gpt-5.4; alias chaining is not supported. Alias names are case-sensitive, start with an ASCII letter, and contain only ASCII letters, digits,_, or-. Listed native model names,codex, and theoc-prefix are reserved, except that a user alias namedgrokretains precedence for compatibility.Missing default config files preserve built-in behavior. Malformed files and invalid model/effort combinations produce errors with the config path. A missing explicitly configured file also produces an error, except that
alias addcan create it.
An absolute XDG_CONFIG_HOME changes the default location to $XDG_CONFIG_HOME/ai-cli/config.json. AI_CLI_CONFIG_PATH overrides that location entirely; relative paths are resolved from the CLI/MCP process's working directory. For an MCP-specific path, set AI_CLI_CONFIG_PATH in the server's env settings. There is no project-level config lookup. The file uses JSON without comments and currently supports only model_aliases.
CLI State Storage
Background CLI runs are stored under:
~/.local/state/ai-cli/cwds/<normalized-cwd>/<pid>/Each PID directory contains:
meta.jsonstdout.logstderr.logexit-status.jsonfor detached runs
Use ai-cli cleanup to remove completed and failed runs. Running processes are preserved.
Exit Status Tracking
Detached ai-cli runs persist natural exit status for all supported backends through exit-status.json. Non-zero exits are surfaced as failed with the recorded exitCode; zero exits are surfaced as completed with exitCode: 0. ai-cli kill records SIGTERM termination as a failed exit, and a tracked process that disappears without exit metadata is treated as failed rather than assumed successful.
Connecting to Your MCP Client
After setting up the server, add the configuration to your MCP client's settings file (e.g., mcp.json for Cursor, mcp_config.json for Windsurf).
If the file doesn't exist, create it and add the ai-cli-mcp configuration.
Tools Provided
This server exposes the following tools:
run
Executes a prompt using Claude CLI, Codex CLI, Antigravity CLI (Gemini), OpenCode, Grok, or Pi. The appropriate CLI is automatically selected based on the model name.
Arguments:
prompt(string, optional): The prompt to send to the AI agent. Eitherpromptorprompt_fileis required.prompt_file(string, optional): Path to a file containing the prompt. Eitherpromptorprompt_fileis required. Can be absolute path or relative toworkFolder.workFolder(string, required): The working directory for the CLI execution. Must be an absolute path. Models:Ultra Aliases (built-in defaults; user config can override):
claude-ultra(opus, defaults to max effort and does not select Fable),codex-ultra(gpt-6-astra, defaults to ultra reasoning),gemini-ultraClaude:
sonnet,sonnet[1m],opus,opusplan,fable,haikufableexplicitly selects Claude Code's latest Fable model. Fable may require separately billed usage credits and is not selected by the built-inclaude-ultradefault.
Codex:
gpt-6-astra,gpt-6-sol,gpt-6-luna,gpt-5.4,gpt-5.6-sol,gpt-5.6-terra,gpt-5.6-luna,gpt-5.5,gpt-5.4-mini,gpt-5.3-codex,gpt-5.3-codex-spark,gpt-5.2Gemini:
gemini-3.8-flash-high,gemini-3.8-flash-medium,gemini-3.8-flash-low, Gemini 3.7/3.6 Flash variants,gemini-3.1-pro-high,gemini-3.1-pro-lowGrok:
grokfor its configured default,grok-4.6,grok-4.5, and other nativegrok-*namesOpenCode:
opencodefor the configured default backend model, plus explicit wrappers likeoc-openai/gpt-5.4Pi:
pifor its configured default model, plus explicit wrappers likepi-openai-codex/gpt-6-astrareasoning_effort(string, optional): Reasoning control for Claude, Codex, Grok, and Pi. Pi mapsoff|minimal|low|medium|high|xhigh|maxto--thinking. Grok uses--reasoning-effort:grok-4.6supports low/medium/high/xhigh;grok-4.5, thegrokconfigured default, and other native Grok names accept low/medium/high. Omit effort to use the CLI default; max/ultra are rejected for Grok. Claude uses--effort(allowed: "low", "medium", "high", "xhigh", "max"). Codex usesmodel_reasoning_effort(base levels: "low", "medium", "high", "xhigh"; GPT-6 Astra/Sol and GPT-5.6 Sol/Terra also support "max" and "ultra", while GPT-6 Luna and GPT-5.6 Luna support "max"). Antigravity accepts--effort low|medium|high, which must match the model name suffix when present. OpenCode does not supportreasoning_effort.session_id(string, optional): Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, OpenCode, Grok, and Pi. Grok resumes via--resume; OpenCode and Pi resume in place via--sessionand may also be combined with explicit model selection.
wait
Waits for multiple AI agent processes to complete and returns their combined results. Blocks until all specified PIDs finish or a timeout occurs.
Set timeout to 0 to wait until all specified processes finish without an ai-cli deadline. For example, call MCP wait with { "pids": [12345], "timeout": 0 }, or use ai-cli wait 12345 --timeout 0. MCP client or transport timeouts still apply independently. A finite wait timeout returns an error and leaves the processes running.
By default, each returned result item uses the compact shape shared with get_result(verbose: false): operational fields such as pid, agent, status, exitCode, model, parsed output such as agentOutput, and top-level session_id when available. Set verbose: true to include full metadata like startTime, workFolder, prompt, and detailed parsed output such as agentOutput.tools.
Arguments:
pids(array of numbers, required): List of process IDs to wait for (returned by theruntool).timeout(number, optional): Non-negative maximum wait time in seconds. Defaults to 180 (3 minutes);0disables the wait timeout.verbose(boolean, optional): Iftrue, each result item uses the full result shape. Defaults tofalse.
peek
Starts a one-shot short observation window for running child agents and returns structured events observed during that specific call. By default this includes only natural-language message events; pass include_tool_calls or --include-tool-calls to also include normalized tool-call events. It is not a history API, not gapless streaming, and not shell stdout/stderr tailing. Separate peek calls may miss events emitted between calls; --follow is intentionally not part of v1.
CLI v1:
ai-cli peek 123 --time 10
ai-cli peek 123 456 --time 10
ai-cli peek 123 --time 10 --include-tool-callsArguments:
pids(array of numbers, required): 1..32 process IDs returned byrun. Duplicate PIDs are deduplicated server-side, preserving first occurrence order. Unknown or unmanaged PIDs are returned per process asnot_found, not as a whole-call failure.peek_time_sec(number, optional): Positive integer observation length in seconds. Defaults to 10 and is capped at 60.0, negative values, and fractional values are invalid.include_tool_calls(boolean, optional): Whentrue, each processeventsarray includes normalizedtool_callevents in addition to message events. Defaults tofalse.
Observation and filtering:
peek_started_atandevents[].tsare ai-cli-mcp server-side UTC RFC3339 timestamps.peek_started_atis when the observation window starts after validation and listener registration;events[].tsis when ai-cli-mcp observed and accepted the event.The window ends when
peek_time_secelapses or all target processes reach a terminal state, whichever comes first.Events emitted before the window starts are not returned. Concurrent
peekcalls for the same PID are allowed; each has an independent window and may return overlapping events.Message events are recognized from Codex
agent_messagetext, Claude and Grok whole assistant text content, OpenCodetype: "text"events wherepart.typeis"text", Antigravitystep_updateevents, and Pitext_deltaevents.When tool calls are included,
tool_callevents are normalized for Codex command/MCP calls, Claude/Grok tool use/results, Antigravity tool steps, OpenCode tool use, and Pi tool execution start/end events. Tool summaries are bounded one-line strings derived from tool names and input metadata only. Raw tool and command output is excluded.Unknown event shapes are denied by default. Managed agents without supported extraction return their real process status with
events: [],truncated: false, anderror: null.Each PID keeps the first 50 events observed in the window. If later events are dropped,
truncatedistrue.statusis one ofrunning,completed,failed, ornot_found, and reflects state when the observation window closes.agentisclaude,codex,gemini,opencode,grok,pi, a future tracked string value, ornullwhen the process is not found or the agent cannot be determined.
Example response:
{
"peek_started_at": "2026-04-11T12:34:56.789Z",
"observed_duration_sec": 10.01,
"processes": [
{
"pid": 123,
"agent": "codex",
"status": "running",
"events": [
{ "kind": "message", "ts": "2026-04-11T12:34:59.120Z", "text": "I'm checking the implementation." },
{ "kind": "tool_call", "ts": "2026-04-11T12:35:00.000Z", "phase": "started", "id": "item_0", "tool": "command_execution", "summary": "/bin/sh -c 'echo hi'" }
],
"truncated": false,
"error": null
},
{
"pid": 999,
"agent": null,
"status": "not_found",
"events": [],
"truncated": false,
"error": "process not found"
}
]
}list_processes
Lists all running and completed AI agent processes with their status, PID, and basic info.
doctor
Checks supported AI CLI binary availability and path resolution from MCP clients. Like ai-cli doctor, it returns a checks block and does not verify login state or terms acceptance.
models
Lists supported model names and aliases, including models discovered by running pi --list-models and opencode models. This returns the same structured payload as ai-cli models. The pi and opencode arrays retain their default keys and append names ready for run.
The two discovery commands run concurrently with a 5-second timeout and a 1 MiB output limit per CLI. PI_CLI_NAME and OPENCODE_CLI_NAME overrides apply. Discovery uses the calling process's working directory and CLI configuration; listed models are not a guarantee of authentication or model access.
Each dynamicModelBackends.<backend>.discovery contains status (success or error), checkedAt, cached, and an error on failure. A missing CLI, timeout, or parsing error leaves that backend's default key and all other model lists and aliases available. An empty successful list has status: "success" and no additional names.
The MCP server caches discovery results, including failures, for 60 seconds and shares concurrent lookups. Each standalone ai-cli models invocation fetches fresh results. Changes to executable selection, working directory, or environment bypass the cache; changes to CLI config files appear after cache expiry. User aliases are read on every request. Listing MCP tools and starting runs do not trigger discovery.
The aliases array includes built-in defaults merged with user model aliases. Each entry contains name, resolvesTo, agent, and optional defaultReasoningEffort.
get_result
Gets the current output and status of an AI agent process by PID.
By default, this returns the compact result shape: operational fields such as pid, agent, status, exitCode, model, parsed output such as agentOutput, and top-level session_id when available. It omits metadata fields like startTime, workFolder, and prompt. Set verbose: true to return the full result shape including those metadata fields and detailed parsed output such as agentOutput.tools. If parsed output is unavailable or incomplete, the raw stdout/stderr fallback is preserved.
Arguments:
pid(number, required): The process ID returned by theruntool.verbose(boolean, optional): Iftrue, returns the full result shape. Defaults tofalse.
kill_process
Terminates a running AI agent process by PID.
Arguments:
pid(number, required): The process ID to terminate.
Troubleshooting
"Command not found" (claude-code-mcp): If installed globally, ensure the npm global bin directory is in your system's PATH. If using
npx, ensurenpxitself is working."Command not found" (
ai-cli): If installed globally, ensure your npm global bin directory is inPATH. If usingnpx, usenpx -y --package ai-cli-mcp@latest ai-cli ...."Command not found" (claude or ~/.claude/local/claude): Ensure the Claude CLI is installed correctly. Run
claude/doctoror check its documentation.Permissions Issues: Make sure you've run the "Important First-Time Setup" step.
JSON Errors from Server: If
MCP_CLAUDE_DEBUGistrue, error messages or logs might interfere with MCP's JSON parsing. Set tofalsefor normal operation.ESM/Import Errors: Ensure you are using Node.js v20 or later.
Contributing
For development setup, testing, and contribution guidelines, see the Development Guide.
Testing
# Deterministic unit, parser, contract, and mocked e2e tests
npm test
# Published npm package contents smoke test
npm run test:package
# Deterministic PR/release gate used by GitHub Actions.
# This does not enable real external CLI runs by itself.
npm run test:release
# Release-time live E2E against real installed AI CLIs
ACM_LIVE_E2E=1 ACM_LIVE_E2E_AGENTS=claude,codex npm run test:live
# Release-time live E2E for both ai-cli and MCP server surfaces
ACM_LIVE_E2E=1 ACM_LIVE_E2E_SURFACE=all ACM_LIVE_E2E_AGENTS=claude,codex npm run test:liveLive E2E is opt-in because it depends on installed and authenticated external CLIs, network access, provider availability, and cost budget. ACM_LIVE_E2E_SURFACE defaults to cli; use mcp or all to include the MCP server surface.
Advanced Configuration (Optional)
Normally not required, but useful for customizing CLI paths or debugging.
CLAUDE_CLI_NAME: Override the Claude CLI binary name or provide an absolute path (default:claude)CODEX_CLI_NAME: Override the Codex CLI binary name or provide an absolute path (default:codex)ANTIGRAVITY_CLI_NAME: Override the Antigravity binary name or absolute path (default:agy). The deprecatedGEMINI_CLI_NAMEis a lower-priority override and must also point to an Antigravity binary.ANTIGRAVITY_PRINT_TIMEOUT: Override Antigravity’s run limit with a positive duration such as1h(integration default:2h;0is not unlimited).GROK_CLI_NAME: Override the Grok CLI binary name or absolute path (default discovery:~/.grok/bin/grok, thengrokon PATH)OPENCODE_CLI_NAME: Override the OpenCode CLI binary name or provide an absolute path (default:opencode)PI_CLI_NAME: Override the Pi CLI binary name or provide an absolute path (default:pi)MCP_CLAUDE_DEBUG: Enable debug logging (set totruefor verbose output)
CLI Name Specification:
Command name only:
CLAUDE_CLI_NAME=claude-customAbsolute path:
CLAUDE_CLI_NAME=/path/to/custom/claudeRelative paths are not supported.
Example with custom CLI binaries:
"ai-cli-mcp": {
"command": "npx",
"args": [
"-y",
"ai-cli-mcp@latest"
],
"env": {
"CLAUDE_CLI_NAME": "claude-custom",
"CODEX_CLI_NAME": "codex-custom",
"OPENCODE_CLI_NAME": "opencode-custom",
"PI_CLI_NAME": "pi-custom"
}
},License
MIT
Available Tools
9 toolscleanup_processesA
Remove all completed and failed processes from the process list to free up memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the action (removing completed/failed processes) and the benefit (free memory). It does not mention edge cases like empty list or return value, but for a simple zero-parameter tool, it is sufficiently transparent.
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 sentence front-loads the purpose and outcome. No wasted words, highly efficient.
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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is adequate. It covers what it does and why. Could mention that it does not affect running processes, but not critical.
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?
There are zero parameters, so baseline is 4. The description adds no parameter info because none exist. Schema coverage is 100%.
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 clearly states the tool removes all completed and failed processes to free memory. It uses specific verbs and resource, and distinguishes from siblings like kill_process (which targets running processes) and list_processes (which lists 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 implies usage for memory cleanup but does not explicitly tell when to use this tool versus alternatives (e.g., kill_process for running processes). No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
doctorA
Check supported AI CLI binary availability and path resolution, including Grok (GROK_CLI_NAME override) and Pi (PI_CLI_NAME override). Does not verify login state or terms acceptance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 behavior. It does reveal a key limitation (does not verify login state or terms acceptance) and implies a non-mutating check. However, it omits any mention of return format, potential errors, or side effects. It gives some transparency but not comprehensive coverage for an unannotated tool.
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 with zero waste. The primary purpose is front-loaded, and the caveat about login state is placed second. Every word earns its place, and there is no redundant phrasing. The description is efficient and well-structured.
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 tool with no parameters and no output schema, the description is fairly complete. It states what it checks, names the relevant overrides, and explicitly says what it does not verify. The main gap is the lack of any indication of the return format or what a successful check looks like. Since there is no output schema, a brief note on the output type would have made it more complete, but the current description still covers the essential behavior.
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?
The tool has zero parameters, so the schema already provides complete coverage (vacuously). The description does not need to explain parameters. The baseline for 0 params is 4, and the description does not add any parameter-specific information, which is appropriate. There is nothing missing in this dimension.
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 clearly states a specific action ('Check supported AI CLI binary availability and path resolution'), names the specific binaries (Grok and Pi) and the environment variable overrides. It also explicitly states what it does not do (verify login state or terms acceptance), which distinguishes it from any related tools. This is a precise, unambiguous purpose that differentiates it from the process and model sibling tools.
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 gives no explicit guidance on when to use this tool versus alternatives. It implies a diagnostic purpose but never names a sibling or a condition that would select this tool over another. The negative statement ('Does not verify login state') hints at a limitation but does not say 'use X when you need login verification'. Without any when/when-not guidance, the agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resultA
Get the current output and status of an AI agent process by PID. Defaults to a compact result shape; set verbose to true for full metadata and detailed parsed output.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID returned by run tool. | |
| verbose | No | Optional: If true, returns the full result shape including metadata fields and detailed parsed output such as tool usage history. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description accurately states it retrieves data, implying a read-only operation. However, it lacks explicit details on side effects, resource usage, or error conditions, which would be beneficial.
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 extremely concise, using two sentences to convey all necessary information without any redundant or irrelevant content.
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?
The description covers the core functionality and result shapes adequately. While it could hint at the output structure, the tool's simplicity and the presence of sibling tools make this sufficient.
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?
With 100% schema coverage, the description adds value by explaining the behavior of the verbose parameter, going beyond the schema's static definitions.
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 clearly states the tool retrieves output and status of an AI agent process by PID, specifying the action and resource. It effectively distinguishes itself from sibling tools like kill_process or run.
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 provides guidance on the verbose parameter (compact vs. full output) but does not explicitly differentiate when to use this tool versus alternatives like peek or wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kill_processC
Terminate a running AI agent process by PID.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID to terminate. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects, required permissions, or what happens to process resources upon termination. For a destructive action, this is insufficient.
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?
Single sentence, no wasted words. However, the brevity sacrifices valuable context for the tool's use.
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 straightforward kill command with one parameter, the description is adequate but does not cover behavioral aspects or differentiate from siblings.
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 100% with 'pid' described. The description adds no additional meaning beyond what the schema provides, which is acceptable given the simple parameter.
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 clearly states 'Terminate a running AI agent process by PID' with a specific verb and resource. However, it does not differentiate from sibling tool 'cleanup_processes', which may also terminate processes.
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?
No guidance on when to use this tool versus alternatives like 'cleanup_processes'. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_processesA
List all running and completed AI agent processes. Returns a simple list with PID, agent type, and status for each process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns a simple list with PID, agent type, and status for each process, but does not disclose behavioral traits such as performance characteristics, rate limits, or whether it blocks. Since no annotations are provided, the description carries the full burden, but it only minimally covers behavior.
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?
One sentence, front-loaded with the core action, and no unnecessary words. Straightforward and efficient.
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 simple list operation with no parameters and no output schema, the description adequately covers the return format and scope. However, it could mention that no detailed process information is provided (e.g., no resource usage) or that it is read-only, but overall it is sufficient.
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?
The tool has no parameters, so schema coverage is 100% by definition. The description naturally adds no parameter information, but the baseline for zero parameters is 4.
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 clearly states the tool lists all running and completed AI agent processes, specifying the resource (processes) and action (list). It distinguishes from sibling tools like cleanup_processes, kill_process, etc., by focusing on listing rather than modifying or inspecting.
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?
No guidance on when to use this tool versus alternatives (e.g., when to use 'peek' or 'get_result'). There is no mention of prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modelsA
List supported model names, aliases, and reasoning effort levels. Queries Pi and OpenCode for current models and returns names ready for run. Discovery uses a 5-second timeout per CLI and a 60-second process-local cache; failures are reported per backend without hiding other models. Lists reflect the server working directory and CLI configuration, not a guarantee of model access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is a major strength. The description discloses two key behaviors: the 5-second timeout per CLI and 60-second cache, and that failures are reported per backend without hiding other models. It also notes the lists reflect server working directory and CLI configuration, not a guarantee of access. With no annotations provided, this description carries the full burden and does so thoroughly.
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 concise, front-loaded with the core purpose, and each sentence provides distinct information. It could be slightly more structured (e.g., splitting behavioral details), but it's efficient and readable.
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?
Given zero parameters, no output schema, and no annotations, the description covers the essential aspects: what it returns, the discovery process, failure handling, and the caveat about access. It might benefit from noting that no arguments are required, but that's evident from the schema. It's complete enough for an agent to call it correctly.
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?
The tool has zero parameters, and the schema coverage is 100% (it's just an empty object). The description doesn't need to explain parameters, but it adds value by clarifying that the tool returns names ready for run and mentions the discovery process. Baseline 4 is appropriate for a zero-parameter tool.
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 clearly states the tool lists supported model names, aliases, and reasoning effort levels, and that it queries Pi and OpenCode. It distinguishes itself from siblings by mentioning 'ready for run' and its discovery mechanism, making its purpose specific and actionable.
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 implies when to use it (e.g., before running commands that require models) and mentions it returns names ready for run. It doesn't explicitly exclude alternatives, but given zero parameters and its discovery nature, the context is clear enough. However, it doesn't explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
peekA
One-shot short observation window for running child agents. Returns only natural-language message events, and optionally normalized tool_call events, observed during this call; not a history API, not gapless streaming, and not stdout/stderr tailing. Message extraction is supported for Codex, Claude, Grok (whole assistant messages), OpenCode, Gemini, and Pi text deltas. Tool calls exclude raw tool output.
| Name | Required | Description | Default |
|---|---|---|---|
| pids | Yes | Process IDs returned by run. Duplicates are deduplicated server-side, preserving first occurrence order. Unknown PIDs are returned per process as not_found. | |
| peek_time_sec | No | Optional positive integer observation window in seconds. Defaults to 10; maximum is 60. | |
| include_tool_calls | No | Optional: include normalized tool_call events without raw tool output. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behaviors: it is a one-shot snapshot, does not return raw tool output, and has specific message extraction support for certain models. It also notes that tool calls are normalized and exclude raw output, which is a useful behavioral detail.
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 concise and front-loaded with the purpose, then quickly lists exclusions and supported model details. Every sentence earns its place, though one minor redundancy exists with 'not gapless streaming' and 'not a history API' being similar concepts, but it's acceptable.
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?
Given no output schema or annotations, the description does a thorough job of setting expectations: it clarifies what it returns, what it excludes, and its limitations. For a relatively simple observation window tool, this is complete for an agent to call it correctly.
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 100%, so parameters are well-documented in the schema. However, the description adds meaningful context beyond the schema: it clarifies that tool_calls are normalized and exclude raw output, and that message extraction is supported for specific models, which helps the agent understand the semantics of include_tool_calls and pids.
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 clearly states the tool's purpose: a one-shot short observation window for running child agents, returning natural-language message events and optionally normalized tool_call events. It distinguishes itself from a history API, gapless streaming, and stdout/stderr tailing, clearly separating it from sibling tools like wait and get_result.
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?
Explicitly states what it is not (not a history API, not gapless streaming, not stdout/stderr tailing) and what it returns (only message events, optionally tool calls) in contrast to siblings like get_result or wait. It also gives context on when to use it: for a quick observation window rather than continuous monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
runA
AI Agent Runner: Starts a Claude, Codex, Antigravity (Gemini), OpenCode, Grok, or Pi CLI process in the background and returns a PID immediately. Use list_processes and get_result to monitor progress.
• File ops: Create, read, (fuzzy) edit, move, copy, delete, list files, analyze/ocr images, file content analysis • Code: Generate / analyse / refactor / fix • Git: Stage ▸ commit ▸ push ▸ tag (any workflow) • Terminal: Run any CLI cmd or open URLs • Web search + summarise content on-the-fly • Multi-step workflows & GitHub integration
IMPORTANT: This tool now returns immediately with a PID. Use other tools to check status and get results.
Supported models: "claude-ultra", "codex-ultra", "gemini-ultra", "sol", "luna", "sonnet", "sonnet[1m]", "opus", "opusplan", "fable", "haiku", "gpt-6-astra", "gpt-6-sol", "gpt-6-luna", "gpt-5.4", "gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna", "gpt-5.5", "gpt-5.4-mini", "gpt-5.3-codex", "gpt-5.3-codex-spark", "gpt-5.2", "gemini-3.8-flash-high", "gemini-3.8-flash-medium", "gemini-3.8-flash-low", "gemini-3.7-flash-high", "gemini-3.7-flash-medium", "gemini-3.7-flash-low", "gemini-3.6-flash-high", "gemini-3.6-flash-medium", "gemini-3.6-flash-low", "gemini-3.1-pro-high", "gemini-3.1-pro-low", "grok", "grok-4.6", "grok-4.5", "opencode", "pi", "oc-<provider/model>", "pi-<provider/model>"
Prompt input: You must provide EITHER prompt (string) OR prompt_file (file path), but not both.
Prompt tips
Be concise, explicit & step-by-step for complex tasks.
Check process status with list_processes
Get results with get_result using the returned PID
Kill long-running processes with kill_process if needed
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | The model to use. Aliases (including user config): "claude-ultra" (opus; auto max reasoning), "codex-ultra" (gpt-6-astra; auto ultra reasoning), "gemini-ultra" (gemini-3.8-flash-high), "sol" (gpt-6-sol), "luna" (gpt-6-luna). An explicit reasoning_effort overrides the alias default. Standard: "sonnet", "sonnet[1m]", "opus", "opusplan", "fable", "haiku", "gpt-6-astra", "gpt-6-sol", "gpt-6-luna", "gpt-5.4", "gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna", "gpt-5.5", "gpt-5.4-mini", "gpt-5.3-codex", "gpt-5.3-codex-spark", "gpt-5.2", "gemini-3.8-flash-high", "gemini-3.8-flash-medium", "gemini-3.8-flash-low", "gemini-3.7-flash-high", "gemini-3.7-flash-medium", "gemini-3.7-flash-low", "gemini-3.6-flash-high", "gemini-3.6-flash-medium", "gemini-3.6-flash-low", "gemini-3.1-pro-high", "gemini-3.1-pro-low", "grok", "grok-4.6", "grok-4.5", "opencode", "pi". Gemini models run through Antigravity CLI (agy); use agy models for current availability. Model effort suffixes must match reasoning_effort when supplied. Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode accepts explicit dynamic models using "oc-<provider/model>". Pi accepts its configured default with "pi" or an explicit dynamic model using "pi-<provider/model>"; discover current choices with "pi --list-models". | |
| prompt | No | The detailed natural language prompt for the agent to execute. Either this or prompt_file is required. | |
| session_id | No | Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, OpenCode, Grok, and Pi. Antigravity resumes its conversation_id via --conversation; old Gemini CLI sessions cannot be resumed. Grok resumes via --resume, preserving the session ID. OpenCode and Pi resume in place via --session and may also be combined with explicit model selection. | |
| workFolder | Yes | The working directory for the agent execution. Must be an absolute path. | |
| prompt_file | No | Path to a file containing the prompt. Either this or prompt is required. Must be an absolute path or relative to workFolder. | |
| reasoning_effort | No | Reasoning control for Claude, Codex, Antigravity (Gemini), Grok, and Pi. Claude uses --effort with "low", "medium", "high", "xhigh", "max". Codex uses model_reasoning_effort with "low", "medium", "high", "xhigh"; GPT-6 Astra/Sol and GPT-5.6 Sol/Terra also support "max" and "ultra", while GPT-6 Luna and GPT-5.6 Luna support "max". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Pi uses --thinking with off/minimal/low/medium/high/xhigh/max. Omitted effort uses the CLI default. Antigravity uses --effort low/medium/high; it must match any effort suffix in the model name. OpenCode does not support reasoning_effort in this integration. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key async trait ('returns immediately with a PID', 'runs in the background'), instructs the agent to use other tools for status/results, and mentions killing long-running processes. It doesn't warn about side effects of arbitrary terminal commands or process lifetime limits, but these are minor for an agent-runner.
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 purpose, capabilities, and tips are front-loaded and well-structured. However, the 'Supported models' section repeats what the model parameter schema already documents in detail, adding a large block of redundancy. The capability bullet list is useful but generic, so not every sentence earns its place.
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 complex async runner with six parameters and no output schema, the definition is largely complete: it explains background execution, immediate PID return, the monitoring workflow, prompt constraints, and actionable tips. It omits details like process cleanup policy or error reporting, but the sibling tools (get_result, kill_process, list_processes) are referenced to cover those workflows.
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 100% with detailed descriptions for all six parameters, so the baseline is 3. The description adds the prompt/prompt_file exclusivity rule and general prompt tips, but the long supported-models list largely duplicates the schema's model parameter description. Added semantic value beyond the schema is minimal.
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 opens with a specific verb and resource: 'Starts a Claude, Codex, Antigravity (Gemini), OpenCode, Grok, or Pi CLI process in the background and returns a PID immediately.' It also differentiates from siblings by directing to list_processes and get_result for monitoring, and it lists concrete capability domains (file ops, code, git, terminal, web).
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 explicit workflow guidance: monitor progress with list_processes, retrieve results with get_result, and kill with kill_process; these are also restated in numbered prompt tips. It clearly states the prompt OR prompt_file constraint. However, it doesn't explicitly state when not to use this tool or name an alternative runner, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waitB
Wait for multiple AI agent processes to complete and return their results. Defaults to compact result items; set verbose to true for full metadata and detailed parsed output.
| Name | Required | Description | Default |
|---|---|---|---|
| pids | Yes | List of process IDs to wait for (returned by the run tool). | |
| timeout | No | Optional: Maximum time to wait in seconds. Defaults to 180 (3 minutes). Set to 0 to wait without a timeout. | |
| verbose | No | Optional: If true, each result item uses the full result shape including metadata fields and detailed parsed output. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It does convey that waiting is blocking until completion and that results are compact by default, with verbose enabling full metadata and parsed output. However, it omits behavior on timeout expiration, partial failures, and invalid or already-cleaned-up pids.
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 focused sentences front-load the core behavior and then explain the verbose option. There is no redundant phrasing, and the structure is easy for an agent to parse quickly.
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?
The tool is simple and the schema covers all parameters well, but there is no output schema and no annotations. The description would benefit from noting timeout behavior, failure handling, and how wait relates to get_result or peek, making it adequate but not fully complete.
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 100%, so the baseline is 3. The description adds useful context about the verbose parameter and default compact results, but it does not materially expand on timeout semantics beyond what the schema already states.
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 states a specific action ('wait'), a clear resource ('multiple AI agent processes'), and the outcome ('complete and return their results'). This distinguishes it from run/kill/list siblings, though it does not explicitly name the sibling it differs from, so it misses 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?
No guidance is provided about when to use wait versus get_result, peek, or list_processes. The schema mentions that pids come from the run tool, but the description itself gives no explicit context for choosing this tool over alternatives.
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 tool update
v3.0.0- Changed
run3 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.8-flash-high). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-3.8-flash-high\", \"gemini-3.8-flash-medium\", \"gemini-3.8-flash-low\", \"gemini-3.7-flash-high\", \"gemini-3.7-flash-medium\", \"gemini-3.7-flash-low\", \"gemini-3.6-flash-high\", \"gemini-3.6-flash-medium\", \"gemini-3.6-flash-low\", \"gemini-3.1-pro-high\", \"gemini-3.1-pro-low\", \"forge\", \"grok\", \"grok-4.6\", \"grok-4.5\", \"opencode\". Gemini models run through Antigravity CLI (agy); use agy models for current availability. Model effort suffixes must match reasoning_effort when supplied. Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.8-flash-high), \"sol\" (gpt-6-sol), \"luna\" (gpt-6-luna). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-6-sol\", \"gpt-6-luna\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-3.8-flash-high\", \"gemini-3.8-flash-medium\", \"gemini-3.8-flash-low\", \"gemini-3.7-flash-high\", \"gemini-3.7-flash-medium\", \"gemini-3.7-flash-low\", \"gemini-3.6-flash-high\", \"gemini-3.6-flash-medium\", \"gemini-3.6-flash-low\", \"gemini-3.1-pro-high\", \"gemini-3.1-pro-low\", \"grok\", \"grok-4.6\", \"grok-4.5\", \"opencode\", \"pi\". Gemini models run through Antigravity CLI (agy); use agy models for current availability. Model effort suffixes must match reasoning_effort when supplied. Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode accepts explicit dynamic models using \"oc-<provider/model>\". Pi accepts its configured default with \"pi\" or an explicit dynamic model using \"pi-<provider/model>\"; discover current choices with \"pi --list-models\"." - changed
Input schema / properties / reasoning_effort / descriptionPrevious value: -"Reasoning control for Claude, Codex, Antigravity (Gemini), and Grok. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Omitted effort uses the CLI default. Grok never accepts max/ultra. Antigravity uses --effort low/medium/high; it must match any effort suffix in the model name. Forge and OpenCode do not support reasoning_effort in this integration."New value: +"Reasoning control for Claude, Codex, Antigravity (Gemini), Grok, and Pi. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra/Sol and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-6 Luna and GPT-5.6 Luna support \"max\". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Pi uses --thinking with off/minimal/low/medium/high/xhigh/max. Omitted effort uses the CLI default. Antigravity uses --effort low/medium/high; it must match any effort suffix in the model name. OpenCode does not support reasoning_effort in this integration." - changed
Input schema / properties / session_id / descriptionPrevious value: -"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, Forge, OpenCode, and Grok. Antigravity resumes its conversation_id via --conversation; old Gemini CLI sessions cannot be resumed. Grok resumes via --resume, preserving the session ID. OpenCode resumes in-place via --session and may also be combined with explicit oc-<provider/model> selection."New value: +"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, OpenCode, Grok, and Pi. Antigravity resumes its conversation_id via --conversation; old Gemini CLI sessions cannot be resumed. Grok resumes via --resume, preserving the session ID. OpenCode and Pi resume in place via --session and may also be combined with explicit model selection."
1 tool update
v2.27.0- Changed
run3 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.1-pro-preview). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"grok\", \"grok-4.6\", \"grok-4.5\", \"opencode\". Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.8-flash-high). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-3.8-flash-high\", \"gemini-3.8-flash-medium\", \"gemini-3.8-flash-low\", \"gemini-3.7-flash-high\", \"gemini-3.7-flash-medium\", \"gemini-3.7-flash-low\", \"gemini-3.6-flash-high\", \"gemini-3.6-flash-medium\", \"gemini-3.6-flash-low\", \"gemini-3.1-pro-high\", \"gemini-3.1-pro-low\", \"forge\", \"grok\", \"grok-4.6\", \"grok-4.5\", \"opencode\". Gemini models run through Antigravity CLI (agy); use agy models for current availability. Model effort suffixes must match reasoning_effort when supplied. Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector." - changed
Input schema / properties / reasoning_effort / descriptionPrevious value: -"Reasoning control for Claude, Codex, and Grok. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Omitted effort uses the CLI default. Grok never accepts max/ultra. Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."New value: +"Reasoning control for Claude, Codex, Antigravity (Gemini), and Grok. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Omitted effort uses the CLI default. Grok never accepts max/ultra. Antigravity uses --effort low/medium/high; it must match any effort suffix in the model name. Forge and OpenCode do not support reasoning_effort in this integration." - changed
Input schema / properties / session_id / descriptionPrevious value: -"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, Forge, OpenCode, and Grok. Grok resumes via --resume, preserving the session ID. OpenCode resumes in-place via --session and may also be combined with explicit oc-<provider/model> selection."New value: +"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, Forge, OpenCode, and Grok. Antigravity resumes its conversation_id via --conversation; old Gemini CLI sessions cannot be resumed. Grok resumes via --resume, preserving the session ID. OpenCode resumes in-place via --session and may also be combined with explicit oc-<provider/model> selection."
2 tool updates
v2.26.0- Changed
run3 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.1-pro-preview). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.1-pro-preview). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"grok\", \"grok-4.6\", \"grok-4.5\", \"opencode\". Fable may require usage credits. Grok accepts native grok-* model names; grok uses its CLI-configured default unless a user alias named grok exists; that alias retains precedence. Native model names such as grok-4.6 select the Grok backend. Omitted effort uses the CLI default; grok and unknown Grok models accept low/medium/high, grok-4.6 also accepts xhigh. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector." - changed
Input schema / properties / reasoning_effort / descriptionPrevious value: -"Reasoning control for Claude and Codex. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."New value: +"Reasoning control for Claude, Codex, and Grok. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Grok: grok-4.6=low/medium/high/xhigh; grok-4.5, grok (configured default), and other grok-* models=low/medium/high. Omitted effort uses the CLI default. Grok never accepts max/ultra. Gemini, Forge, and OpenCode do not support reasoning_effort in this integration." - changed
Input schema / properties / session_id / descriptionPrevious value: -"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, Forge, and OpenCode. OpenCode resumes in-place via --session and may also be combined with explicit oc-<provider/model> selection."New value: +"Optional session ID to resume a previous session. Supported for Claude, Codex, Gemini, Forge, OpenCode, and Grok. Grok resumes via --resume, preserving the session ID. OpenCode resumes in-place via --session and may also be combined with explicit oc-<provider/model> selection."
- Changed
wait2 fields changed- changed
Input schema / properties / timeout / descriptionPrevious value: -"Optional: Maximum time to wait in seconds. Defaults to 180 (3 minutes)."New value: +"Optional: Maximum time to wait in seconds. Defaults to 180 (3 minutes). Set to 0 to wait without a timeout." - added
Input schema / properties / timeout / minimumAdded value: +0
1 tool update
v2.24.0- Changed
run1 field changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases: \"claude-ultra\" (Opus with auto max effort; does not select Fable), \"codex-ultra\" (auto ultra reasoning), \"gemini-ultra\". Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable is an explicit selection and may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases (including user config): \"claude-ultra\" (opus; auto max reasoning), \"codex-ultra\" (gpt-6-astra; auto ultra reasoning), \"gemini-ultra\" (gemini-3.1-pro-preview). An explicit reasoning_effort overrides the alias default. Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."
1 tool update
v2.23.0- Changed
run2 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases: \"claude-ultra\" (Opus with auto max effort; does not select Fable), \"codex-ultra\" (auto ultra reasoning), \"gemini-ultra\". Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable is an explicit selection and may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases: \"claude-ultra\" (Opus with auto max effort; does not select Fable), \"codex-ultra\" (auto ultra reasoning), \"gemini-ultra\". Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-6-astra\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable is an explicit selection and may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector." - changed
Input schema / properties / reasoning_effort / descriptionPrevious value: -"Reasoning control for Claude and Codex. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-5.6 Sol and Terra also support \"max\" and \"ultra\", while Luna supports \"max\". Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."New value: +"Reasoning control for Claude and Codex. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-6 Astra and GPT-5.6 Sol/Terra also support \"max\" and \"ultra\", while GPT-5.6 Luna supports \"max\". Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."
1 tool update
v2.22.0- Changed
run2 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"The model to use. Aliases: \"claude-ultra\" (auto max effort), \"codex-ultra\" (auto xhigh reasoning), \"gemini-ultra\". Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"haiku\", \"gpt-5.4\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector."New value: +"The model to use. Aliases: \"claude-ultra\" (Opus with auto max effort; does not select Fable), \"codex-ultra\" (auto ultra reasoning), \"gemini-ultra\". Standard: \"sonnet\", \"sonnet[1m]\", \"opus\", \"opusplan\", \"fable\", \"haiku\", \"gpt-5.4\", \"gpt-5.6-sol\", \"gpt-5.6-terra\", \"gpt-5.6-luna\", \"gpt-5.5\", \"gpt-5.4-mini\", \"gpt-5.3-codex\", \"gpt-5.3-codex-spark\", \"gpt-5.2\", \"gemini-2.5-pro\", \"gemini-2.5-flash\", \"gemini-3.1-pro-preview\", \"gemini-3-pro-preview\", \"gemini-3-flash-preview\", \"forge\", \"opencode\". Fable is an explicit selection and may require usage credits. OpenCode also accepts explicit dynamic models using \"oc-<provider/model>\". \"forge\" is a provider key, not a Forge model family selector." - changed
Input schema / properties / reasoning_effort / descriptionPrevious value: -"Reasoning control for Claude and Codex. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\". Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."New value: +"Reasoning control for Claude and Codex. Claude uses --effort with \"low\", \"medium\", \"high\", \"xhigh\", \"max\". Codex uses model_reasoning_effort with \"low\", \"medium\", \"high\", \"xhigh\"; GPT-5.6 Sol and Terra also support \"max\" and \"ultra\", while Luna supports \"max\". Gemini, Forge, and OpenCode do not support reasoning_effort in this integration."
9 tool updates
v2.21.0- First observed
cleanup_processes - First observed
doctor - First observed
get_result - First observed
kill_process - First observed
list_processes - First observed
models - First observed
peek - First observed
run - First observed
wait
TDQS
Scored across 9 tools
Each tool has a clearly distinct purpose: run starts processes, list/get_result/wait monitor them, kill/cleanup manage them, peek provides live observation, doctor checks CLI availability, and models lists supported models. No two tools overlap in function.
Naming is mixed: some tools follow verb_noun (cleanup_processes, list_processes, get_result, kill_process) while others are bare verbs (run, wait, peek) or nouns (doctor, models). The pattern is not uniform but still readable and intuitive.
With 9 tools, the server is well-scoped for AI CLI process management and model discovery. Each tool covers a necessary aspect of the workflow without redundancy or bloat.
The tool surface covers the full lifecycle: creating processes (run), monitoring (list, get_result, wait, peek), terminating (kill, cleanup), and supporting infrastructure (doctor, models). No obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceOrchestrates multiple AI models (Gemini, OpenAI, Claude, local models) within a single conversation context, enabling collaborative workflows like multi-model code reviews, consensus building, and CLI-to-CLI bridging for specialized tasks.-
- AlicenseBqualityFmaintenanceEnables orchestrating multiple AI CLI agents (Claude Code, Codex, Gemini CLI, Copilot CLI) through a unified MCP interface for task delegation, cross-agent comparison, and specialized tools like code review and debugging.143 npm14MIT
- AlicenseAqualityAmaintenanceEnables one AI coding agent to delegate tasks to, and build consensus across, multiple other coding CLIs (Claude Code, Codex, etc.) by orchestrating them as headless subprocesses.1833 PyPI6MIT
- AlicenseDqualityCmaintenanceEnables Claude Code as a team leader to delegate tasks to GPT and Gemini experts, supporting multi-LLM collaboration with tools for consultation, code review, design, and background execution.768 npmMIT