Skip to main content
Glama

AI CLI MCP Server

npm package View changelog

🇯🇵 日本語のREADMEはこちら

📦 Package Migration Notice: This package was formerly @mkxultra/claude-code-mcp and has been renamed to ai-cli-mcp to 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

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 disabled

  • Execute 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 (opencode plus oc-<provider/model>), and Pi (pi plus pi-<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:

  1. Refactor src/backend code using sonnet

  2. Create unit tests for src/frontend using gpt-5.3-codex

  3. Update docs in docs/ using gemini-3.1-pro-high

While they run, please update the TODO list. Once done, use the wait tool 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.

  1. First, use acm mcp run with opus to read all files in src/ and understand the project structure.

  2. Use the wait tool to wait for completion and retrieve the session_id from the result.

  3. Using that session_id, run the following two tasks in parallel with acm mcp run:

    • Create refactoring proposals for src/utils using sonnet

    • Add architecture documentation to README.md using gpt-5.3-codex

  4. Finally, wait again to combine both results.

Session Resume Demo

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 doctor passes, and execution with --dangerously-skip-permissions is 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 agy and 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, then PATH; GROK_CLI_NAME overrides 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 the oc-<provider/model> wrapper syntax exposed by ai-cli models.

  • Pi (Optional): Install and authenticate Pi locally (tested with 0.86.1). Run pi --list-models to see the provider/model pairs available to your account. PI_CLI_NAME overrides 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 entrypoint

  • ai-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-mcp

This exposes both commands:

  • ai-cli

  • ai-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-mcp

Human 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-permissions

Follow 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 login

For Antigravity CLI (Gemini):

Start Antigravity once interactively to sign in:

agy

macOS 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:

  • run

  • ps

  • result

  • peek

  • wait

  • kill

  • cleanup

  • doctor

  • models

  • alias list / alias add / alias rm

  • mcp

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 cleanup

run accepts --cwd as the primary working-directory flag and also accepts the older aliases --workFolder / --work-folder for compatibility.

OpenCode model selection accepts either:

  • opencode for the CLI's configured default model

  • oc-<provider/model> for an explicit OpenCode provider/model, for example oc-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-models

Use 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-coding

alias 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-ultra

Use 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"
    }
  }
}
  • model is required; reasoning_effort is 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; omitting reasoning_effort uses 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, or oc-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 the oc- prefix are reserved, except that a user alias named grok retains 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 add can 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.json

  • stdout.log

  • stderr.log

  • exit-status.json for 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. Either prompt or prompt_file is required.

  • prompt_file (string, optional): Path to a file containing the prompt. Either prompt or prompt_file is required. Can be absolute path or relative to workFolder.

  • 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-ultra

  • Claude: sonnet, sonnet[1m], opus, opusplan, fable, haiku

    • fable explicitly selects Claude Code's latest Fable model. Fable may require separately billed usage credits and is not selected by the built-in claude-ultra default.

  • 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, 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-low

  • Grok: grok for its configured default, grok-4.6, grok-4.5, and other native grok-* names

  • OpenCode: opencode for the configured default backend model, plus explicit wrappers like oc-openai/gpt-5.4

  • Pi: pi for its configured default model, plus explicit wrappers like pi-openai-codex/gpt-6-astra

  • reasoning_effort (string, optional): Reasoning control for Claude, Codex, Grok, and Pi. Pi maps off|minimal|low|medium|high|xhigh|max to --thinking. Grok uses --reasoning-effort: grok-4.6 supports low/medium/high/xhigh; grok-4.5, the grok configured 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 uses model_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 support reasoning_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 --session and 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 the run tool).

  • timeout (number, optional): Non-negative maximum wait time in seconds. Defaults to 180 (3 minutes); 0 disables the wait timeout.

  • verbose (boolean, optional): If true, each result item uses the full result shape. Defaults to false.

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

Arguments:

  • pids (array of numbers, required): 1..32 process IDs returned by run. Duplicate PIDs are deduplicated server-side, preserving first occurrence order. Unknown or unmanaged PIDs are returned per process as not_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): When true, each process events array includes normalized tool_call events in addition to message events. Defaults to false.

Observation and filtering:

  • peek_started_at and events[].ts are ai-cli-mcp server-side UTC RFC3339 timestamps. peek_started_at is when the observation window starts after validation and listener registration; events[].ts is when ai-cli-mcp observed and accepted the event.

  • The window ends when peek_time_sec elapses or all target processes reach a terminal state, whichever comes first.

  • Events emitted before the window starts are not returned. Concurrent peek calls for the same PID are allowed; each has an independent window and may return overlapping events.

  • Message events are recognized from Codex agent_message text, Claude and Grok whole assistant text content, OpenCode type: "text" events where part.type is "text", Antigravity step_update events, and Pi text_delta events.

  • When tool calls are included, tool_call events 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, and error: null.

  • Each PID keeps the first 50 events observed in the window. If later events are dropped, truncated is true.

  • status is one of running, completed, failed, or not_found, and reflects state when the observation window closes.

  • agent is claude, codex, gemini, opencode, grok, pi, a future tracked string value, or null when 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 the run tool.

  • verbose (boolean, optional): If true, returns the full result shape. Defaults to false.

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, ensure npx itself is working.

  • "Command not found" (ai-cli): If installed globally, ensure your npm global bin directory is in PATH. If using npx, use npx -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/doctor or check its documentation.

  • Permissions Issues: Make sure you've run the "Important First-Time Setup" step.

  • JSON Errors from Server: If MCP_CLAUDE_DEBUG is true, error messages or logs might interfere with MCP's JSON parsing. Set to false for 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:live

Live 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 deprecated GEMINI_CLI_NAME is 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 as 1h (integration default: 2h; 0 is not unlimited).

  • GROK_CLI_NAME: Override the Grok CLI binary name or absolute path (default discovery: ~/.grok/bin/grok, then grok on 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 to true for verbose output)

CLI Name Specification:

  • Command name only: CLAUDE_CLI_NAME=claude-custom

  • Absolute path: CLAUDE_CLI_NAME=/path/to/custom/claude Relative 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 tools
cleanup_processesA

Remove all completed and failed processes from the process list to free up memory.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pidYesThe process ID returned by run tool.
verboseNoOptional: If true, returns the full result shape including metadata fields and detailed parsed output such as tool usage history. Defaults to false.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pidYesThe process ID to terminate.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pidsYesProcess IDs returned by run. Duplicates are deduplicated server-side, preserving first occurrence order. Unknown PIDs are returned per process as not_found.
peek_time_secNoOptional positive integer observation window in seconds. Defaults to 10; maximum is 60.
include_tool_callsNoOptional: include normalized tool_call events without raw tool output. Defaults to false.

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

  1. Be concise, explicit & step-by-step for complex tasks.

  2. Check process status with list_processes

  3. Get results with get_result using the returned PID

  4. Kill long-running processes with kill_process if needed

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoThe 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".
promptNoThe detailed natural language prompt for the agent to execute. Either this or prompt_file is required.
session_idNoOptional 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.
workFolderYesThe working directory for the agent execution. Must be an absolute path.
prompt_fileNoPath to a file containing the prompt. Either this or prompt is required. Must be an absolute path or relative to workFolder.
reasoning_effortNoReasoning 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

A4/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pidsYesList of process IDs to wait for (returned by the run tool).
timeoutNoOptional: Maximum time to wait in seconds. Defaults to 180 (3 minutes). Set to 0 to wait without a timeout.
verboseNoOptional: If true, each result item uses the full result shape including metadata fields and detailed parsed output. Defaults to false.

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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. 1 tool updatev3.0.0
    • Changedrun3 fields changed
      • changedInput schema / properties / model / description
        Previous 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\"."
      • changedInput schema / properties / reasoning_effort / description
        Previous 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."
      • changedInput schema / properties / session_id / description
        Previous 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."
  2. 1 tool updatev2.27.0
    • Changedrun3 fields changed
      • changedInput schema / properties / model / description
        Previous 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."
      • changedInput schema / properties / reasoning_effort / description
        Previous 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."
      • changedInput schema / properties / session_id / description
        Previous 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."
  3. 2 tool updatesv2.26.0
    • Changedrun3 fields changed
      • changedInput schema / properties / model / description
        Previous 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."
      • changedInput schema / properties / reasoning_effort / description
        Previous 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."
      • changedInput schema / properties / session_id / description
        Previous 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."
    • Changedwait2 fields changed
      • changedInput schema / properties / timeout / description
        Previous 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."
      • addedInput schema / properties / timeout / minimum
        Added value: +0
  4. 1 tool updatev2.24.0
    • Changedrun1 field changed
      • changedInput schema / properties / model / description
        Previous 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."
  5. 1 tool updatev2.23.0
    • Changedrun2 fields changed
      • changedInput schema / properties / model / description
        Previous 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."
      • changedInput schema / properties / reasoning_effort / description
        Previous 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."
  6. 1 tool updatev2.22.0
    • Changedrun2 fields changed
      • changedInput schema / properties / model / description
        Previous 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."
      • changedInput schema / properties / reasoning_effort / description
        Previous 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."
  7. 9 tool updatesv2.21.0
    • First observedcleanup_processes
    • First observeddoctor
    • First observedget_result
    • First observedkill_process
    • First observedlist_processes
    • First observedmodels
    • First observedpeek
    • First observedrun
    • First observedwait

TDQS

A3.8/5.0

Scored across 9 tools

Disambiguation5/5

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 Consistency3/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    Orchestrates 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.
    -
  • A
    license
    B
    quality
    F
    maintenance
    Enables 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.
    14
    3 npm
    14
    MIT
  • A
    license
    D
    quality
    C
    maintenance
    Enables 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.
    76
    8 npm
    MIT