Skip to main content
Glama

Run read-only Antigravity exploration task

explore_task

Delegate a read-only exploration and diagnosis task to the Antigravity CLI, blocking until the headless run exits. Get answers and summaries without file changes, with a git-based audit.

Instructions

Delegate a fast read-only exploration and diagnosis task to the Antigravity (agy) CLI and block until the headless run exits (synchronous; the tool call IS the wait). Defaults: mode plan (read-only), effort low; the mode preset is fixed, so callers cannot weaken the read-only posture. Produces answers and summaries without modifying files. Returns the same report as general_task, including the git-based files_touched/scope_violations audit. Headless runs auto-DENY tool requests that would prompt instead of hanging (surfaced in denied_actions); permission to allow them is granted by the user via permissions.allow rules in their own Antigravity settings.json (e.g. command()), which this server never edits. auto_approve is the expert full-auto switch (--dangerously-skip-permissions); pair it with sandbox when granting it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory for the delegated task (project the sub-agent operates on). Defaults to the server's cwd.
agentNoAntigravity agent profile to use (see list_agents)
modelNoModel for the task, e.g. gemini-3.8-flash-medium, claude-opus-5-5-high (see list_models)
effortNoReasoning effort for the task
promptYesFull, self-contained task description for the sub-agent. Include all needed context and file paths.
projectNoAntigravity project ID or name for the task
sandboxNoRun the task with Antigravity's terminal sandbox flag enabled (--sandbox)
add_dirsNoExtra directories to add to the task's workspace (--add-dir, repeatable)
edit_scopeNoGive the sub-agent an edit boundary (files and directories relative to cwd, or absolute). Out-of-scope changes are surfaced in the result's files_touched/scope_violations audit; it is an audit-and-replay control, not a sandbox — the CLI writes files itself.
timeout_msNoIdle timeout for the run in ms (0..3600000; 0 disables the idle kill for this run). Resets on every stdout/stderr chunk from the child; kicks in after this much child silence and kills the child (SIGTERM, then SIGKILL after 5s). Default: 900000 (AGY_MCP_IDLE_TIMEOUT_MS).
auto_approveNoExpert switch: pass --dangerously-skip-permissions so headless runs stop auto-denying gated tools. Pair it with sandbox when granting it. Allowed by this server.
conversation_idNoExisting agy conversation ID to continue/resume instead of starting a new conversation. Returned by previous task results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so thoroughly: synchronous blocking, fixed read-only mode, auto-denial of gated tools, permission handling via user settings, and the expert nature of auto_approve. It also discloses the git-based files_touched/scope_violations audit and how denials are surfaced.

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?

The description is dense but front-loads the main purpose, read-only guarantee, and synchronous behavior before moving into edge cases. Some repetition around read-only and permission handling keeps it from being maximally tight, but most sentences carry useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters, no annotations, and no output schema, the description supplies the missing behavioral context an agent needs: blocking semantics, fixed mode, denial behavior, permission model, and audit reporting. It is complete enough to select and invoke the tool correctly.

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%, so parameter mechanics are already documented. The description still adds useful semantic context for auto_approve as an expert full-auto switch to pair with sandbox, and clarifies that permissions are granted through the user's own Antigravity settings rather than edited by this server.

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: delegate a fast read-only exploration and diagnosis task to the Antigravity CLI. It clearly distinguishes itself from general_task by emphasizing the fixed read-only posture and synchronous blocking behavior.

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?

Gives clear usage context for read-only exploration/diagnosis and explains that the mode preset cannot be weakened. It references general_task for comparison but does not explicitly state the reverse condition—use general_task when file modification is intended.

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