Skip to main content
Glama
Sign In
agy-mcp-server

agy-mcp-server

by HackerWilson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

antigravity_start

Launch asynchronous Antigravity tasks for long-running analyses or refactors, returning a job ID immediately, with support for continuing existing sessions via conversation_id.

Instructions

Submit an asynchronous task to Antigravity and return a job ID without waiting for model completion. Use this for long-running tasks (e.g. multi-minute analyses, large refactors). Supports both new tasks and continuing existing sessions (if conversation_id is provided).

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": {
      "prompt": "<prompt>"
    },
    "name": "antigravity_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
yoloNoIf true (default), runs with --dangerously-skip-permissions for auto-approvals.
modelNoOptional model identifier override.
promptYesTask instructions or continuation prompt.
work_dirNoOptional working directory path.
read_onlyNoIf true, enables Antigravity --sandbox; workspace writes may still be allowed. Defaults to false.
conversation_idNoOptional Conversation ID to continue an existing session.
print_timeout_secondsNoMaximum agy execution time. Range 60-86400; defaults to 3600 seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.4

TDQS

A4/5.0
Behavior3/5

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

Because there are no annotations, the description carries the behavioral disclosure burden. It does disclose the key behavior clearly: this tool is asynchronous, returns a job ID, and has a continuation path. However, it does not disclose tool-level side effects such as the dangerous default yolo/skip-permissions behavior or what happens to workspace writes, which are meaningful transparency gaps for a no-annotation tool.

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 two sentences with no filler. The core behavior is front-loaded first, followed by the main use case and the conversation_id edge case. Every sentence earns its place and the structure makes it easy for an agent to quickly select or reject the tool.

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 an asynchronous submission tool with no output schema, the description covers the essential contract: no waiting, a job ID is returned, long-running tasks are appropriate, and existing conversations can be continued via conversation_id. It would be more complete if it pointed to the companion status/result tools or called out the default yolo safety behavior, but what is needed to invoke the tool correctly is mostly present.

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?

The schema description coverage is 100%, so the baseline is 3 even if the description adds little parameter-level detail. The description only restates the conversation_id continuation concept, which the schema already covers. It does not introduce new meaning about defaults, formats, ranges, or interactions among the seven parameters, so there is no reason to score above baseline.

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 exact action: 'Submit an asynchronous task to Antigravity and return a job ID without waiting for model completion.' This names the verb, resource, and response behavior, and it clearly differentiates itself from the synchronous-looking sibling run_antigravity. The continuation support via conversation_id is also explicitly called out, adding specificity without ambiguity.

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 gives explicit context with 'Use this for long-running tasks (e.g. multi-minute analyses, large refactors),' which tells an agent when this tool is appropriate. It also clarifies the continuation case via conversation_id. It does not explicitly name siblings like antigravity_continue as alternatives or state when not to use them, so it stops short of a 5.

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