Skip to main content
Glama

Ask Antigravity (new conversation)

antigravity_ask

Ask Google's Antigravity CLI (agy) a question in a new conversation and get the model's final response as text. Use it for short tasks and tool-calling.

Instructions

Ask Antigravity (agy CLI, Gemini by default) a question in a NEW conversation.

Uses your existing AI Pro authentication (silent-auth via Windows Credential Manager). Returns the model's final response as text. Good for fast tool-calling and short tasks; for heavier reasoning pick a bigger model or use the host model directly.

Input Schema

NameRequiredDescriptionDefault
planNoIf true, run agy in PLAN mode (agy 1.1.12+): it investigates and writes an implementation plan instead of touching anything. Verified on 1.1.20 that a file write and a shell command are both refused and diverted into a plan document under agy's own directory — even when the prompt insists, and even though the bridge still passes --dangerously-skip-permissions — while file READS answer normally. Use it to point Antigravity at a repo you don't want it editing. Two caveats. It is agent-enforced, not an OS sandbox: it constrains agy's agent loop, so treat it as a strong default rather than a boundary you'd rely on against a hostile prompt (Codex has the real one — see codex_ask's sandbox, and its Windows caveat: as of codex 0.162.1 a sandboxed run there refuses every command and answers anyway). And it is exclusive with the bridge's slash-command shield, because agy silently disables plan mode when that shield is on; a prompt whose first token is a slash command is therefore rejected up front rather than run. Raises on agy older than 1.1.12, which ignores --mode in print mode, rather than silently running your prompt unrestricted. Default false.
modelNoOptional model slug to run this conversation on (agy's --model), e.g. "claude-sonnet-5-5-high" or "gemini-3.8-flash-low". Omit to use the model set in agy's settings.json (gemini-3.8-flash-high as of agy 1.3.5). Must be one of `agy models` — an unknown slug is rejected up front. agy renames and drops models between releases, often with no changelog entry, so a slug from older docs may be gone; see antigravity_status / `agy models` for the valid ones.
watchNoIf true, open a live "watch" view in your browser that streams agy's steps (narration + the real commands it runs) as it works. agy still runs headless; the same final text is returned. Best- effort and cross-platform — if the browser can't open, the run completes normally. Default false.
promptYesQuestion or instruction for Antigravity.
schemaNoOptional JSON Schema (an object, or its JSON text). When given, agy is asked to produce output matching it (agy 1.1.8's --json-schema) and this tool returns the VALIDATED OBJECT as JSON text instead of prose — json.loads it. What comes back is agy's own `structured_output`, which carries exactly the declared fields; agy's prose `response` on the same run also picks up its internal toolAction/toolSummary keys and can be prefixed with a sentence, so the two are NOT interchangeable. If agy produces no structured output the call RAISES rather than handing back prose you would have to parse anyway. Needs agy 1.1.8+. IMPORTANT — write the prompt so the ANSWER is in the turn, and let the schema only shape it. agy fills the schema in a finishing pass that does not re-reason about the content, so a field the turn never established gets guessed from the schema itself. Measured on 1.1.20 with "this broke my build and wasted my whole afternoon": with enum ["positive","negative"] it answered "positive" 3 times out of 4, and simply REVERSING the enum to ["negative","positive"] flipped it to "negative" 2 out of 2 — it was following field order, not the sentence. Adding a `reason` field did not help; the reason came back "Completed sentiment classification task." Asking the prompt to state the verdict and why, and keeping the same biased enum, was correct 3 out of 3. So: extraction of what the model has already worked out is reliable; a judgment delegated to the schema is not.
timeout_sNoMax seconds to wait for agy to complete. Default 180.
workspaceNoWorking directory for the conversation. Defaults to cwd. Choose an existing project dir for context-aware responses.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.33.0
    • changedInput schema / properties / model / description
      Previous value: -"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.8-flash-high as of agy\n   1.1.25). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs, and the default has\n   since moved to the gemini-3.8-flash family; the old form is no\n   longer accepted. Note 1.1.25 also DROPPED the gemini-3.5-flash\n   family with no changelog entry, so a 3.5 slug you saw in older\n   docs is now rejected. See antigravity_status / `agy models` for\n   the valid slugs."New value: +"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"claude-sonnet-5-5-high\" or \"gemini-3.8-flash-low\". Omit to use\n   the model set in agy's settings.json (gemini-3.8-flash-high as of\n   agy 1.3.5). Must be one of `agy models` — an unknown slug is\n   rejected up front. agy renames and drops models between releases,\n   often with no changelog entry, so a slug from older docs may be\n   gone; see antigravity_status / `agy models` for the valid ones."
    • changedInput schema / properties / plan / description
      Previous value: -"If true, run agy in PLAN mode (agy 1.1.12+): it investigates and\n  writes an implementation plan instead of touching anything. Verified\n  on 1.1.20 that a file write and a shell command are both refused and\n  diverted into a plan document under agy's own directory — even when\n  the prompt insists, and even though the bridge still passes\n  --dangerously-skip-permissions — while file READS answer normally.\n  Use it to point Antigravity at a repo you don't want it editing.\n  Two caveats. It is agent-enforced, not an OS sandbox: it constrains\n  agy's agent loop, so treat it as a strong default rather than a\n  boundary you'd rely on against a hostile prompt (Codex has the real\n  one — see codex_ask's sandbox, and its Windows caveat: as of codex\n  0.149.1 a sandboxed run there refuses every command and answers\n  anyway). And it is exclusive with the bridge's\n  slash-command shield, because agy silently disables plan mode when\n  that shield is on; a prompt whose first token is a slash command is\n  therefore rejected up front rather than run. Raises on agy older than\n  1.1.12, which ignores --mode in print mode, rather than silently\n  running your prompt unrestricted. Default false."New value: +"If true, run agy in PLAN mode (agy 1.1.12+): it investigates and\n  writes an implementation plan instead of touching anything. Verified\n  on 1.1.20 that a file write and a shell command are both refused and\n  diverted into a plan document under agy's own directory — even when\n  the prompt insists, and even though the bridge still passes\n  --dangerously-skip-permissions — while file READS answer normally.\n  Use it to point Antigravity at a repo you don't want it editing.\n  Two caveats. It is agent-enforced, not an OS sandbox: it constrains\n  agy's agent loop, so treat it as a strong default rather than a\n  boundary you'd rely on against a hostile prompt (Codex has the real\n  one — see codex_ask's sandbox, and its Windows caveat: as of codex\n  0.162.1 a sandboxed run there refuses every command and answers\n  anyway). And it is exclusive with the bridge's\n  slash-command shield, because agy silently disables plan mode when\n  that shield is on; a prompt whose first token is a slash command is\n  therefore rejected up front rather than run. Raises on agy older than\n  1.1.12, which ignores --mode in print mode, rather than silently\n  running your prompt unrestricted. Default false."
  2. Changed1 schema field changedv0.29.1
    • changedInput schema / properties / model / description
      Previous value: -"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.7-flash-high by\n   default). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs, and the default has\n   since moved to the gemini-3.7-flash family; the old form is no\n   longer accepted. See antigravity_status / `agy models` for the\n   valid slugs."New value: +"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.8-flash-high as of agy\n   1.1.25). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs, and the default has\n   since moved to the gemini-3.8-flash family; the old form is no\n   longer accepted. Note 1.1.25 also DROPPED the gemini-3.5-flash\n   family with no changelog entry, so a 3.5 slug you saw in older\n   docs is now rejected. See antigravity_status / `agy models` for\n   the valid slugs."
  3. Changed3 schema fields changedv0.28.0
    • changedInput schema / properties / model / description
      Previous value: -"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.6-flash-high by\n   default). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs and 1.1.6 added the\n   gemini-3.6-flash family; the old form is no longer accepted. See\n   antigravity_status / `agy models` for the valid slugs."New value: +"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.7-flash-high by\n   default). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs, and the default has\n   since moved to the gemini-3.7-flash family; the old form is no\n   longer accepted. See antigravity_status / `agy models` for the\n   valid slugs."
    • addedInput schema / properties / plan
      Added value: +{
      +  "default": false,
      +  "description": "If true, run agy in PLAN mode (agy 1.1.12+): it investigates and\n  writes an implementation plan instead of touching anything. Verified\n  on 1.1.20 that a file write and a shell command are both refused and\n  diverted into a plan document under agy's own directory — even when\n  the prompt insists, and even though the bridge still passes\n  --dangerously-skip-permissions — while file READS answer normally.\n  Use it to point Antigravity at a repo you don't want it editing.\n  Two caveats. It is agent-enforced, not an OS sandbox: it constrains\n  agy's agent loop, so treat it as a strong default rather than a\n  boundary you'd rely on against a hostile prompt (Codex has the real\n  one — see codex_ask's sandbox, and its Windows caveat: as of codex\n  0.149.1 a sandboxed run there refuses every command and answers\n  anyway). And it is exclusive with the bridge's\n  slash-command shield, because agy silently disables plan mode when\n  that shield is on; a prompt whose first token is a slash command is\n  therefore rejected up front rather than run. Raises on agy older than\n  1.1.12, which ignores --mode in print mode, rather than silently\n  running your prompt unrestricted. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / schema
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional JSON Schema (an object, or its JSON text). When given, agy\n    is asked to produce output matching it (agy 1.1.8's --json-schema)\n    and this tool returns the VALIDATED OBJECT as JSON text instead of\n    prose — json.loads it. What comes back is agy's own\n    `structured_output`, which carries exactly the declared fields;\n    agy's prose `response` on the same run also picks up its internal\n    toolAction/toolSummary keys and can be prefixed with a sentence, so\n    the two are NOT interchangeable. If agy produces no structured\n    output the call RAISES rather than handing back prose you would\n    have to parse anyway. Needs agy 1.1.8+.\n\n    IMPORTANT — write the prompt so the ANSWER is in the turn, and let\n    the schema only shape it. agy fills the schema in a finishing pass\n    that does not re-reason about the content, so a field the turn never\n    established gets guessed from the schema itself. Measured on 1.1.20\n    with \"this broke my build and wasted my whole afternoon\": with\n    enum [\"positive\",\"negative\"] it answered \"positive\" 3 times out of 4,\n    and simply REVERSING the enum to [\"negative\",\"positive\"] flipped it\n    to \"negative\" 2 out of 2 — it was following field order, not the\n    sentence. Adding a `reason` field did not help; the reason came back\n    \"Completed sentiment classification task.\" Asking the prompt to state\n    the verdict and why, and keeping the same biased enum, was correct\n    3 out of 3. So: extraction of what the model has already worked out\n    is reliable; a judgment delegated to the schema is not."
      +}
  4. Changed1 schema field changedv0.21.4
    • changedInput schema / properties / model / description
      Previous value: -"Optional model label to run this conversation on (agy's --model),\n   e.g. \"Gemini 3.1 Pro (High)\" or \"Claude Sonnet 4.6 (Thinking)\".\n   Omit to use the model set in agy's settings.json (Gemini 3.5 Flash\n   (High) by default). Must be one of `agy models` — an unknown label\n   is rejected up front (agy would otherwise silently ignore it and\n   fall back to the default). See antigravity_status / `agy models`\n   for the valid labels."New value: +"Optional model slug to run this conversation on (agy's --model),\n   e.g. \"gemini-3.1-pro-high\" or \"claude-sonnet-4-6\". Omit to use the\n   model set in agy's settings.json (gemini-3.6-flash-high by\n   default). Must be one of `agy models` — an unknown slug is\n   rejected up front (agy would otherwise silently ignore it and fall\n   back to the default). agy 1.1.5 replaced the old human labels\n   (\"Gemini 3.1 Pro (High)\") with these slugs and 1.1.6 added the\n   gemini-3.6-flash family; the old form is no longer accepted. See\n   antigravity_status / `agy models` for the valid slugs."
  5. Changed1 schema field changedv0.15.4
    • addedInput schema / properties / model
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional model label to run this conversation on (agy's --model),\n   e.g. \"Gemini 3.1 Pro (High)\" or \"Claude Sonnet 4.6 (Thinking)\".\n   Omit to use the model set in agy's settings.json (Gemini 3.5 Flash\n   (High) by default). Must be one of `agy models` — an unknown label\n   is rejected up front (agy would otherwise silently ignore it and\n   fall back to the default). See antigravity_status / `agy models`\n   for the valid labels."
      +}
  6. First observedv0.11.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false; the description adds genuinely new context beyond that — it runs under existing AI Pro credentials via silent auth in Windows Credential Manager, and the session is new (no prior conversation memory). It does not quantify latency or rate limits, but the auth and session-freshness disclosures are useful non-obvious traits.

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?

Four short sentences, front-loaded with the action and scope before the authentication and routing details. No filler or restatement of the title.

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?

An output schema exists and the description correctly notes the return is the final response as text, while annotations cover the open-world/non-idempotent profile. The one gap is that it doesn't warn that a new conversation carries no memory of prior turns, which matters given the antigravity_continue sibling, but everything needed to invoke it correctly is 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?

Schema description coverage is 100% and the parameter docs are exceptionally rich (plan-mode sandbox caveats, the schema finishing-pass failure mode, timeout, workspace). The description only adds a passing hint about choosing a bigger `model`, so the schema is doing essentially all the parameter work — baseline 3.

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 concrete verb+resource (ask Antigravity via the agy CLI) and pins the scope with 'NEW conversation,' which cleanly separates it from the sibling antigravity_continue. It also says what comes back ('the model's final response as text'), so an agent can select it without opening the schema.

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 a clear use context ('fast tool-calling and short tasks') and names an alternative route for heavier work ('pick a bigger `model` or use the host model directly'). It never explicitly routes follow-up turns to antigravity_continue, so the when-not guidance is implied by 'NEW' rather than stated.

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