antigravity-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTIGRAVITY_LOG_LEVEL | No | Log verbosity (written to stderr). | INFO |
| ANTIGRAVITY_STATE_DIR | No | Where `jobs.json` and `supervision.sqlite3` live. Defaults to the platform state dir (e.g. `%LOCALAPPDATA%\antigravity-mcp` on Windows). Set this to a separate directory if you run both upstream and this fork. | |
| ANTIGRAVITY_JOB_TIMEOUT | No | Seconds before a job is abandoned. | 1800 |
| ANTIGRAVITY_DISABLE_LOCAL | No | Skip the local backend entirely. Unset by default. | |
| ANTIGRAVITY_EVENT_PROFILE | No | Selects the job-event/webhook profile. Unset by default. | |
| ANTIGRAVITY_MAX_CONCURRENT_JOBS | No | Jobs running at once; extras queue. | 3 |
| ANTIGRAVITY_MAX_CONCURRENT_REQUESTS | No | Tool calls handled in parallel. | 16 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
GPT owns core design/implementation, multi-parent decomposition and final review. Dispatch independent roots/workers/agents on one IDE, then end the GPT turn. Native jobs get non-LLM local status checks every 300 seconds. Keep tunnel/MCP/IDE running. Subscribe to agent_job.attention for that exact job_id when events are available. Normal progress stays local. Use get_agent_job_status for compact status; fetch check_agent_job details only for completion or problems. A local timer alone cannot wake ChatGPT; do not promise automatic resume before a real event subscription and end-to-end delivery have been verified.
Default project workflow: GPT plans and reviews; Gemini 3.8 Flash (High) executes. GPT fixes the core design, immutable inputs, interfaces and acceptance criteria, then prepares independent parent groups, workers and leaf tasks. Submit ONE dispatch_gemini_agent with task beginning exactly 'Execute this GPT-approved independent multi-parent plan:' followed by a newline and JSON {core_plan, parents}. Each parent has id, objective, inputs, outputs, depends_on: [], workers. Each worker has id, objective, inputs, outputs, depends_on: [], agents. Each leaf has id, objective, inputs, outputs, depends_on: []. Use at least two independent parents, at least two workers per parent and at least two agents per worker. Actual counts come from the independent tasks; there are no fixed two- agent or three-worker/parent caps. Shared immutable read-only inputs are allowed; all sibling writes must be disjoint and cannot be peer inputs. GPT resolves semantic dependencies before execution and integrates results afterward. The MCP creates separate genuine root conversations on ONE pinned Antigravity IDE endpoint. Each root sees only its own assignment and owns its native workers and their agents. All roots use High; descendants inherit High. Runtime metadata, real native IDs, ownership and terminal results are validated before success. GPT is the host planner; the MCP does not start an additional GPT service. Ordinary questions and administrative diagnostics may execute directly. Legacy single-parent plans remain an explicit compatibility path only.
Delegate work to a local Antigravity IDE agent instead of doing it inline when the task is large-context, parallelisable, or mechanical.
Typical loop: call list_available_models if you do not already know a live model name, dispatch_gemini_agent to start the job (returns immediately with a job_id), continue your own work, then check_agent_job to collect the result. Always review a subagent's output before applying it to files.
Default collaboration model: Gemini 3.8 Flash (High), loaded from this MCP's workflow_settings.json. An explicit model argument remains an explicit override. GPT owns the core design, fixed interfaces, immutable inputs, acceptance criteria, task decomposition and final review. For substantial implementation work, GPT must first prepare mutually independent work packages and validate their declared inputs and outputs. Each package and each of its child tasks has depends_on=[], disjoint writes, and no reads of peer outputs. Shared fixed read-only inputs are allowed. Resolve semantic dependencies before dispatch; integration occurs after the independent tasks finish. Execute the plan through ONE top-level dispatch with multiple independent root conversations on ONE Antigravity IDE endpoint. Each root owns multiple native workers. Parent, worker and agent counts come from the reviewed plan; there are no fixed two-agent or three-worker/parent caps. The separate top-level MCP job queue controls task groups. Each worker creates at least two genuine native agents with independent responsibilities. Use define_subagent/invoke_subagent, never a serial simulation of roles. EnableSubagentTools belongs to define_subagent; enable it on workers so they can create their own agents. Native descendants use Model='inherit' from the High parent and Workspace='inherit'. Every worker collects its children's actual terminal states and results; the parent collects every worker's terminal state and results. Returning 'awaiting' or assigning logical conversation IDs does not prove completion. Report missing results and failed verification as incomplete. Read-only administrative probes and configuration maintenance may run directly without spawning a worker tree. Review agent output before applying changes.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dispatch_gemini_agentA | Dispatch a coding, analysis, or research task to a background Antigravity subagent. Returns immediately with a job_id so the orchestrator is never blocked. |
| list_available_modelsA | List the live models available from the Antigravity IDE or Gemini REST fallback. Call this before dispatch_gemini_agent when you do not already know an exact, currently-live model name. |
| check_agent_jobB | Check the status, logs, duration, and output of a dispatched agent job. |
| list_active_jobsC | List active, pending, completed, cancelled, or failed subagent jobs. |
| cancel_agent_jobB | Cancel a running background subagent job. |
| gemini_code_searchB | Use a large-context model to scan multiple repository files at once and answer architectural or code questions about them. Runs synchronously and returns the answer. |
| get_agent_job_statusA | Read compact status for one known job_id without task prompts, logs or full output. Prefer for low-token follow-up. |
| supervise_agent_jobA | Enable/disable local non-LLM 300-second supervision of one known job. Does not itself schedule or wake GPT. Native dispatches enable it automatically. Acknowledge a stall only after reviewing it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools have clearly distinct purposes (dispatch, cancel, list, supervise, model listing, synchronous code search). The one genuinely confusable pair is check_agent_job vs get_agent_job_status, which both read job status, but the descriptions draw a useful line between full logs/output versus compact low-token status.
Seven of eight tools follow a clear verb_noun pattern (list_available_models, check_agent_job, cancel_agent_job, get_agent_job_status, etc.). The single outlier, gemini_code_search, is noun-first and breaks the convention, but overall the set is predictable.
Eight tools is well-scoped for a dispatch-and-monitor server, with each tool covering a distinct lifecycle step (discover models, dispatch, poll, cancel, supervise, list, code search). Nothing feels redundant or missing at the count level.
The surface covers the full lifecycle of dispatching, monitoring, supervising, and cancelling background jobs, plus model discovery and synchronous code search. Minor gaps exist around job cleanup/retention and retry/resume of failed jobs, which agents can work around.