Which integrations are available for this server?

Allows AI agents to interact with Google Antigravity's agy CLI, enabling prompt execution, session management, conversation continuation, and task automation with file-writing capabilities.

How do I use agy MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agy MCP Server explain the authentication flow in the current project" 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.

agy MCP Server

by toonPt0473

Overview Schema Related Servers Score Discussions

TypeScript

Remote

agy MCP Server

Bridge between Claude and Google Antigravity's agy CLI — let Claude Code (or any MCP client) drive the Antigravity agent through tool calls.

graph LR
    A[Claude Code] --> B[agy MCP Server]
    B --> C[agy CLI]
    C --> D[Antigravity / Gemini]

    style A fill:#FF6B35
    style B fill:#4A90E2
    style C fill:#00D4AA
    style D fill:#FFA500

This project mirrors the architecture of codex-mcp-server but wraps agy instead of codex.

How it works

agy exposes a non-interactive print mode: agy -p "<prompt>" runs a single prompt (the prompt is the value of -p) and prints the response to stdout. This server spawns agy -p "<prompt>" with the prompt as an argument, always closes stdin so agy never blocks waiting for input, and returns stdout as the MCP tool result. (agy only reads the prompt from stdin when -p is empty; a bare -p with no value errors with "flag needs an argument".)

Related MCP server: agy-bridge

Requirements

agy CLI v1.0.3+ on your PATH (agy --version). It ships with Google Antigravity.
You must be logged into Antigravity — agy reuses the desktop app's credentials, so there is no API key to configure here.

Install

Prerequisite (all methods): the agy CLI (v1.0.3+) must be installed and logged into Antigravity on the machine that runs the MCP server.

A) Via GitHub + npx (no manual clone)

claude mcp add agy-cli -- npx -y github:toonPt0473/agy-mcp-server

npx clones the repo and runs the prepare script (tsc) to build dist/ on first install, then launches the server. Requires git and Node on PATH. Updates: bump the repo; npx re-fetches on the next cold install (or clear the npx cache).

B) From a local clone

git clone https://github.com/toonPt0473/agy-mcp-server.git
cd agy-mcp-server
npm install            # runs the build automatically via the `prepare` script
claude mcp add agy-cli -- node "$(pwd)/dist/index.js"

C) Global binary (decoupled from the source folder)

npm install -g .       # in the cloned repo; exposes the `agy-mcp-server` bin
claude mcp add agy-cli -- agy-mcp-server

This repo also ships a project-scoped .mcp.json pointing at dist/index.js, which Claude Code picks up automatically when run from the project directory.

Tools

Tool	Description
`agy`	Run a prompt through `agy -p` (print mode) with optional model, session continuation, extra dirs, sandbox, and skip-permissions
`models`	List the models available to agy (`agy models`)
`listSessions`	View active conversation sessions
`ping`	Test server connection
`help`	Get `agy --help` output
`changelog`	Show `agy` changelog / release notes

`agy` tool parameters

Parameter	Type	Default	Description
`prompt`	string	— (required)	The task/question. Passed as the value of `agy -p`.
`model`	string	—	Model for this call (`--model`). Use a name from the `models` tool, e.g. `Claude Opus 4.6 (Thinking)`. Omit to use agy's default (or `AGY_MCP_DEFAULT_MODEL`).
`sessionId`	string	—	Multi-turn context. First turn = fresh conversation; later turns continue it.
`resetSession`	boolean	`false`	Start a fresh conversation for this session.
`conversationId`	string	—	Resume a specific agy conversation (`--conversation <id>`).
`continueConversation`	boolean	`false`	Force `agy --continue` (most recent conversation).
`addDirs`	string[]	—	Extra workspace dirs (`--add-dir`, repeatable).
`sandbox`	boolean	`false`	`--sandbox` (terminal restrictions).
`skipPermissions`	boolean	`false`	⚠️ `--dangerously-skip-permissions` — auto-approve all tool use. Needed for agy to run tools unattended.
`printTimeout`	string	`5m`	`--print-timeout` (Go duration, e.g. `90s`, `1h30m`).

Examples

Use agy to explain the auth flow in this repo
Use the models tool to see which agy models are available
Use agy with model "Claude Opus 4.6 (Thinking)" to review this design
Use agy with sessionId "refactor" to analyze this module
Use agy with sessionId "refactor" to now implement the change   # continues the same conversation
Use agy with skipPermissions true and addDirs ["./src"] to refactor and write files

Selecting a model

agy v1.0.5+ supports choosing a model. List what's available with the models tool (runs agy models), then pass the exact name as the model parameter of the agy tool — names contain spaces/parentheses and are passed safely as a single argument, e.g. Claude Opus 4.6 (Thinking) or Gemini 3.5 Flash (High).

Precedence: per-call model arg → AGY_MCP_DEFAULT_MODEL env → omitted (agy uses its own default). An unknown model name is not rejected — agy falls back to its default. Requires agy ≥ v1.0.5 (older versions have no --model flag).

Session model & limitations

agy print mode does not emit a conversation ID, so multi-turn within a sessionId uses agy --continue (continue the most recent conversation).
Because "most recent" is global to agy, avoid interleaving multiple sessions or running agy manually in the middle of a session — the continuation could attach to the wrong conversation. For precise resume, pass a conversationId you obtained from the Antigravity app.
Without skipPermissions: true, a prompt that makes agy want to use a tool may block until printTimeout, since approvals can't be given non-interactively. Use skipPermissions for agentic/file-writing tasks; leave it off for Q&A.

Environment variables

AGY_BIN — path to the agy binary (default: agy on PATH).
AGY_MCP_DEFAULT_MODEL — default --model when not set per-call (default: none → agy's own default).
AGY_MCP_PRINT_TIMEOUT — default --print-timeout when not set per-call (default 5m).
AGY_MCP_LOG_DIR — enable conversation logging into this directory (see below).
AGY_MCP_LOG_FILE — enable conversation logging into this single file (overrides AGY_MCP_LOG_DIR).
STRUCTURED_CONTENT_ENABLED — emit structuredContent in results (1/true/yes/on). Off by default; _meta is always included for Claude Code.

Conversation logging

Every agy tool call (the prompt Claude sent and the response agy returned) can be appended to a Markdown transcript. Logging is off by default; enable it by setting one of:

AGY_MCP_LOG_DIR=/path/to/dir → one file per day: agy-conversations-YYYY-MM-DD.md
AGY_MCP_LOG_FILE=/path/to/file.md → a single file (takes precedence)

Set it in the env block of your .mcp.json, e.g.:

{
  "mcpServers": {
    "agy-cli": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "github:toonPt0473/agy-mcp-server"],
      "env": { "AGY_MCP_LOG_DIR": "/abs/path/to/project/.agy-logs" }
    }
  }
}

Each entry records the timestamp, mode (fresh/continue/resume), sessionId, conversationId, duration, flags (sandbox/skipPermissions/addDirs), and the full prompt and response. Logging failures are reported to stderr but never break the tool. Add the log directory to .gitignore if you don't want transcripts committed.

Development

npm install     # install dependencies
npm run dev     # run from source with tsx
npm run build   # compile to dist/
npm test        # run the test suite
npm run lint    # eslint
npm run format  # prettier

License

ISC

Available Tools

5 tools

agyA

Destructive

Run a prompt through the Antigravity CLI (agy) in non-interactive print mode and return the response. Supports multi-turn continuation, extra workspace directories, sandbox, and auto-approval of tool permissions.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	The coding task, question, or analysis request
`sessionId`	No	Optional session ID for multi-turn context. The first turn starts a fresh agy conversation; later turns in the same session continue it via `agy --continue`. Note: agy continues the most-recent conversation globally, so avoid interleaving sessions or manual agy usage mid-session.
`resetSession`	No	Reset the session history before processing this request (starts a fresh agy conversation)
`conversationId`	No	Resume a specific agy conversation by ID (e.g. one obtained from the Antigravity app). Maps to `agy --conversation <id>` and takes precedence over session continuation.
`continueConversation`	No	Force `agy --continue` to continue the most recent conversation, regardless of session state
`addDirs`	No	Extra directories to add to the agy workspace (maps to repeated `--add-dir` flags)
`sandbox`	No	Run agy in a sandbox with terminal restrictions enabled (`--sandbox`)
`skipPermissions`	No	DANGEROUS: auto-approve all tool permission requests without prompting (`--dangerously-skip-permissions`). Required for agy to use tools non-interactively, but lets it modify files/run commands unattended.
`printTimeout`	No	Timeout for print mode as a Go-style duration (e.g. "90s", "5m", "1h30m"). Maps to `--print-timeout`. Defaults to 5m.

TDQS

A4/5.0

Behavior4/5

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

Annotations indicate destructiveHint=true and openWorldHint=true. The description adds significant behavioral context: non-interactive mode, multi-turn continuation, sandbox, and auto-approval with danger warnings. It also warns about session interleaving, going beyond what annotations provide.

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 a single, well-structured sentence that encapsulates all key features without redundancy. Every clause adds value, and the main action is front-loaded.

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 9 parameters and no output schema, the description covers the core functionality (print mode, multi-turn, sandbox, auto-approval). It does not explain the return format explicitly, but 'return the response' implies CLI output. Error handling is not addressed.

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 baseline is 3. The description does not add new parameter-level details beyond the schema's own descriptions, which are already thorough (e.g., sessionId warning, skipPermissions danger). Hence the description adds marginal value.

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 action ('Run a prompt through the Antigravity CLI'), the resource (agy), and the mode (non-interactive print mode). It distinguishes the tool from siblings like changelog, help, listSessions, and ping, which serve different purposes.

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 clear context for the tool's functionality but does not explicitly state when to use it versus alternatives. The sibling tools are different, but no direct usage guidance or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

changelogA

Read-onlyIdempotent

Show the Antigravity CLI (agy) changelog and release notes

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it shows changelog and release notes, but no further behavioral details beyond what annotations provide. It does not contradict annotations.

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 a single sentence that efficiently conveys the tool's purpose. Every word is necessary, and there is no extraneous information.

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 the tool has no parameters, is annotated as read-only, and has no output schema, the description is complete enough. It tells the agent exactly what the tool does without missing context.

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, and the schema coverage is 100% (empty schema). Since there are no parameters to document, the description does not need to add parameter semantics. A baseline of 4 is appropriate for zero-parameter tools.

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 that the tool shows the changelog and release notes for the Antigravity CLI (agy). It uses a specific verb ('Show') and resource ('changelog and release notes'), and the tool is easily distinguishable from siblings like 'help' and 'listSessions'.

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 does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. While the purpose is straightforward, the dimension requires at least some context about usage, which is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

helpA

Read-onlyIdempotent

Get Antigravity CLI (agy) help information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already document readOnlyHint and idempotentHint. The description adds context by specifying the resource (Antigravity CLI agy), which is valuable beyond annotations.

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?

Single sentence with no wasted words. Front-loaded with purpose, concise and effective.

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 trivial complexity (no parameters, no output schema), the description is complete enough. It tells what the tool does, though could mention what help format is returned (e.g., text).

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?

No parameters in the schema, and coverage is 100% (vacuously). With zero params, baseline is 4; description adds no further semantic burden and is appropriate.

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?

Description clearly states the tool retrieves help information for the Antigravity CLI (agy), with a specific verb and resource. It distinguishes from sibling tools like 'agy' (main command), 'changelog', 'listSessions', and 'ping', as help is a distinct utility.

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?

No explicit guidance on when to use this tool versus siblings. Usage is implied for obtaining help, but no exclusions or alternatives are provided, which is acceptable given the tool's simplicity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listSessionsA

Read-onlyIdempotent

List all active conversation sessions with metadata

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds the qualifier 'active' and mentions metadata, which is consistent and adds value beyond annotations.

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 a single concise sentence that conveys the purpose without any filler or unnecessary words.

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 the simplicity (no parameters, clear annotations, no output schema), the description is complete and provides sufficient information for an agent to use the tool 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?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter information, as there are none. Baseline score of 4 is appropriate.

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 active conversation sessions with metadata, using a specific verb and resource. It distinguishes itself from sibling tools which have different purposes.

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 usage context (listing sessions) but does not explicitly state when to use or not use versus alternatives. However, sibling tools are distinct, so the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Read-onlyIdempotent

Test MCP server connection

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	Message to echo back

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context beyond stating it's a connection test. It doesn't discuss side effects, errors, or performance, but annotations cover the safety profile adequately.

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?

Single, front-loaded sentence with no unnecessary words. Every word is meaningful and efficiently conveys the tool's purpose.

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 ping/health-check tool with no output schema and rich annotations, the description is adequate. It informs the agent of the core function. However, missing details like return value behavior could be improved, but not critical.

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% for the single 'message' parameter, which has a clear description 'Message to echo back'. The tool description does not add further parameter semantics, but the schema is sufficient.

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?

Description clearly states 'Test MCP server connection', which is a specific verb (test) and resource (MCP server connection). It distinguishes from sibling tools like 'agy', 'changelog', 'help', and 'listSessions' which have different purposes.

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, no explicit when-not-to-use, and no mention of prerequisites or context. The description is too minimal to inform selection decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a unique purpose: running prompts, showing changelog, providing help, listing sessions, and testing connection. No overlap.

Naming Consistency2/5

Tool names use inconsistent conventions: most are lowercase (agy, changelog, help, ping) but one is camelCase (listSessions). No clear pattern.

Tool Count5/5

Five tools is appropriate for a CLI wrapper MCP server, covering core interactions without unnecessary complexity.

Completeness4/5

Core functionality is covered (run prompts, get help, list sessions), but missing tools for session management (e.g., end session) or configuration (e.g., auto-approval settings) are minor gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Railway MCP
com.railway
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Cloud Platforms Developer Tools CI/CD & DevOps
2
SentinelX MCP
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
25
mcp-server
ai.cdbx
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Code Execution Developer Tools
1
AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121

Related MCP Servers

agy-headless-bridge MCP server
AI & Machine Learning Command Line
rhishi99
A
license
B
quality
A
maintenance
Enables calling Google's Antigravity CLI (agy) headlessly through MCP, providing tools like agy_ask and agy_research for agents like Claude Code.
Updated 19 days ago (2026-08-15 13:51 UTC)
2
15
MIT
agy-bridge
Agent Orchestration AI & Machine Learning Developer Tools
sshahzaiib
A
license
A
quality
A
maintenance
MCP bridge that lets Claude Code delegate heavy tasks to the Antigravity CLI (agy) — purpose-built tools, model routing with fallback, session continuity, and output truncation to save Claude's context and tokens.
Updated 2 months ago (2026-07-04 21:35 UTC)
4
6
110
46
MIT
agymcp
AI & Machine Learning Command Line
leologoli
F
license
Not graded
quality
C
maintenance
Wraps the Antigravity CLI (agy) as an MCP server, enabling Claude Code and other MCP clients to execute AI tasks and manage conversations via the agy command.
Updated 8 days ago (2026-08-26 12:17 UTC)
1
Antigravity MCP Server
Command Line Autonomous Agents
Ayato964
F
license
Not graded
quality
C
maintenance
Enables external agents like Gemini Spark to control Google Antigravity CLI (agy) via Model Context Protocol, supporting multimodal inputs and automatic session management.
Updated 2 months ago (2026-07-16 07:34 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/toonPt0473/agy-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

agy MCP Server

How it works

Requirements

Install

A) Via GitHub + npx (no manual clone)

B) From a local clone

C) Global binary (decoupled from the source folder)

Tools

agy tool parameters

Examples

Selecting a model

Session model & limitations

Environment variables

Conversation logging

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`agy` tool parameters