What can you do with this server?

Gemini Relay is a local MCP server that lets your coding agent delegate large-context reading, analysis, planning, image generation, and brainstorming to Google Gemini, returning only concise answers instead of filling the agent's context window. * ask-gemini: Ask questions, review code, or request changes; include files/folders with @, choose model/effort/mode, enforce JSON schema output, resume conversations, get token usage, and receive structured changeMode edits. * gemini-plan: Generate architectural and implementation blueprints, dependency analysis, and risk assessments without modifying code. * gemini-image: Generate images from text descriptions, choose aspect ratios, and save them directly into your project workspace. * brainstorm: Structured ideation using frameworks like SCAMPER or Design Thinking, with constraints, domain context, and feasibility analysis. * gemini-models: List available Gemini models, defaults, reasoning capabilities, and backend status. * gemini-doctor: Diagnose CLI/agy installation, backend, login, version, and remaining quota. * fetch-chunk: Retrieve additional cached chunks from a prior changeMode response. * ping and Help: Verify server connectivity and get the active backend CLI's help.

Which integrations are available for this server?

Enables image generation through Google Imagen with selectable aspect ratios and saving generated assets to the workspace path. Provides access to Google Gemini models via the Antigravity CLI, supporting configurable reasoning effort, planning mode, structured JSON schema outputs, token usage metrics, and workspace context inlining.

gemini-relay

by V-Songbird

Overview Schema Source Related Servers Score Discussions

TypeScript

Local

TL;DR — Your coding agent has a small context window, and reading a big folder fills it. Gemini Relay sends the reading to Google Gemini instead, and hands your agent back a short answer. Ask in plain English. Point at files with @, or let Gemini find them itself.

What is this?

Your agent's context window is the thing you run out of first.

You ask it to review a folder. It opens twenty files, and now most of the window is source code it will never quote. The useful part of the answer is one paragraph, and there is no room left to act on it.

Gemini Relay is a small server that sits beside your agent. Your agent sends it a question, the question goes to Google Gemini, and only the answer comes back. The files never enter your agent's window.

Gemini can read the project on its own, too. Point it at files with @ when you want exactly those. Say nothing and it goes looking.

Related MCP server: MCP Gemini Server

Why you'd want it

A real one, measured on this repo.

package-lock.json here is 181 KB. Reading it into an agent costs roughly 45,000 tokens, and then you still have to count the thing you wanted.

Sent through the relay instead, the whole file went to Gemini and this came back in 19 seconds:

{ "count": 392 }

That is the entire cost to the agent. Nineteen seconds, one line, and the window is still empty for the work.

Install

You need two things: this server, and Google's Antigravity CLI that it drives.

1. Install the CLI and sign in.

curl -fsSL https://antigravity.google/cli/install.sh | bash
agy

Run agy once and it walks you through signing in. On Windows, use the official installer from https://goo.gle/gemini-cli-migration instead of the curl line.

2. Add the server.

Claude Code, one command:

claude mcp add gemini-relay -- npx -y gemini-relay

Claude Desktop, in claude_desktop_config.json:

{
  "mcpServers": {
    "gemini-relay": {
      "command": "npx",
      "args": ["-y", "gemini-relay"]
    }
  }
}

Cursor and Windsurf: add a server named gemini-relay with the command npx -y gemini-relay.

3. Check it. Ask your agent to run gemini-doctor. It reports whether the CLI was found, whether you are signed in, and how much quota is left. It costs nothing to run.

Node 18.19 or newer.

What you can ask for

Talk to your agent normally. These are the shapes that work.

You want to…	Say something like
Review code without filling your window	"Have gemini review `@src/backends` for race conditions."
Look at something too big to open	"Ask gemini what's in `@package-lock.json`."
Let Gemini go find the problem itself	"Ask gemini to find the riskiest code in this repo."
Get a plan before you write anything	"Use gemini-plan to design retry with backoff for the upload queue."
Get a second opinion from another model	"Ask gemini the same question, but with Claude Opus."
Get an answer your code can parse	"Ask gemini for the outdated deps as JSON."
Make a picture	"Use gemini-image for a 16:9 dark hero image, save it to `assets/hero.png`."
Kick ideas around	"Brainstorm ten ways to cut our cold-start time."
See what models you have	"Run gemini-models."
Find out why it broke	"Run gemini-doctor."

@ accepts a file, a folder, @. for the whole project, or a glob like @src/**/*.ts.

Nine tools. Every parameter, every default. A tenth, timeout-test, appears only when GEMINI_MCP_TEST_TOOLS is set.

Tool	Parameter	Type · default	Notes
`ask-gemini`	`prompt`	string, required	Supports `@file`, `@dir`, `@.`, globs.
	`model`	string	Any id `gemini-models` lists, or `flash` / `pro`. Unset sends no `--model`, so agy answers on its own configured model.
	`effort`	`low` \| `medium` \| `high`	Thinking depth.
	`mode`	`plan` \| `accept-edits`	`plan` is read-only.
	`jsonSchema`	object \| string	Enforces structured JSON. Suppresses `includeUsage` and the conversation-id footer so the body stays parseable.
	`addDirs`	string[]	Extra directories agy may see.
	`conversationId`	string	Resume a thread. A plain reply reports the id it created or continued.
	`agent`	string	Run a custom `agent.md` agent.
	`allowSlashCommands`	boolean · `false`	Let a `/`-prefixed prompt reach agy's own command layer (`/usage`, `/skills`, …) — free, no model turn. Such a prompt is delivered on argv, because agy refuses a command under stdin.
	`skipPermissions`	boolean · `false`	`--dangerously-skip-permissions`. Headless runs honour persisted permissions since agy 1.1.5, so without this a disallowed tool call is refused with nobody to approve it.
	`includeUsage`	boolean · `false`	Appends tokens and timing. Ignored with `jsonSchema`.
	`sandbox`	boolean · `false`	Forwarded, but agy does not isolate tool execution headless, and says so in a notice. The legacy `gemini` backend does.
	`changeMode`	boolean · `false`	Gemini emits `FILE: path:line` over a fenced `OLD:` / `NEW:` block; you receive the parsed form — a `[CHANGEMODE OUTPUT …]` header, one `### Edit N` section per edit, and a `fetch-chunk` footer when chunked.
	`chunkIndex`	number \| string	Which chunk (1-based). With `chunkCacheKey` it replays a cached chunk; alone it picks a chunk of a fresh result.
	`chunkCacheKey`	string	Exactly 8 lowercase hex characters, or the call is refused.
`gemini-plan`	`task`	string, required	The thing to plan.
	`context`	string	Constraints, or `@file` references.
	`model`	string · `gemini-3.8-flash-high`	Pinned unless you override it.
	`effort`	`low` \| `medium` \| `high` · `high`
	`addDirs`	string[]
	`includeUsage`	boolean · `true`	Never reports a conversation id.
`gemini-image`	`prompt`	string, required
	`aspectRatio`	enum · `1:1`	`1:1` `16:9` `9:16` `4:3` `3:4` `3:2` `2:3` `5:4` `4:5` `21:9` `4:1` `1:4` `8:1` `1:8`.
	`size`	`512` \| `1K` \| `2K` \| `4K`	Omit to let Gemini pick.
	`outputPath`	string	Relative workspace path. Escaping the root is refused.
`brainstorm`	`prompt`	string, required
	`methodology`	`divergent` \| `convergent` \| `scamper` \| `design-thinking` \| `lateral` \| `auto` · `auto`
	`model`, `effort`, `domain`, `constraints`, `existingContext`	string
	`ideaCount`	integer · `12`
	`includeAnalysis`	boolean · `true`	Never reports a conversation id.
`fetch-chunk`	`cacheKey`, `chunkIndex`	string, number — both required	Both reported by the initial `changeMode` reply.
`gemini-models`	—		Live catalogue from `agy models`, plus backend capabilities.
`gemini-doctor`	—		Binaries, versions, backend, plus login and quota via a free `agy -p "/usage"`.
`ping`	`prompt`	string · `""`	Answered in process. Proves the transport is alive, not the CLI.
`Help`	—		The backend CLI's own `--help`.

One rule for every flag. The relay sends a flag only when the installed agy advertised it in --help. If that probe finds nothing, no flags are sent at all and the run falls back to agy's defaults — an unknown flag makes agy exit non-zero and fails the whole request.

Models. Gemini 3.8 / 3.7 / 3.6 Flash in high, medium and low; Gemini 3.1 Pro in high and low; plus claude-sonnet-4-6, claude-opus-4-6-thinking and gpt-oss-120b-medium, which draw on a separate quota bucket.

What @ actually sends. A file inlines. A folder or @. inlines the text files beneath it. A glob inlines its matches. A token that resolves to nothing is left in the prompt verbatim. During folder and glob expansion node_modules, .git, dist and secret-looking files are skipped — name @.env directly and it is sent. Any file is dropped if it is binary, unreadable, or past the budget of 256 KB per file and 2 MB per prompt; a cut file carries TRUNCATED:, and dropped files are named in OMITTED: and UNREADABLE: footers. Nothing outside the project root is ever read.

Variable	Default	What it does
`GEMINI_MCP_BACKEND`	resolves by date	`agy` / `antigravity`, or `gemini` for the legacy CLI. Unset: `gemini` before 2026-06-18, `agy` from then on.
`AGY_CLI_PATH`	auto-detected	Full path to `agy`. Honoured on every platform.
`GEMINI_CLI_PATH`	auto-detected	Full path to the legacy `gemini`. Windows only.
`GEMINI_MCP_TIMEOUT`	`45`	Wrapper timeout in minutes. Fractions accepted. Read once at load.
`AGY_PRINT_TIMEOUT`	derived	Go duration forwarded to `agy --print-timeout`. Derived as 60 s under the wrapper above a two-minute wrapper, half of it at or below.
`AGY_MCP_PTY`	unset	`1` to recover `agy -p` stdout through a pseudo-terminal. POSIX only, recovery path only, own 10-minute cap.
`GEMINI_MCP_TEST_TOOLS`	unset	Registers the test-only `timeout-test` tool.

Going deeper

Everything technical lives here, so this page can stay short.


Agent guide	Every tool schema, recipes, and how to spend a context window well
How it works	What happens between your question and the answer
Context inlining	What `@` sends, what it skips, and the budgets
Models	The catalogue, reasoning effort, and the quota buckets
Tool reference	Parameters and defaults, in long form
Troubleshooting	The errors you will actually see, and what to do
Antigravity CLI	Why the backend moved, and what the code still guards against

Good to know

Gemini reads your project on its own. Not only what you send with @. It has file, search, web, memory and shell tools, and it uses them in whatever folder the server runs in. mode: "plan" keeps a run read-only.
Headless runs are not sandboxed. Asking for sandbox forwards the flag but does not isolate tool execution on the agy backend, and you get a notice saying so. Your own agy permission settings are what hold.
Secrets are skipped when a folder is expanded, not when you name one. @.env sends the file.
Quota is shared with your other agy use. gemini-doctor shows what is left, free of charge. Claude and GPT-OSS models sit on their own bucket.
Windows finds agy at %LOCALAPPDATA%\agy\bin\agy.exe. If the server cannot see it, set AGY_CLI_PATH to the full path.
Nothing leaves your machine except the prompt. Files are read locally and sent to Google as prompt text, the same as if you had pasted them.

Working on it

npm run doctor    # is the environment sane
npm test          # 150 unit + integration tests
npm run test:e2e  # build, then drive the real CLI
npm run lint      # type-check source and tests
npm run build     # compile to dist/

Support

If this saves you tokens or time, buy me a coffee.

License

MIT — see LICENSE.

Available Tools

9 tools

ask-geminiC

Query Google Gemini (Gemini 3.8 Flash / 3.1 Pro) for analysis, reasoning, architectural planning, and code changes with massive context window.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Agent execution mode: 'plan' for architectural analysis without modifying files, 'accept-edits' for direct edit application.
`model`	No	Gemini model to use (e.g., 'gemini-3.8-flash-high', 'gemini-3.1-pro-high', 'flash', 'pro'). Default: 'gemini-3.8-flash-high'.
`effort`	No	Reasoning effort ('low', 'medium', 'high') for Gemini 3.8 Flash, 3.7 Flash, and 3.1 Pro. Controls depth of thinking tokens.
`prompt`	Yes	Analysis request. Use @ syntax to include files (e.g., '@largefile.js explain what this does') or ask general questions
`addDirs`	No	Optional additional workspace directories to provide context to Gemini.
`sandbox`	No	Use sandbox mode (-s flag) to safely test code changes, execute scripts, or run potentially risky operations in an isolated environment
`changeMode`	No	Enable structured change mode - formats prompts to prevent tool errors and returns structured edit suggestions that Claude can apply directly
`chunkIndex`	No	Which chunk to return (1-based)
`jsonSchema`	No	Optional JSON schema to enforce structured output from Gemini.
`includeUsage`	No	Set to true to append token usage and timing metrics to the response.
`chunkCacheKey`	No	Optional cache key for continuation
`conversationId`	No	Optional conversation ID to resume a previous session.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'code changes,' which hints at mutation, but does not clarify whether the tool applies edits directly, requires approval, or has side effects. There is also no mention of authentication, rate limits, or safety behavior, leaving a significant transparency gap.

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 a single front-loaded sentence with minimal waste. The phrase 'massive context window' is somewhat vague and adds only general marketing value, but the structure is tight and readable.

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

Completeness2/5

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

Despite having 12 parameters, no output schema, and no annotations, the description is only one sentence. It omits critical operational context such as what the response looks like, how mode/changeMode/sandbox affect behavior, when to use it versus sibling tools, and whether 'code changes' means actual file modification.

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%, so the input schema already documents all 12 parameters thoroughly. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Query'), names the resource ('Google Gemini'), and lists concrete use cases: analysis, reasoning, architectural planning, and code changes. However, it does not explicitly differentiate from siblings like gemini-plan or brainstorm, which likely share some of these purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given for when to use ask-gemini versus alternatives. The phrase 'massive context window' implies suitability for large-context tasks, but there are no stated exclusions, prerequisites, or comparisons to sibling tools such as gemini-plan, brainstorm, or gemini-doctor.

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

brainstormA

Generate novel ideas with dynamic context gathering. --> Creative frameworks (SCAMPER, Design Thinking, etc.), domain context integration, idea clustering, feasibility analysis, and iterative refinement.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No	Optional Gemini model to use (e.g., 'gemini-3.8-flash-high', 'gemini-3.1-pro-high'). Defaults to 'gemini-3.8-flash-high'.
`domain`	No	Domain context for specialized brainstorming (e.g., 'software', 'business', 'creative', 'research', 'product', 'marketing')
`effort`	No	Reasoning effort ('low', 'medium', 'high') to control depth of ideation and feasibility analysis.
`prompt`	Yes	Primary brainstorming challenge or question to explore
`ideaCount`	No	Target number of ideas to generate (default: 10-15)
`constraints`	No	Known limitations, requirements, or boundaries (budget, time, technical, legal, etc.)
`methodology`	No	Brainstorming framework: 'divergent' (generate many ideas), 'convergent' (refine existing), 'scamper' (systematic triggers), 'design-thinking' (human-centered), 'lateral' (unexpected connections), 'auto' (AI selects best)	auto
`existingContext`	No	Background information, previous attempts, or current state to build upon
`includeAnalysis`	No	Include feasibility, impact, and implementation analysis for generated ideas

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses a meaningful internal pipeline: dynamic context gathering, domain context integration, idea clustering, feasibility analysis, and iterative refinement. This goes well beyond a vague 'generates ideas' and gives the agent a realistic sense of how the tool behaves, though it does not describe output format or potential state changes.

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 one compact sentence with a clear front-loaded purpose followed by a telegraphic capability list. It wastes few words, though the arrow-plus-list construction is slightly awkward and terms like 'dynamic context gathering' are somewhat vague, keeping it just below a perfect 5.

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

Completeness3/5

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

Given nine parameters, no output schema, and no annotations, the description stays high-level and does not explain what a successful result looks like, when to prefer this over ask-gemini, or how parameters like effort and methodology alter behavior. Schema descriptions compensate for parameter understanding, so this is adequate but not complete.

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%, so the input schema already documents all nine parameters with meanings, defaults, enums, and examples. The tool description itself adds very little parameter-level detail, but because the schema is thorough, the baseline of 3 is appropriate.

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 opens with a specific verb and object, 'Generate novel ideas,' and then reinforces the resource with a distinctive capability list: 'Creative frameworks (SCAMPER, Design Thinking, etc.), domain context integration, idea clustering, feasibility analysis, and iterative refinement.' This clearly separates it from generic siblings like ask-gemini or ping by describing a structured brainstorming workflow rather than a general-purpose query.

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 implies when to use the tool—when the user needs novel ideas or structured brainstorming—but it never explicitly says when not to use it or which sibling alternative to prefer. There are no exclusions or routing cues, so the agent must infer usage from the word 'brainstorm' and the creative-framework references.

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

fetch-chunkA

Retrieves cached chunks from a changeMode response. Use this to get subsequent chunks after receiving a partial changeMode response.

ParametersJSON Schema

Name	Required	Description	Default
`cacheKey`	Yes	The cache key provided in the initial changeMode response
`chunkIndex`	Yes	Which chunk to retrieve (1-based index)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. The word 'Retrieves' signals a read operation, and 'cached chunks' implies a non-destructive lookup from previously stored response data. It does not detail cache expiration or whether chunks can be re-fetched, but the core behavior is clear.

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?

Two short sentences deliver the core behavior and the intended usage context with no wasted words. The primary action is front-loaded and the follow-up guidance is immediately actionable.

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?

The description gives enough context for a simple two-parameter fetch tool: where the cacheKey comes from and when to call it. With no output schema, it could have clarified the response shape or chunk count, but the invocation path is adequately complete.

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%, so the parameters are already well documented. The description adds context about when the cacheKey/chunkIndex are used, but it does not provide substantial extra meaning beyond the schema.

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 states a specific verb and resource: it retrieves cached chunks from a changeMode response. It also clarifies the tool's role as the follow-up mechanism for partial changeMode responses, making its purpose unmistakable.

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 explicitly says to use this tool 'after receiving a partial changeMode response' and positions it as the way to get subsequent chunks. It does not mention exclusions or alternatives, but no directly competing sibling tool is apparent.

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

gemini-doctorA

Diagnose and verify Gemini CLI / Antigravity CLI (agy) installation, active backend, CLI version, and system readiness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It lists what is checked (installation, backend, version, readiness) but does not explicitly state whether the tool is read-only, whether it modifies anything, what output format to expect, or whether it requires any prerequisites. 'Diagnose and verify' strongly implies non-mutating, but this is left implicit.

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?

A single sentence with no filler. The action verb is front-loaded, and every phrase adds a distinct diagnostic aspect: installation, backend, version, and readiness.

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 a zero-parameter diagnostic tool with no output schema and no annotations, the description covers the key dimensions an agent needs to understand its purpose. It does not state what the verification output looks like or how to interpret results, but the low complexity makes that a minor gap.

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?

The tool has zero parameters, so there is no parameter documentation burden. Schema coverage is trivially complete, and the description does not need to explain parameters that do not exist.

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 uses specific verbs ('diagnose', 'verify') and names exact resources: Gemini CLI / Antigravity CLI (agy) installation, active backend, CLI version, and system readiness. This clearly distinguishes it from sibling tools like ask-gemini or gemini-image, which are content-generation tools.

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 diagnostic scope clearly implies use when checking environment health or CLI readiness, which is distinct from the content-generation siblings. However, it does not explicitly state when not to use it or name alternative tools for similar checks.

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

gemini-imageA

Generate images using Google Gemini & Imagen directly from text descriptions. Supports aspect ratio selection and optional export directly into your project workspace.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Detailed visual description of the image to create (subject, environment, lighting, artistic style, colors).
`outputPath`	No	Optional relative file path in your project workspace where the generated image file should be copied (e.g., 'assets/hero.jpg').
`aspectRatio`	No	Aspect ratio of the generated image (default: '1:1').	1:1

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden of behavioral disclosure. It does disclose the optional side effect of exporting the file into the project workspace, but it does not explain what happens when outputPath is omitted, whether files are overwritten, or how the generated image is returned to the agent.

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 a single, front-loaded sentence with no filler. It states the core purpose first, then the key capabilities, making it easy for an agent to parse quickly.

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

Completeness3/5

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

For a tool with only one required and two optional parameters, the schema plus description cover the basics needed to make a call. However, with no output schema and no annotations, the description does not clarify what the agent should expect as a return value or what occurs when no outputPath is provided, leaving a moderate completeness gap.

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%, so the schema already provides full parameter documentation. The description mentions aspect ratio and workspace export at a high level but adds no meaning beyond what the schema already defines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Generate images'), the tool/provider ('Google Gemini & Imagen'), and the input ('text descriptions'). This strongly signals image generation and distinguishes it from the text/planning/model sibling tools, though it does not explicitly name an alternative tool.

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 clear context: use this tool when you need to create an image from a text prompt. It does not explicitly list when not to use it or point to alternatives, but the purpose is obvious enough that an agent can infer appropriate usage.

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

gemini-modelsA

Lists available Gemini models, default selections, reasoning capabilities, and active backend status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/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 the full burden. The verb 'Lists' signals a read-only operation, and 'active backend status' discloses that it queries live backend state. It does not mention rate limits or authentication, but for a zero-parameter discovery tool these are low-risk omissions.

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 a single efficient sentence that fronts the core action ('Lists available Gemini models') and then packs the important output dimensions into a compact list. Every phrase adds information without repetition or filler.

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 a simple no-parameter, no-output-schema tool, the description covers what the tool returns: models, defaults, reasoning capabilities, and backend status. It could add a bit more about output format or how status is represented, but nothing essential is missing for invoking it 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?

The tool has zero parameters and the schema is an empty object with 100% coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 for no-parameter tools is appropriate.

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 uses a specific verb ('Lists') and identifies a distinct resource ('available Gemini models'), then enumerates the exact content categories returned: default selections, reasoning capabilities, and active backend status. This clearly separates it from action-oriented siblings like ask-gemini, gemini-plan, and gemini-image.

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 makes the use context clear: an agent should call this when it needs to know which Gemini models are available, which are defaults, what reasoning capabilities exist, or whether the backend is active. It does not explicitly name alternatives or exclusions, but no sibling tool appears to cover model discovery, so the context is sufficient.

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

gemini-planA

Architectural and implementation planner powered by Gemini's deep reasoning. Generates structured, phased implementation blueprints, dependency analysis, and risk assessments without modifying code.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	The architectural task, complex feature, or refactoring goal to plan out.
`model`	No	Gemini model to use (default: 'gemini-3.8-flash-high' or 'gemini-3.1-pro-high').
`effort`	No	Reasoning effort level (default: 'high'). Allocates deep thinking tokens for comprehensive plan design.	high
`addDirs`	No	Additional directories to add to workspace context.
`context`	No	Additional context, constraints, or reference files (supports @file syntax).
`includeUsage`	No	Include token metrics in the response.

TDQS

A4.4/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 the burden. It clearly states the tool generates blueprints, dependency analysis, and risk assessments without modifying code, which sets accurate expectations. It doesn't disclose response format details, but for a planner tool this is reasonable.

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?

Two sentences with zero waste. Front-loaded with the tool's identity and purpose, then a clear boundary statement. The word count is appropriate for the tool's complexity.

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 a planner tool with a fully documented schema and no side effects, the description is complete enough. It lacks explicit return format or output examples, but given the absence of an output schema and the role of a planner, the description covers the essential context.

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 already documents all 6 parameters. The description adds meaningful context about 'without modifying code' and 'reasoning effort' semantics via the description text, going slightly beyond the schema's structural definitions.

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 states a specific verb ('planner'), resource ('Architectural and implementation planner'), and explicitly distinguishes itself from code modification ('without modifying code'). This clearly differentiates it from siblings like ask-gemini, brainstorm, and gemini-doctor.

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 implies usage for architectural tasks, complex features, or refactoring goals via the parameter schema, and the 'without modifying code' phrase signals when not to use it. It doesn't explicitly name alternatives, but the sibling list and planner framing provide enough context.

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

HelpA

Receive CLI help information for the active Gemini backend

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It conveys that the tool returns help information and hints at being a read-only operation, but it does not disclose output format, potential side effects, or what 'active backend' entails. This is acceptable for a simple help tool but not rich.

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?

A single, compact sentence with no filler. It front-loads the core message and every word contributes to understanding the tool's purpose.

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 a zero-parameter, no-output-schema help tool, the description is sufficiently complete. It tells the agent what the tool does and its scope, though it could optionally mention that no arguments are required or expected.

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?

There are zero parameters and the schema is empty, so the baseline is 4. The description adds meaningful context by indicating the help is scoped to the active backend, which is all that is needed given no parameters exist.

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 states a specific verb ('Receive') and a concrete resource ('CLI help information'), scoped to the 'active Gemini backend'. This clearly distinguishes it from the sibling tools, which perform other actions like asking questions or planning.

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 phrase 'for the active Gemini backend' implies the tool is used when the agent needs CLI help related to the currently selected backend. However, it does not explicitly mention when to prefer this over alternatives or any exclusions, leaving the usage context mostly inferred.

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

pingC

Echo

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	No	Message to echo

TDQS

C2.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Echo' only restates the core action and implies the prompt is returned, but it does not state side effects, safety traits, or response format. For a trivial tool this is minimally acceptable, but it still lacks explicit behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is extremely concise, it is under-specified rather than efficiently structured. A single word without context is not a well-formed definition, and the conciseness is the result of omission rather than careful pruning.

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

Completeness2/5

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

Despite the tool's low complexity, the description leaves out important context such as the intended use (e.g., connectivity test or echo of user input) and the fact that the given prompt will be returned. There is no output schema, so the description should clarify return behavior, but it does not.

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 input schema already has 100% coverage with the description 'Message to echo' for the prompt parameter. The description 'Echo' adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a single word, 'Echo', which names an action but does not specify the resource or what is echoed. It is not a complete statement of purpose and leaves ambiguity about whether it echoes the prompt parameter or something else. This is more like a vague fragment than a clear tool definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus any of the sibling tools. There is no mention of typical use cases, prerequisites, or exclusions. An agent receives no context to decide whether to call ping instead of ask-gemini or brainstorm.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv1.2.0Sep 5, 2026
- First observedask-gemini
- First observedbrainstorm
- First observedfetch-chunk
- First observedgemini-doctor
- First observedgemini-image
- First observedgemini-models
- First observedgemini-plan
- First observedHelp
- First observedping

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation3/5

Several tools have overlapping cognitive territory: ask-gemini and gemini-plan both cover architectural planning, and brainstorm overlaps with ask-gemini for ideation. ping, Help, and fetch-chunk are distinct, but the boundaries between the analysis/planning/creative tools are not fully crisp.

Naming Consistency2/5

Naming is mixed: there is a gemini-* prefix pattern for four tools, but ask-gemini, brainstorm, fetch-chunk, ping, and Help all follow different conventions. Capitalized Help and verb-only brainstorm/ping/fetch-chunk break any coherent naming scheme.

Tool Count4/5

Nine tools is a reasonable count for a multi-purpose Gemini relay covering querying, planning, image generation, diagnostics, and utility operations. It is not bloated, though a couple of utility tools like ping and Help feel peripheral to the main creative/analytical purpose.

Completeness3/5

The surface covers core Gemini interactions: querying, planning, image generation, model discovery, diagnostics, and help. However, there are notable gaps such as no explicit conversation/history management and no clear cancellation or progress control for long-running changeMode workflows that fetch-chunk implies.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
toolweaveOAuth
io.github.andreysparish
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
App Automation AI & Machine Learning Agent Orchestration
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

Gemini MCP Server
Agent Orchestration Code Execution
aliargun
A
license
A
quality
F
maintenance
Model Context Protocol (MCP) server implementation that enables Claude Desktop to interact with Google's Gemini AI models.
Updated a year ago (2025-07-14 18:52 UTC)
6
81
258
MIT
MCP Gemini Server
Search Text Summarization RAG Systems
amitsh06
F
license
Not graded
quality
D
maintenance
A server implementing the Model Context Protocol that enables AI assistants like Claude to interact with Google's Gemini API for text generation, text analysis, and chat conversations.
Updated a year ago (2025-03-17 06:27 UTC)
-
Gemini MCP Server
Autonomous Agents Agent Orchestration
ParsaSarcheshmeh
-
license
Not graded
quality
Not graded
maintenance
An MCP server implementation that allows using Google's Gemini AI models (specifically Gemini 1.5 Pro) through Claude or other MCP clients via the Model Context Protocol.
Updated a year ago (2025-03-25 23:52 UTC)
1
-
Gemini Thinking MCP Server
Agent Orchestration Coding Agents
falahgs
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server implementation for the Google Gemini language model. This server allows Claude Desktop users to access the powerful reasoning capabilities of Gemini-2.0-flash-thinking-exp-01-21 model.
Updated a year ago (2025-04-11 07:50 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/V-Songbird/gemini-relay'

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