Skip to main content
Glama
V-Songbird

gemini-relay

by V-Songbird
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

gemini-ask

Send a prompt to Google Gemini and receive direct answers for questions, code review, analysis, edits, or structured JSON. Reference project files with @path and continue conversations by passing a conversation ID.

Instructions

Send one prompt to Google Gemini (or the Claude and GPT-OSS models the Antigravity CLI also offers) and get the answer back: questions, code review, analysis, edits, structured JSON. Reference project files with @path to send their contents along. Pass conversationId to continue a thread. For a phased implementation blueprint use gemini-plan; for idea generation use gemini-brainstorm; for everything else use this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoAgent execution mode: 'plan' for architectural analysis without modifying files, 'accept-edits' for direct edit application.
agentNoOptional custom agent to run instead of the default one (the name of an agent.md agent, e.g. a reviewer persona). Ignored by an agy build without --agent.
modelNoModel to use — any id 'gemini-models' lists, or the aliases 'flash' and 'pro'. Leave it unset and no --model is sent at all, so agy answers on whatever model it is itself configured to use.
effortNoReasoning effort ('low', 'medium', 'high') for Gemini 3.8 Flash, 3.7 Flash, and 3.1 Pro. Controls depth of thinking tokens.
promptYesAnalysis request. Use @ syntax to include files (e.g., '@largefile.js explain what this does') or ask general questions
addDirsNoOptional additional workspace directories to provide context to Gemini.
sandboxNoAsk the CLI to run in sandbox mode. The agy backend forwards it but does not isolate tool execution in headless runs, and says so in a notice; the legacy gemini backend does isolate.
changeModeNoEnable structured change mode - formats prompts to prevent tool errors and returns structured edit suggestions that Claude can apply directly
chunkIndexNoWhich chunk of a changeMode response to return (1-based). With chunkCacheKey it reads the cached chunk; alone, it selects which chunk of a fresh changeMode result to return.
jsonSchemaNoOptional JSON schema to enforce structured output from Gemini.
includeUsageNoSet to true to append token usage and timing metrics to the response. Ignored when jsonSchema is set, so the body stays valid JSON.
chunkCacheKeyNoThe 8-hex-character cache key a multi-chunk changeMode response reported, to fetch a later chunk without re-running the analysis.
conversationIdNoOptional conversation ID to resume a previous session. A plain-text reply reports the ID of the conversation it created or continued; a jsonSchema or changeMode reply does not, because its body is parsed.
skipPermissionsNoSet to true to run agy with --dangerously-skip-permissions. This genuinely changes behaviour: since agy 1.1.5 headless runs honour the persisted permission settings, so without it a tool call the settings do not allow is refused with nobody there to approve it.
allowSlashCommandsNoSet to true to let a prompt starting with '/' expand as an agy command or skill (e.g. '/usage', '/skills'), which answers for free without a model turn. Default false: the prompt goes to the model verbatim.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses several beyond-schema behaviors: file inclusion via @path, conversation continuation, response-ID reporting caveats in plain-text vs jsonSchema/changeMode, agy backend's sandbox limitations, and skipPermissions behavior. Some details live in the schema, but the description adds A plain-text reply vs parsed-body distinction and the basic file-inclusion mechanism.

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 sentences: core action, feature highlights, and sibling routing. Front-loaded with what the tool does, no filler, and the routing closes the description. Every sentence earns its place; it stays compact despite handling a complex 15-parameter tool.

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?

Richly covers a complex general-purpose tool: what it returns, how to reference files, how to continue threads, and when to use siblings. There is no output schema to document return values, but the description's core promise ('get the answer back') plus the conversationId/plain-text caveat suffice. No essential calling context is missing.

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 description coverage is 100%, so the schema documents every parameter, making the baseline 3. The description adds meaning above that by encoding the @path file-inclusion convention directly ('Reference project files with @path to send their contents along') and by grouping the conversational state (conversationId to continue a thread). It also gives a quick semantic to mode via 'accept-edits' and 'plan' examples in the schema; the prose adds the general mental model, which lifts it slightly 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?

Description leads with a clear verb+resource ('Send one prompt to Google Gemini... and get the answer back'), and enumerates concrete uses: questions, code review, analysis, edits, structured JSON. It also distinguishes itself from gemini-plan and gemini-brainstorm by name, which is enough to tell it apart from siblings.

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?

Explicitly says when to use this tool vs alternatives: 'For a phased implementation blueprint use gemini-plan; for idea generation use gemini-brainstorm; for everything else use this.' That is direct when/when-not routing. Thread-continuation guidance (conversationId) is also included.

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