Skip to main content
Glama
hampsterx

gemini-mcp-bridge

by hampsterx
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

gemini-mcp-bridge

Deprecated and unmaintained

Google is retiring Gemini CLI on June 18, 2026 in favor of Antigravity CLI. After that date, Gemini CLI stops serving requests for Google AI Pro, Ultra, and free tier accounts (Gemini Code Assist for individuals). Enterprise customers on paid Gemini Code Assist Standard/Enterprise licenses retain access.

Because this bridge wraps Gemini CLI as a subprocess, it stops working for individual users on the same date. This repository is archived and the npm package is deprecated. No further releases are planned.

Migration options:

Existing installs continue to function until June 18, 2026. The historical README follows.

npm version npm downloads CI License: MIT Node.js TypeScript MCP

MCP server that wraps Gemini CLI as a subprocess, exposing its capabilities as Model Context Protocol tools.

Works with any MCP client: Claude Code, Codex CLI, Cursor, Windsurf, VS Code, or any tool that speaks MCP.

Related MCP server: Vertex AI MCP Server

Do you need this?

If you're in a terminal agent (Claude Code, Codex CLI) with shell access, call Gemini CLI directly:

# File context query
gemini -p "Explain how this auth flow works" -- @src/auth.ts @src/session.ts

# Quick question
gemini -p "Is this approach sound for handling retries?"

# Web search
gemini -p --yolo "What's the latest stable Node.js LTS?"

Tips: --yolo is needed for agentic file access in headless mode (without it, tool calls block). Use -m gemini-2.5-pro to skip the CLI's internal model routing (~1-2s). Cold start is ~16s per invocation. For code review, see Code review with this CLI below.

Use this MCP bridge instead when:

  • Your client has no shell access (Cursor, Windsurf, Claude Desktop, VS Code)

  • You need structured output with JSON Schema validation (Gemini CLI has no custom schema support)

  • You need concurrency management (max 3 parallel spawns, FIFO queue, optional pacing/jitter between CLI starts)

  • You need partial response capture on timeout (NDJSON streaming) and automatic model fallback on quota errors

  • You need response length controls (maxResponseLength parameter)

  • You need oversized query/search responses paginated safely instead of getting truncated by MCP client limits (structured is intentionally not chunked, preserves machine-consumable JSON)

  • You want subprocess isolation: env allowlist, path sandboxing, no shell escape

Quick Start

npx gemini-mcp-bridge

Prerequisites

  • Gemini CLI installed (npm i -g @google/gemini-cli)

  • Authenticated (gemini auth login)

Claude Code

claude mcp add gemini -s user -- npx -y gemini-mcp-bridge

Codex CLI

Add to ~/.codex/config.json:

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

Cursor / Windsurf / VS Code

Add to your MCP settings:

{
  "gemini": {
    "command": "npx",
    "args": ["-y", "gemini-mcp-bridge"]
  }
}

Tools

Tool

Description

query

Agentic prompt with optional file context. Gemini runs inside your repo with read/grep/glob tools. Supports text and images.

search

Google Search grounded query. Gemini searches the web and synthesizes an answer with source URLs.

structured

JSON Schema validated output via Ajv. Data extraction, classification, or any task needing machine-parseable output.

ping

Health check. Verifies CLI is installed and authenticated, reports versions and capabilities.

fetch-chunk

Retrieve later segments from a chunked query or search response using its cacheKey.

query

Send a prompt with optional file paths as hints. Gemini reads the files itself and can explore surrounding code for context. Text queries run under --approval-mode plan (read-only agentic). Image queries use --yolo for native pixel access.

Key parameters: prompt (required), files (text or images), model, workingDirectory, timeout (default 120s, max 1800s), changeMode (see below).

Change mode: set changeMode: true to ask Gemini to emit structured **FILE: <path>:<start>-<end>** / ===OLD=== / ===NEW=== edit blocks instead of prose. The raw response stays in response (chunked normally); parsed edits are returned on _meta.edits as a machine-applicable array and are never chunked. A pre/post-spawn git snapshot detects any file writes Gemini might attempt, if writes are found, _meta.appliedWrites is set to true and edits is omitted so callers can't re-apply half-applied state. Text-only for v1; requires a git workingDirectory. Plan mode refuses to emit edit blocks (verified on CLI 0.38.0), so change mode runs in default agentic mode with the snapshot guardrail as the safety net.

search

Google Search grounded query. Spawns Gemini CLI in agentic mode with google_web_search, then synthesizes an answer with source URLs.

Key parameters: query (required), model, workingDirectory, timeout.

Large query and search responses are automatically chunked when they exceed the bridge threshold. The first chunk includes a cacheKey and chunk count in _meta and the response footer. Use fetch-chunk with that cacheKey and a 1-based chunkIndex to retrieve later segments within the 10-minute in-memory cache window. structured responses are intentionally not chunked (preserves machine-consumable JSON output).

structured

Generate JSON conforming to a provided schema. Schema is embedded in the prompt, response validated with Ajv. Returns isError: true with validation details on failure.

Key parameters: prompt (required), schema (required, JSON string), files, model, workingDirectory, timeout.

ping

No parameters. Returns CLI version, auth status, and server info.

All tools attach execution metadata (_meta) with durationMs, model, and partial (timeout indicator). See DESIGN.md for details.

Code review with this CLI

The review and assess tools were removed in v0.7.0 (see ADR-001). The gemini ecosystem already ships several review surfaces, listed here in priority order:

  1. Official gemini-cli-extensions/code-review extension (repo). Adds /code-review and /pr-code-review slash commands to the CLI.

  2. Skills (/skills, .gemini/skills/code-reviewer/SKILL.md). Project- or user-scoped review prompts, invokable as slash commands.

  3. Subagents (.gemini/agents/, ~/.gemini/agents/). Specialized reviewer personas the CLI can delegate to.

  4. Gemini Code Assist GitHub app. Inline review on pull requests.

  5. Direct gemini -p with hardened isolation flags. Pipe the diff via stdin (using $(git diff ...) as positional args expands the diff into shell tokens):

    git diff origin/main...HEAD | gemini --approval-mode plan \
  -e "" \
  --allowed-mcp-server-names "" \
  -p "Review the diff on stdin for bugs, missing tests, and unhandled errors"

    --approval-mode plan is read-only agentic. -e "" disables loaded extensions for this run. --allowed-mcp-server-names "" blocks bundled MCP servers. Default text output is preferred over --output-format json for human-readable review notes.

  6. Third-party MCP servers if you specifically need an MCP-shaped review tool (e.g. nicobailon/gemini-code-review-mcp).

Configuration

Variable

Default

Description

GEMINI_DEFAULT_MODEL

(CLI default)

Default model for all tools

GEMINI_FALLBACK_MODEL

gemini-2.5-flash

Fallback on quota/rate-limit errors (none to disable)

GEMINI_CLI_PATH

gemini

Path to CLI binary

GEMINI_MAX_CONCURRENT

3

Max concurrent subprocess spawns

GEMINI_MIN_INVOCATION_GAP_MS

5000

Minimum gap between Gemini CLI start times

GEMINI_SPAWN_JITTER_MAX_MS

200

Random extra delay before spawn to avoid deterministic timing

Prompt templates for the search, structured, and query change-mode tools live in prompts/. Editable when running from a local clone; bundled when running via npx.

Choosing a Gemini MCP server

You need...

Consider

Schema-validated structured output, concurrency management, response chunking

This bridge

Shell command generation, Google Workspace integration

@tuannvm/gemini-mcp-server

Lightweight large-context codebase analysis

gemini-mcp-tool

No CLI dependency (API-only, broadest feature set)

@rlabs-inc/gemini-mcp

Simple API wrapper with broad client support

mcp-server-gemini

Performance

Each invocation spawns a fresh CLI process with ~15-20s cold start (large dependency tree, sync auth checks). No daemon mode yet (tracking; PR in progress).

Scenario

Typical time

Minimal query

17-25s

File-context query (small repo)

30-60s

Web search + synthesis

35-60s

Structured output (small schema)

25-45s

Setting GEMINI_DEFAULT_MODEL avoids the CLI's internal model routing step (~1-2s savings per call).

Bridge family

Three MCP servers, same architecture, different underlying CLIs. Each wraps a terminal agent as a subprocess and exposes it as MCP tools. Pick the one that matches your model provider, or run multiple for cross-model workflows.

gemini-mcp-bridge

claude-mcp-bridge

codex-mcp-bridge

CLI

Gemini CLI

Claude Code

Codex CLI

Provider

Google

Anthropic

OpenAI

Tools

query, structured, search, fetch-chunk, ping

query, structured, search, ping, listSessions

codex, query, structured, search, ping, listSessions

Code review

Use the gemini ecosystem: code-review extension, skills, subagents, Code Assist, or gemini -p

Use Claude Code built-ins (/review, /security-review, /ultrareview) or claude -p

Use codex review --base <ref> (native CLI subcommand)

Structured output

Ajv validation

Native --json-schema

Ajv validation

Session resume

Not supported

Native --resume

Session IDs with multi-turn

Budget caps

Not supported

Native --max-budget-usd

Not supported

Effort control

Not supported

--effort low/medium/high/max

reasoningEffort (low/medium/high)

Cold start

~16s

~1-2s

<100ms (inference dominates)

Auth

gemini auth login

claude login (subscription) or ANTHROPIC_API_KEY

OPENAI_API_KEY

Cost

Free tier available

Subscription (included) or API credits

Pay-per-token

Concurrency

3 (configurable)

3 (configurable)

3 (configurable)

Model fallback

Auto-retry with fallback model

Auto-retry with fallback model

Auto-retry with fallback model

All three share: subprocess env isolation, path sandboxing, FIFO concurrency queue, MCP tool annotations, _meta response metadata, progress heartbeats. The codex and claude bridges also perform output redaction (secret stripping).

Development

npm install
npm run build        # Compile TypeScript
npm run dev          # Watch mode
npm test             # Run tests
npm run lint         # ESLint
npm run typecheck    # tsc --noEmit

Further reading

  • DESIGN.md - Architecture, output streaming, concurrency, response metadata, prompt templates

  • SECURITY.md - Environment isolation, path sandboxing, agentic mode caveats, resource limits

  • CHANGELOG.md - Release history

License

MIT

Available Tools

5 tools
fetch-chunkA
Read-onlyIdempotent

Retrieve a cached chunk from a previously chunked response. Large query and search responses may return only the first chunk plus a cacheKey. Use this tool with that cacheKey and a 1-based chunkIndex to fetch the remaining segments before the 10-minute in-memory cache expires.

ParametersJSON Schema
NameRequiredDescriptionDefault
cacheKeyYesCache key returned in the initial chunked response.
chunkIndexYes1-based chunk index to retrieve. Use 2 for the next segment after the initial response.
workingDirectoryNoUnused for now. Accepted for tool contract consistency with the other bridge tools.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive. The description adds valuable context: the 10-minute in-memory cache expiry, which is a critical behavioral constraint. It also clarifies that large responses may return only the first chunk plus a cacheKey, explaining the tool's place in the interaction flow. No contradiction with annotations.

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 that front-load the core purpose, then provide context and usage. Every word earns its place; no fluff or redundancy. Perfectly sized for the task.

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 the tool's simplicity, the description fully covers what an agent needs: what it does, when to use it (with a cacheKey), how to use it (1-based chunkIndex), and the expiry constraint. No output schema exists, but the return value is implied to be the next chunk, which is acceptable for this tool.

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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning: it explains that cacheKey comes from the initial chunked response and that chunkIndex is 1-based with 2 as the next segment, which slightly reinforces the schema. However, it does not substantially go beyond the schema descriptions.

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 with a specific verb ('Retrieve') and resource ('a cached chunk from a previously chunked response'). It distinguishes itself from sibling tools (ping, query, search, structured) by being the follow-up mechanism for fetching remaining chunks, which is explicit and unambiguous.

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 explicit usage context: use when a large query/search response returns a cacheKey and you need subsequent segments before the 10-minute expiry. It could be stronger by explicitly stating not to use without a cacheKey, but the scenario is clear and self-contained.

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

pingA
Read-onlyIdempotent

Health check. Verifies gemini CLI is installed and authenticated, reports CLI version, auth status, configured models, and server version. Fast (~1s, no model call).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it is fast (~1s) and makes no model call. No contradictions with annotations.

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 highly concise, starting with 'Health check.' and providing key details in two sentences. Every sentence adds value without fluff.

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 the tool's simplicity (no parameters, no output schema), the description is complete: it states the purpose, what it verifies, what it reports (CLI version, auth status, models, server version), and performance characteristics. Nothing missing for an agent to use it effectively.

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 empty. The description does not need to explain parameters; the baseline for zero-parameter tools is 4, and no additional information is necessary.

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 identifies the tool as a health check that verifies CLI installation and authentication, and reports version/status details. This distinguishes it from sibling tools like query and search, which are data-retrieval operations.

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 the tool is for health verification (e.g., before other operations) but does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. Context is clear but usage guidance is implied rather than explicit.

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

queryA

Agentic query: Gemini runs inside your workingDirectory with read_file, grep, list_directory, and glob tools. Pass file paths as hints (not content) — Gemini reads them itself and can explore surrounding code for context.

Capabilities:

  • Code analysis with full repo exploration (Gemini follows imports, reads tests, checks related files)

  • Image understanding: screenshots, diagrams, architecture charts (png/jpg/gif/webp/bmp)

  • General knowledge questions and technical research

  • Text transformation, summarization, and generation

  • Change mode: structured edit blocks parsed into a machine-applicable edits array (see 'changeMode' below)

File handling: Pass file paths in the 'files' array as hints. Text files are referenced via @{path} — Gemini reads them with its own tools. Image files use --yolo mode for native pixel access. Gemini may also read files beyond the ones you hint at.

Note: Gitignored files cannot be read in text-query mode (plan mode restriction). Image queries (--yolo) can read gitignored files.

Change mode: set 'changeMode: true' to ask Gemini to emit structured **FILE: <path>:<start>-<end>** / ===OLD=== / ===NEW=== blocks instead of prose. The response text stays in response; parsed edits are returned on _meta.edits and never chunked. The tool runs in default agentic mode (NOT plan mode, which refuses to emit edit blocks) with a pre/post-spawn git snapshot that detects any file writes Gemini might attempt. If writes are detected the tool returns _meta.appliedWrites: true and omits edits for safety. Text-only (image files rejected). Requires a git working directory.

Model tips: Use gemini-2.5-flash for speed, gemini-2.5-pro for depth and complex reasoning. If omitted, the CLI auto-selects via its routing model.

Each invocation spawns a fresh CLI process (~15-20s startup overhead). Plan timeouts accordingly.

ParametersJSON Schema
NameRequiredDescriptionDefault
filesNoFile paths relative to workingDirectory, passed as hints. Gemini reads them with its own tools — contents are NOT inlined. Image files (png, jpg, jpeg, gif, webp, bmp) trigger --yolo mode. Max 20 files, 1MB per text file, 5MB per image.
modelNoGemini model override. Options: gemini-2.5-flash (fast), gemini-2.5-pro (deep). Omit to let CLI auto-route.
promptYesThe prompt to send to Gemini
timeoutNoTimeout in milliseconds (default: 120000, max: 1800000). Minimum useful: ~20s due to CLI startup.
changeModeNoWhen true, Gemini emits structured **FILE: path:start-end** / ===OLD=== / ===NEW=== edit blocks. Legacy OLD:/NEW: markers are still parsed for back-compat. Parsed edits are returned on _meta.edits (never chunked). A pre/post-spawn git snapshot enforces that Gemini did not write any files; if writes are detected, _meta.appliedWrites is true and edits are omitted. Text-only, requires a git workingDirectory.
workingDirectoryNoWorking directory for file resolution and project context. The CLI reads GEMINI.md/AGENTS.md from here automatically.
maxResponseLengthNoSoft limit on response length in words (e.g. 500). Reduces oversized responses from Gemini's large context window.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, openWorldHint=true, etc.), the description richly discloses behaviors: fresh CLI spawn per invocation (~15–20s startup), file-hint semantics, read-beyond-hints, gitignore restrictions, pre/post-spawn git snapshot safety, structured edit parsing never chunked, and _meta.appliedWrites detection. No contradictions with annotations.

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?

Although lengthy, the description is logically organized with sections for capabilities, file handling, change mode, model tips, and startup overhead. Each sentence contributes essential information, and key facts are front-loaded. No filler or redundant prose.

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?

For a complex tool with 7 parameters and no output schema, the description covers operational behavior, constraints, prerequisites, and response metadata (e.g., _meta.edits, _meta.appliedWrites). It provides enough detail for an agent to use the tool correctly without requiring additional external knowledge.

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%, but the description adds meaningful context: files are hints not inlined, images trigger --yolo mode, model guidance (flash vs pro), timeout floor due to CLI startup, and changeMode's structured edit safety. This goes beyond the baseline schema descriptions and helps the agent set parameters effectively.

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 identifies this as an agentic query tool where Gemini runs with read_file, grep, list_directory, and glob tools in the workingDirectory. It lists specific capabilities (code analysis, image understanding, general knowledge, text transformation, change mode) that distinguish it from simpler or sibling tools, even without naming them explicitly.

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 explicit use cases and prerequisites: requires a git working directory, text-only in change mode, gitignored files unreadable in text-query mode, and model selection tips (flash for speed, pro for depth). While it doesn't explicitly compare to sibling tools like search or structured, it implies when this agentic tool is appropriate and notes limitations.

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

structuredA
Read-only

Agentic structured output: generate a JSON response conforming to a provided JSON Schema. Gemini runs inside workingDirectory with read_file and grep tools, so it can read files for context. Use for data extraction, classification, or any task needing machine-parseable output. The response is validated against the schema; isError is true if validation fails.

ParametersJSON Schema
NameRequiredDescriptionDefault
filesNoText file paths to reference as context (no images). Gemini reads them with its own tools — contents are NOT inlined. Max 20 files, 1MB each.
modelNoGemini model override. Omit to let CLI auto-route.
promptYesWhat to generate or extract from the provided context
schemaYesJSON Schema as a string. The response will be validated against this. Max 20KB.
timeoutNoTimeout in ms (default: 120000, max: 1800000).
workingDirectoryNoWorking directory for file resolution.

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint true, destructiveHint false), the description discloses the agentic design: Gemini runs inside workingDirectory with read_file and grep tools, and the response is validated against the schema with isError set on failure. This adds significant behavioral context.

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 dense sentences, front-loaded with the core purpose. Each sentence contributes useful information without redundancy—purpose, agentic context, and validation behavior.

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 covers purpose, usage, validation, and behavioral context, making it mostly self-contained. It does not describe return value structure, but with no output schema and strong annotations, this is an acceptable gap for a structured-output tool.

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 baseline is 3. The description adds context about agentic file reading and validation but does not elaborate on parameter formats beyond what the schema already states, so it adds only marginal semantic value.

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 resource: 'generate a JSON response conforming to a provided JSON Schema.' It clearly distinguishes from siblings by targeting structured output for data extraction/classification, leaving no ambiguity about what the tool does.

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?

It explicitly says 'Use for data extraction, classification, or any task needing machine-parseable output,' providing actionable usage guidance. It does not name alternative tools, but the use cases are clear enough to guide an agent.

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.

  1. 5 tool updatesv0.8.0
    • First observedfetch-chunk
    • First observedping
    • First observedquery
    • First observedsearch
    • First observedstructured
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: ping for health, query for agentic code/Q&A, search for web-grounded answers, structured for schema-validated JSON, and fetch-chunk for retrieving large responses. Even query and structured, which both use file access, are differentiated by output format and validation.

Naming Consistency3/5

Names are all lowercase and concise, but they mix verbs (ping, search, fetch-chunk), a noun (query), and an adjective (structured). There is no consistent verb_noun pattern, though the simple style remains readable and not chaotic.

Tool Count5/5

Five tools is well-scoped for a Gemini bridge, covering health checking, general and code-aware querying, web search, structured output, and chunk retrieval. Each tool has a clear role and none feels redundant.

Completeness4/5

The tool set covers core Gemini workflows: health verification, agentic analysis, web research, structured extraction, and large-response handling. Minor gaps exist, such as explicit model management or conversation history, but they are not essential for the server's stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Vertex AI MCP Server

    shariqriazz
    A
    license
    A
    quality
    C
    maintenance
    Implementation of Model Context Protocol (MCP) server that provides tools for accessing Google Cloud's Vertex AI Gemini models, supporting features like web search grounding and direct knowledge answering for coding assistance and general queries.
    20
    30
    88
    MIT

  • Gemini CLI MCP Server

    wminson
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that wraps the Gemini CLI to provide tools for executing prompts, managing chat sessions, and accessing CLI extensions. It supports both local stdio and remote SSE transports for flexible integration with MCP clients.
    1
    -

  • mcp-cli-gemini

    rlaksana
    F
    license
    A
    quality
    D
    maintenance
    Wraps the Gemini CLI as an MCP server, enabling AI tools to perform Gemini queries, interactive sessions, and extension management via a unified tool.
    1
    1
    -

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/hampsterx/gemini-mcp-bridge'

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