Skip to main content
Glama

gemini_request

Destructive

Send a prompt to Google's Antigravity CLI via the Gemini-compatible gateway. Handles synchronous execution with automatic deferral to pollable jobs for long-running tasks.

Instructions

Run a Google Antigravity CLI (agy) request through the Gemini-compatible gateway tool synchronously (when async jobs are enabled, auto-defers to a pollable job past the sync deadline; otherwise runs to completion). Requires exactly one of prompt or promptParts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yoloNoEmit `--dangerously-skip-permissions` to auto-approve all actions. Routed through the same approval gate. Under mcp_managed the gate still decides.
modelNoModel name or alias passed to agy --model (e.g. gemini-3-pro-preview, gemini-2.5-flash, pro, flash, latest)
promptNoPrompt text for Antigravity CLI (mutually exclusive with promptParts)
projectNoAntigravity 1.0.13 --project <ID>: select the project for this session. Mutually exclusive with newProject.
sandboxNoRun Antigravity in sandbox mode (--sandbox)
worktreeNoSlice λ: run this request inside a dedicated git worktree owned by the gateway. `true` creates a fresh worktree at `<repoRoot>/.worktrees/<uuid>` branched from HEAD. `{ name?, ref? }` lets the caller supply a sanitized name and/or a git ref (default: HEAD). When the request carries a sessionId and the session already has a worktree, that worktree is reused. The gateway spawns the child CLI with `cwd: <worktree-path>` — no `-w`/`--worktree` flag is ever emitted to the underlying CLI. On session_delete or TTL eviction the gateway runs `git worktree remove --force`. Successful responses are prefixed with `[gateway] worktree=<absolute-path>\n` so callers can use the path. NOTE: callers should `.gitignore` the `.worktrees/` directory in their repo (the gateway does NOT auto-gitignore — see slice λ spec Q4).
sessionIdNoAntigravity conversation ID to resume (emits --conversation <id>). agy owns conversation ids; a fresh request returns no resumable sessionId, continue via resumeLatest:true.
skipTrustNoUnsupported for Antigravity CLI; true is rejected.
workspaceNoRegistered workspace alias for remote HTTP/OAuth provider calls. Do not use this field, workspace_list, or workspace_register_existing_repo as a fallback for stdio/local provider path access; pass workingDir/addDir/includeDirs directly instead.
mcpServersNoMCP server names accepted for approval tracking only; Antigravity manages its own MCP configuration.
newProjectNoAntigravity 1.0.13 --new-project: create a new project for this session. Mutually exclusive with project.
attachmentsNoUnsupported for Antigravity CLI; non-empty values are rejected.
includeDirsNoAdditional workspace directories passed as --add-dir. Stdio/local callers may pass local paths directly. Remote HTTP/OAuth callers must use relative paths inside a selected registered workspace. Do not call workspace_* tools to fix stdio/local provider path access.
policyFilesNoUnsupported for Antigravity CLI; non-empty values are rejected.
promptPartsNoCache-aware structured prompt: { system?, tools?, context?, task }. Mutually exclusive with prompt. Stable parts hash into cache_state for prefix-discipline tracking.
allowedToolsNoUnsupported for Antigravity CLI; non-empty values are rejected
approvalModeNoApproval mode. Only default (prompted) and yolo (auto-approve all, emits --dangerously-skip-permissions) work with the Antigravity agy headless path; auto_edit and plan are rejected at request time (agy has no headless accept-edits/plan mode).
forceRefreshNoBypass dedup and force a fresh CLI run even if a recent identical request exists
outputFormatNoOutput format. The Antigravity agy headless path emits text only; json and stream-json are rejected at request time. Per-request token usage and cost are therefore not available for gemini.text
printTimeoutNoAntigravity --print-timeout <DURATION>: print-mode wait timeout as a Go duration string (e.g. '5m0s', '30s').
resumeLatestNoContinue the most recent conversation. agy owns conversation ids; a fresh request returns no resumable sessionId, continue via resumeLatest:true.
correlationIdNoRequest trace ID (auto if omitted)
idleTimeoutMsNoIdle timeout in ms (min 30s, max 1h, omit=CLI default)
approvalPolicyNoApproval policy when approvalStrategy is mcp_managed: strict|balanced|permissive (default balanced). Ignored under legacy strategy.
optimizePromptNoOptimize prompt before execution
adminPolicyFilesNoUnsupported for Antigravity CLI; non-empty values are rejected.
approvalStrategyNoApproval strategy: legacy (default) lets the provider CLI's own flags decide; mcp_managed routes the run through the gateway approval gate (required for approvalPolicy and approval_list). Under mcp_managed the caller's permissionMode/alwaysApprove may be overridden by the gate.legacy
compressResponseNoCompress the response display text via the native compressor (default: [compression].enabled in config.toml, off unless opted in). Skipped for structured output.
createNewSessionNoForce new session
optimizeResponseNoOptimize response output
Behavior4/5

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

The description discloses important behavioral traits beyond annotations: async auto-deferral, parameter constraints (prompt/promptParts exclusivity), rejected parameters (skipTrust, attachments, policyFiles, allowedTools, adminPolicyFiles, outputFormat json/stream-json, approvalMode auto_edit/plan), and worktree lifecycle. Annotations already mark destructiveHint=true, so the description adds context about what gets rejected and async behavior.

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 relatively long but well-structured: it front-loads the core purpose and key constraints, then provides detailed parameter semantics. It could be slightly more concise, but the length is justified given the tool's complexity (30 parameters, nested objects, multiple behaviors).

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?

Given the tool's high complexity (30 parameters, no output schema), the description covers many aspects: synchronous behavior, async deferral, parameter requirements, unsupported features, worktree behavior. A missing element is a clear description of the response format beyond the worktree prefix; however, overall completeness is good.

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%, meaning all parameters have descriptions. The tool description adds some context beyond schema (e.g., the exclusivity of prompt/promptParts, worktree details, unsupported parameters), but much of the parameter semantics are already captured in the schema. Baseline 3 is appropriate as the description adds marginal additional meaning.

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 tool's purpose: 'Run a Google Antigravity CLI (`agy`) request through the Gemini-compatible gateway tool synchronously'. It specifies the required parameter constraint (exactly one of prompt or promptParts). This distinguishes it from its async sibling gemini_request_async and other provider-specific request tools.

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?

The description notes auto-deferral when async jobs are enabled, but does not explicitly guide on when to use this tool vs alternatives like gemini_request_async or claude_request. It lacks explicit when-to-use and when-not-to-use guidance, leaving the agent to infer based on model name and sync/async behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/verivus-oss/llm-cli-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server