Antigravity MCP Server

Overview Schema Source Related Servers Discussions Admin

batch-antigravity

Destructive

Delegate multiple atomic tasks for batch processing to handle repetitive operations, mass refactoring, and automated transformations.

Instructions

Delegate multiple atomic tasks to Antigravity for batch processing. Ideal for repetitive operations, mass refactoring, and automated transformations.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tasks": "<tasks>"
    },
    "name": "batch-antigravity"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Agent mode (--mode): accept-edits, auto (sandboxed autonomy; not available on every account), or plan (answers go into a plan artifact).
`model`	No	Optional model override applied to every task. Known: Gemini 4 Hydrogen (Low), Gemini 4 Hydrogen (Medium), Gemini 4 Hydrogen (High), Gemini 4 Hydrogen (XHigh), Gemini 4 Argon (Low), Gemini 4 Argon (Medium), Gemini 4 Argon (High), Gemini 4 Carbon (Low), Gemini 4 Carbon (Medium), Gemini 4 Carbon (High), Orchestrator (Argon), Orchestrator (Carbon), Gemini 3.8 Flash (Low), Gemini 3.8 Flash (Medium), Gemini 3.8 Flash (High), Claude Opus 5.5 (Low), Claude Opus 5.5 (Medium), Claude Opus 5.5 (High), Claude Sonnet 5.5 (Low), Claude Sonnet 5.5 (Medium), Claude Sonnet 5.5 (High), GPT-OSS 120B (Medium).
`tasks`	Yes	Array of atomic tasks to delegate to Antigravity
`effort`	No	Reasoning effort (--effort). Supported levels depend on the model — see list-models. Use with a base model ID (e.g. gemini-4-hydrogen); not supported by Orchestrator.
`timeout`	No	Maximum execution time per task in milliseconds
`parallel`	No	Execute independent tasks in parallel
`workingDir`	No	Working directory for execution
`concurrency`	No	Maximum parallel agy processes when parallel=true. Default: min(task count, 4)
`stopOnError`	No	Stop execution if any task fails
`skipPermissions`	No	--dangerously-skip-permissions. Default: true (print mode can't answer prompts), false when `mode` is set. Not allowed with mode plan.

Output Schema

Name	Required	Description	Default
`total`	Yes
`failed`	Yes
`results`	Yes
`skipped`	Yes
`successful`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 14, 2026

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known from structured data. The description adds nothing beyond those annotations — it never states that files will be modified, that edits are auto-accepted depending on mode, or that execution runs in an external agent process. For a destructive batch mutation tool, the description should at least echo the write semantics.

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 short sentences with the action front-loaded and the use-case guidance second; nothing is redundant. 'Ideal for' is slightly promotional phrasing but it does carry usage information, so it earns its place.

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?

There is an output schema, so return values need not be explained, and the parameter schema is complete. However, for a ten-parameter destructive batch executor the description is thin: it never hints at the task array shape, the per-task timeout, or the fact that concurrency and parallel interact. An agent could call it, but with little framing about blast radius.

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% and every one of the ten parameters carries a substantive description, including the nuanced interaction between mode, skipPermissions, and parallel. The description adds zero parameter-level meaning on top of that, so the baseline 3 applies — the schema is doing all the work.

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?

States a specific verb and resource — 'Delegate multiple atomic tasks to Antigravity' — and the word 'multiple' plus 'batch processing' implicitly distinguishes it from the single-task delegate/ask siblings. It stops short of naming any sibling explicitly, so an agent must infer the boundary from the plural framing alone.

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?

'Ideal for repetitive operations, mass refactoring, and automated transformations' gives real context for when this tool fits, which is better than nothing. But it offers no exclusions, no prerequisites, and no pointer to which sibling to use for a single task or for planning, which matters given 13 sibling tools in this family.

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

Deploy Server