Allows delegating autonomous coding tasks and code reviews to Google Antigravity CLI (agy), with support for working directories, models, timeouts, and YOLO mode.
Allows delegating autonomous coding tasks and code reviews to OpenAI Codex CLI, with support for working directories, models, timeouts, and YOLO mode.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AI CLI MCP Server Use Codex to review the uncommitted git diff and suggest fixes."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-ready Model Context Protocol (MCP) server that acts as a secure, unified gateway to both OpenAI Codex CLI and Google Antigravity CLI (agy).
It empowers primary AI orchestrators (such as Claude Desktop, Gemini, Cursor, or Windsurf) to delegate complex coding tasks, file refactorings, and deep automated code reviews to autonomous CLI agents running in YOLO mode with robust process lifecycle supervision.
┌───────────────────────────────────┐
│ Any AI Agent │
│ Claude / Gemini / Cursor / etc. │
└─────────────────┬─────────────────┘
│ MCP Protocol
▼
┌────────────────────────────────────┐
│ Python MCP Server │
│ (ai_cli_mcp_server) │
├────────────────────────────────────┤
│ • codex_run • codex_review │
│ • antigravity_run • antigravity_rvw│
│ • cli_status • get_agent_skills │
└──────────────┬──────────────┬──────┘
│ │
┌───────────┘ └───────────┐
▼ ▼
┌───────────────────────────┐ ┌───────────────────────────┐
│ OpenAI Codex CLI │ │ Google Antigravity CLI │
│ (--dangerously-bypass) │ │ (--dangerously-skip) │
└───────────────────────────┘ └───────────────────────────┘Related MCP server: agent-delegation-mcp
Unified CLI Gateway: Controls both OpenAI Codex and Google Antigravity agents through clean, standard MCP tools.
True Autonomous YOLO Mode:
Automatically applies --dangerously-bypass-approvals-and-sandbox for Codex.
Automatically applies --dangerously-skip-permissions for Antigravity (agy).
Guarantees non-blocking, headless execution without hanging on confirmation dialogs.
Safer by Design: Does not expose arbitrary shell execution (cmd.exe/bash). Only structured, sandboxed tasks are dispatched to vetted agent CLIs.
Process Supervision & Windows Tree-Killing: When a task times out, child processes (compilers, servers, node) are terminated cleanly via process-tree signals.
Built-in Agent Skills: Exposes an embedded, self-contained skills document via tool (get_agent_skills) and MCP resource (skills://usage-guide) so calling agents know how to orchestrate multi-agent workflows.
Multi-Client Support: Out-of-the-box configuration for Claude Desktop, Cursor, Antigravity, Gemini, and VS Code.
Tool | Parameters | Description |
|
| Runs an autonomous coding task with OpenAI Codex CLI. |
|
| Runs an autonomous coding task with Google Antigravity CLI. |
|
| Runs a non-interactive Git diff code review via Codex. |
|
| Runs an automated codebase critique and review via Antigravity. |
| (none) | Inspects local CLI binary health, versions, paths, and platform info. |
| (none) | Returns the comprehensive orchestration guide for calling agents. |
# Clone the repository
git clone https://github.com/kiranmaya/ai-cli-mcp.git
cd ai-cli-mcp
# Install dependencies or install in editable mode
pip install -e .Run the server status check directly in Python:
python -c "import asyncio, server; print(asyncio.run(server.cli_status()))"Edit %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"ai-cli-gateway": {
"command": "python",
"args": [
"C:/Projects2026/AgentsCLI_MCP_Server/ai_cli_mcp_server.py"
],
"env": {
"CLI_YOLO_MODE": "true"
}
}
}
}In Cursor, add to .cursor/mcp.json:
{
"mcpServers": {
"ai-cli-gateway": {
"command": "python",
"args": [
"C:/Projects2026/AgentsCLI_MCP_Server/ai_cli_mcp_server.py"
]
}
}
}(For detailed setup in Antigravity IDE, Windsurf, and VS Code Cline, see INSTALLATION_AND_CLIENTS.md.)
A calling agent (e.g. Claude) can execute an end-to-end task and peer review:
# 1. Dispatch feature implementation to Codex
codex_run(
prompt="Implement JWT refresh token rotation with SQLite in src/auth.py",
working_directory="C:/MyProject"
)
# 2. Dispatch cross-verification review to Antigravity
antigravity_review(
working_directory="C:/MyProject",
instructions="Audit security edge cases for token invalidation in src/auth.py"
)ai-cli-mcp/
├── ai_cli_mcp_server.py # Main CLI entrypoint
├── server.py # MCP Server & Tool definitions
├── config.py # Path discovery & sandbox validation
├── process.py # Async process execution & tree killing
├── cli/
│ ├── codex.py # OpenAI Codex CLI adapter
│ └── antigravity.py # Google Antigravity CLI adapter
├── models/
│ └── requests.py # Pydantic schemas & response models
├── skills/
│ └── document.md # In-depth agent usage & skills documentation
├── pyproject.toml # Packaging & build configuration
├── requirements.txt # Core dependencies
├── INSTALLATION_AND_CLIENTS.md # Client configuration reference
└── README.mdVariable | Default | Purpose |
|
| Runs commands with permission-bypass flags. |
|
| Default timeout in seconds (5 min). |
|
| Maximum timeout ceiling (30 min). |
|
| Sandbox directory whitelist (comma-separated). |
| Auto | Override path to |
| Auto | Override path to |
MIT License. See LICENSE for details.
Performs an automated code review on a workspace using Google Antigravity CLI.
Args: working_directory: Root directory of the workspace or repository to review. instructions: Optional custom review criteria, guidelines, or focus areas. model: Optional model override. timeout: Execution timeout in seconds (default: 300).
Returns: JSON string containing review critique, exit code, and execution summary.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| timeout | No | ||
| instructions | No | ||
| working_directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does state the tool executes an external CLI and returns a JSON string with critique, exit code, and summary, which is useful. However, it does not disclose whether the review is read-only, whether the Antigravity CLI must be pre-installed/authenticated, or what happens on timeout. These are meaningful gaps for a tool that invokes an external command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a single purpose sentence followed by a short Args list and a one-line Returns format. Every sentence adds value, and the key information is front-loaded. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema means return-value details are already covered, and the parameter semantics are provided. But for a CLI-invoking tool with no annotations, important context is missing: when to use this over sibling tools, prerequisites like CLI installation/auth, and whether the operation mutates the workspace. The description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section gives meaningful semantics for all four parameters: 'working_directory' is clarified as the root of the workspace or repository, 'instructions' as custom review criteria, 'model' as an optional override, and 'timeout' with its default. The model override remains vague about available options, but this is a solid compensation given the schema provides no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Performs an automated code review on a workspace using Google Antigravity CLI.' This distinguishes it from codex_review by naming Antigravity, and from antigravity_run through the 'review' verb. However, it doesn't explicitly call out any sibling by name, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like codex_review or antigravity_run. The optional 'instructions' parameter hints at customization, but there is no explicit context, exclusion, or alternative recommendation. The agent is left to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a coding prompt non-interactively using Google Antigravity CLI (agy).
Args: prompt: Detailed instruction or task description for the Antigravity agent. working_directory: Target project root directory where the task executes. model: Optional model override (e.g. gemini-2.5-pro, gemini-2.5-flash). timeout: Execution timeout in seconds (default: 300, max: 1800). yolo: When true, runs in YOLO mode (--dangerously-skip-permissions) for automated non-blocking execution.
Returns: JSON string containing success status, exit code, execution time, stdout, and stderr.
| Name | Required | Description | Default |
|---|---|---|---|
| yolo | No | ||
| model | No | ||
| prompt | Yes | ||
| timeout | No | ||
| working_directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: YOLO mode as '--dangerously-skip-permissions' for non-blocking execution, timeout limits, non-interactive operation, and the returned JSON structure. It does not mention prerequisites like authentication or explicit side effects on the working directory, but it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with one clear purpose sentence, then uses a structured Args list and a Returns section. Every sentence adds value with no redundancy or filler, making it efficient and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, the return value, execution mode, and the YOLO flag, making it highly usable. It lacks explicit environmental prerequisites (e.g., AGY installed, authentication) and doesn't explicitly state that the tool may modify files in working_directory, but these are minor gaps given the output schema and detailed Args section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a dedicated Args section that explains all five parameters, including defaults and semantics (e.g., timeout default 300 with max 1800, yolo default true, model override). Since schema description coverage is 0%, this fully compensates and adds meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('executes'), resource ('coding prompt'), and mode ('non-interactively using Google Antigravity CLI'). This clearly distinguishes it from sibling tools like codex_run (different CLI) and antigravity_review (review vs. run), so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a non-interactive Antigravity execution tool, and the phrase 'using Google Antigravity CLI' implicitly differentiates it from codex_run. However, it does not explicitly name alternatives or state when not to use this tool, though the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the operational status of Codex CLI and Antigravity CLI binaries on the host.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool checks status and is host-local, which implies a read-only inspection, but it does not explicitly state that no modifications occur, nor what happens if a binary is missing. It is adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the verb and resource, with zero filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema, the description covers the essential facts: what is checked and where. It could slightly improve by hinting at failure behavior, but nothing critical is missing for a status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is trivially complete, so the baseline of 4 applies. The description correctly adds no unnecessary parameter information; nothing more is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Checks'), a clear resource ('operational status of Codex CLI and Antigravity CLI binaries'), and a location ('on the host'). This clearly differentiates it from sibling tools like codex_run, codex_review, and get_agent_skills, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for verifying the availability/operational state of the CLIs before running or reviewing, but it does not explicitly state when to use it versus alternatives or when not to use it. The usage context is reasonably inferable but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs an automated code review on a git repository using OpenAI Codex CLI.
Args: working_directory: Root directory of the Git repository to review. instructions: Optional review focus areas or guidelines (e.g. security, memory leaks). model: Optional model override. timeout: Execution timeout in seconds (default: 300). uncommitted: When true, reviews uncommitted staged and unstaged changes.
Returns: JSON string containing code review output, exit code, and execution summary.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| timeout | No | ||
| uncommitted | No | ||
| instructions | No | ||
| working_directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description correctly carries the full burden of behavioral disclosure and largely succeeds: it discloses the execution timeout and its default, the uncommitted-review behavior, that an external CLI is invoked, and the return shape (output, exit code, summary). It slightly under-discloses what 'review output' actually contains and how failures surface, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized: a one-line purpose statement, a clean Args list, and a Returns note. Every sentence carries information and there is no fluff or repetition. The format is front-loaded and scannable for an agent parsing the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool (5 params, external CLI, side-effect-free review) the definition is complete: purpose, all parameters, timeout semantics, and return format are covered. The Returns section effectively substitutes for the output schema by describing the JSON string contents. Minor omissions such as error/exit-code interpretation and whether network access to Codex is required keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is fully responsible for parameter documentation, and it compensates excellently. The Args block documents all five parameters with meaningful semantics: working_directory (root dir), instructions (focus areas, e.g. security, memory leaks), model (override), timeout (seconds, default 300), and uncommitted (staged and unstaged changes). Only the default=true for uncommitted is arguably non-obvious, but it is still declared.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb ('reviews'), a resource ('git repository'), and a method ('using OpenAI Codex CLI'). This clearly separates it from codex_run/antigravity_run (execution tools), and naming the backend distinguishes it from antigravity_review. However, it never mentions the antigravity_review sibling, so an agent cannot tell them apart purely from this text without inferencing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: it reviews code, so an agent will infer 'use this when a code review is wanted.' But there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives like antigravity_review. The description leaves selection among review siblings to the agent's own judgment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a coding prompt non-interactively using the OpenAI Codex CLI.
Args: prompt: Detailed instruction or task description for the Codex agent. working_directory: Target project root directory where the task executes. model: Optional model override (e.g. o3-mini, o1, gpt-4o). timeout: Execution timeout in seconds (default: 300, max: 1800). yolo: When true, runs in YOLO mode (--dangerously-bypass-approvals-and-sandbox) for automated non-blocking execution.
Returns: JSON string containing success status, exit code, execution time, stdout, and stderr.
| Name | Required | Description | Default |
|---|---|---|---|
| yolo | No | ||
| model | No | ||
| prompt | Yes | ||
| timeout | No | ||
| working_directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does transparently mention YOLO mode and the '--dangerously-bypass-approvals-and-sandbox' flag, which signals safety implications, and it discloses the non-interactive nature. However, it does not explicitly state that running the prompt can modify the working directory, execute arbitrary code, or require authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a purpose sentence followed by labeled Args and Returns sections. Every line carries useful information, and there is no redundant repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and the output shape, which is sufficient for most invocation decisions. It is slightly incomplete for an arbitrary-code execution tool because it does not mention prerequisites such as Codex CLI installation/authentication or potential filesystem side effects, but the YOLO flag disclosure partially mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates for every parameter: prompt, working_directory, model with concrete examples, timeout with default and max, and yolo with behavior and flag mapping. It adds meaning that the bare schema titles lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Executes a coding prompt non-interactively using the OpenAI Codex CLI.' This clearly differentiates the tool from siblings like codex_review and cli_status, making its role as the execution-focused tool obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose codex_run over codex_review, antigravity_run, or antigravity_review. There is no stated condition such as 'use for non-interactive execution' versus 'use review for critique', so an agent must infer the appropriate selection from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the comprehensive AI Agent Skills & Usage Guide for delegating tasks to Codex and Antigravity.
Calling agents should read this guide to understand:
Tool invocation parameters and return formats
YOLO autonomous mode execution mechanics
Decision matrix for choosing Codex vs. Antigravity
Multi-agent collaboration pipelines and prompt patterns
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns a guide and lists its contents, which is sufficient for a read-only documentation tool. It doesn't mention side effects or output format, but these are not critical for a static guide retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, then efficiently lists the guide's contents in bullet points. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter documentation tool, the description is complete. It clearly states what the tool returns and what the guide covers, which is sufficient for an agent to decide to call it. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially 100%, so the baseline for parameter semantics is 4. The description doesn't need to add parameter details since there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a comprehensive guide for delegating tasks, naming the resource and its purpose. It distinguishes itself from the sibling execution tools (codex_run, antigravity_run) by being a documentation resource rather than an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells agents to read this guide to understand key aspects of delegation, implying it should be used before executing tasks. However, it does not explicitly compare to alternatives or state when not to use it, though the contrast with execution tools is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0antigravity_reviewantigravity_runcli_statuscodex_reviewcodex_runget_agent_skillsScored across 6 tools
The two run tools and two review tools are intentionally parallel but clearly distinguished by vendor (Codex vs. Antigravity), and cli_status/get_agent_skills are wholly distinct. The main confusion risk is between codex_run and antigravity_run, but descriptions make the target CLI explicit.
The core tools follow a consistent vendor_action pattern (codex_run, antigravity_run, codex_review, antigravity_review). cli_status and get_agent_skills break the pattern slightly, but they are also different kinds of operations and the names remain readable and predictable.
Six tools is a well-scoped set for a server that wraps two external CLI agents. Each tool covers a distinct operational need: execute, review, status check, and usage guidance.
The server covers the primary workflows one would expect: running and reviewing with both Codex and Antigravity, plus environment status and skill guidance. Minor gaps like model listing or installation tooling exist, but agents can work around them.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
