Skip to main content
Glama
Sign In
Antigravity MCP Server

Antigravity MCP Server

by x51xxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

plan-antigravity

Read-only

Generates a structured implementation plan before coding so you can identify steps, files to touch, risks, and open questions for feature work, refactors, or investigations.

Instructions

Generate a structured implementation plan using Antigravity. Use BEFORE coding to get steps, files-to-touch, risks, and open questions. Distinct from ask-antigravity: enforces a plan-only system prompt and parses structured output.

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": {
      "goal": "<goal>"
    },
    "name": "plan-antigravity"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalYesWhat you want planned (a feature, refactor, investigation).
modelNo
effortNoReasoning 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.
formatNoOutput shape. json (default) returns structured steps/risks; markdown returns a checklist.json
timeoutNoMaximum execution time in milliseconds (default 600000)
acceptanceNoAcceptance criteria the plan must satisfy.
workingDirNo
constraintsNoHard constraints (must-not-touch areas, style rules, deadlines).
contextFilesNoPaths/globs to reference in the prompt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's job is to add process detail. It does: a plan-only system prompt is enforced and output is parsed structurally, which explains why results are shaped rather than free-form prose. It stops short of noting latency/cost or that the underlying model call can be long-running, which the timeout parameter hints at but never explains.

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?

Three short sentences, front-loaded with the purpose, then timing, then sibling differentiation. No restatement of the name and no filler.

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 nine-parameter delegation tool with no output schema, the description still conveys the return shape (steps, files, risks, questions) and the two output formats. Missing only operational context such as expected duration or the fact that it invokes an external model, which matters given a 600s default timeout.

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 coverage is 78%, near the threshold where the schema does the heavy lifting, so a 3 baseline applies. The description only adds meaning for format implicitly ('structured steps/risks' vs a checklist) and says nothing about model, workingDir, or timeout beyond what the schema already states.

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?

States a specific verb and resource ('Generate a structured implementation plan') and immediately separates it from the sibling ask-antigravity by naming the mechanism (plan-only system prompt, structured output parsing). An agent can pick this over ask-antigravity without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use BEFORE coding' gives explicit timing, and the enumerated outputs (steps, files-to-touch, risks, open questions) tell the agent what it will get. The contrast with ask-antigravity supplies a concrete alternative and the condition that selects it.

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

Deploy Server

Other Tools