Skip to main content
Glama

antigravity-claude-mcp

Give Claude Code a second brain. Ask Google Antigravity — Gemini 3 Pro, Claude, or GPT-OSS — for an independent code review or second opinion, right from inside Claude Code. One command. Zero dependencies.

npm node license

claude mcp add antigravity -- npx -y antigravity-claude-mcp

That's it. Restart Claude Code, and Claude can now call ask_antigravity to get a second model's take on any plan or diff.


Why

Claude reviewing its own code is Claude reviewing its own code. You don't catch your own blind spots by thinking harder — you catch them with a different mind.

This bridges Claude Code to Google Antigravity's CLI (agy), so Claude can hand a plan or a diff to a different model family (Gemini 3 Pro by default) and get an independent verdict — before you do. Two models check the work; you make the call.

It's the wiring behind a simple loop:

You ── prompt ──▶ Claude validates ──▶ asks Antigravity (Gemini) ──▶ they agree on ONE plan
                                                                          │
        you approve ◀── Antigravity reviews the diff ◀── Claude writes the code

See examples/CLAUDE_ANTIGRAVITY_LOOP.md for the full working agreement you can drop into any project.


Related MCP server: peer-agents-mcp

Quickstart (2 minutes)

1. Install the Antigravity CLI (if you don't have it) and sign in once:

curl -fsSL https://antigravity.google/cli/install.sh | bash
~/.local/bin/agy -p "ping" --print-timeout 5m   # opens a Google login the first time

2. Add the MCP server to Claude Code:

claude mcp add antigravity -- npx -y antigravity-claude-mcp

3. Check it's healthy (optional):

npx antigravity-claude-mcp doctor

4. Restart Claude Code, run /mcp to approve the tool, and ask:

"Use ask_antigravity to review my changes in src/auth.ts for edge cases."


How it works

┌────────────┐   MCP (stdio,    ┌─────────────────────────┐   agy -p     ┌──────────────────┐
│ Claude Code│   JSON-RPC 2.0)  │ antigravity-claude-mcp   │  --model …   │ Antigravity CLI  │
│  (Claude)  │ ───────────────▶ │  ask_antigravity tool    │ ───────────▶ │ Gemini 3 Pro /   │
│            │ ◀─────────────── │  (this package)          │ ◀─────────── │ Claude / GPT-OSS │
└────────────┘   tool result    └─────────────────────────┘   stdout     └──────────────────┘

The package is a tiny stdio MCP server that shells out to agy -p (Antigravity's headless print mode), optionally adding files/folders as context with --add-dir, and returns the model's text back to Claude.

The ask_antigravity tool

Param

Type

Required

Description

prompt

string

The question, proposed approach, or review request.

paths

string[]

Absolute file/folder paths. Antigravity reads them in full as context.

model

string

Override the model (see below). Default: Gemini 3.1 Pro (High).


Models

Whatever your Antigravity account exposes via agy models, for example:

  • Gemini 3.1 Pro (High)default (strong, and a different family from Claude)

  • Gemini 3.5 Flash (Low|Medium|High) (fast/cheap)

  • Claude Sonnet 4.6 (Thinking), Claude Opus 4.6 (Thinking)

  • GPT-OSS 120B (Medium)

Why default to Gemini, not Claude? The whole point is an independent reviewer. Using a Claude model to review Claude's work defeats the cross-check. Override per call with model if you want a specific one.


Configuration

Set as environment variables on the MCP server (e.g. via claude mcp add ... -e KEY=VAL):

Variable

Default

Purpose

AGY_BIN

auto-detected

Absolute path to the agy binary.

AGY_MODEL

Gemini 3.1 Pro (High)

Default model for every call.

AGY_TIMEOUT

5m

Headless print timeout.


Troubleshooting

agy runs but prints "passed to Electron/Chromium" warnings. You have the Antigravity IDE installed, and plain agy on your PATH is a symlink into Antigravity.app — that's the editor, not the CLI. This package auto-detects and skips it, preferring the real CLI at ~/.local/bin/agy. If you call agy by hand, use the full path or set AGY_BIN.

"Authentication required." Sign in once interactively: ~/.local/bin/agy -p "ping" --print-timeout 5m, open the printed Google link, approve, and paste the code back into that prompt.

Tool doesn't appear in Claude Code. Restart Claude Code after claude mcp add, then run /mcp and approve ask_antigravity. claude mcp list should show antigravity ✔ Connected.


vs. a proxy

Some projects route Claude Code's own traffic through Antigravity via an Anthropic-compatible proxy (i.e. Claude Code is "powered by" Antigravity). This is the opposite and complementary: Claude Code stays Claude, and Antigravity becomes a tool Claude can consult — so you get two genuinely different models in one loop instead of swapping one out for the other.


Requirements

License

MIT © Arjun Thilak

Available Tools

1 tool
ask_antigravityA

Get an INDEPENDENT second opinion or code review from Google Antigravity (default model: Gemini 3.1 Pro High) — a different model family than Claude, so it is a real cross-check, not Claude reviewing Claude. Provide a prompt; optionally pass paths (absolute file or folder paths) and Antigravity will read the ENTIRE file/folder as context before answering. Use it to validate an approach before coding, get an alternative design, or review code for bugs / edge cases / style.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOptional model override (e.g. "Claude Opus 4.6 (Thinking)", "GPT-OSS 120B (Medium)"). Default: Gemini 3.1 Pro (High).
pathsNoOptional absolute paths to files or folders to give Antigravity as full context.
promptYesThe question, proposed approach, or code-review request.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description bears full transparency burden. It discloses that the tool reads entire files/folders when paths are given, uses a default model (Gemini 3.1 Pro High), and provides an independent perspective. However, it omits operational details like error handling or response format.

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 concise, well-organized, and front-loaded with the main value proposition. Every sentence serves a purpose without redundancy or verbosity.

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 complexity (three parameters, no output schema), the description covers the main semantics and usage context. It could mention that the response is free-form text or provide example output, but it is sufficient for an agent to understand the tool's function.

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%, and the description adds meaning beyond each parameter's schema description. It explains that 'paths' are read as full context, 'model' defaults to a specific model, and 'prompt' is the user's request. This clarifies usage well.

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: to get an independent second opinion or code review from a different model family (Google Antigravity/Gemini 3.1 Pro High). It uses specific verbs like 'validate', 'review', and distinguishes from Claude by emphasizing cross-check value.

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 explicitly lists ideal scenarios: validating an approach before coding, getting an alternative design, or reviewing code for bugs/edge cases/style. It implicitly differentiates from using Claude by noting the cross-check benefit, but does not explicitly state when not to use it.

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 updatev0.1.0
    • First observedask_antigravity

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools, so disambiguation is perfect.

Naming Consistency5/5

The single tool name 'ask_antigravity' follows a clear verb_noun pattern, and with only one tool, naming consistency is perfect.

Tool Count3/5

One tool is minimal but may be appropriate for a simple 'ask a question' service. However, it lacks separate tools for different operations, making it borderline.

Completeness5/5

The single tool covers the entire domain of asking a second opinion with context, leaving no obvious gaps for this narrow purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Multi-perspective code analysis using Claude Code, Codex, and Antigravity CLI agents to provide direct, honest technical feedback on code, architecture, and ideas.
    4
    93 npm
    14
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Lets Claude Code use Google's Antigravity CLI (agy) to review plans or execute them in isolated git worktrees, with safety controls like secret scanning.
    4
    24 npm
    MIT