gemini-mcp-server
Allows MCP clients to send prompts to Google Gemini models via the Gemini API and receive text answers, with configurable primary/fallback models and retry handling for rate limits and outages.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@gemini-mcp-serverask Gemini to review this Python function for bugs and suggest fixes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
gemini-mcp-server
A tiny Model Context Protocol stdio server that gives any MCP
client one tool, gemini_ask, which sends a prompt to Google Gemini and returns the text answer.
It retries with backoff on rate limits and outages, and falls back to another model when one fails.
Why a tiny MCP server?
A second opinion inside your agent. Let one assistant consult another model for cross-checks, reviews or drafts without leaving the workflow.
Small surface, easy to audit. One tool and about 150 lines of logic. The key comes from env, nothing else is exposed, and you can read all of it in a few minutes.
A good MCP learning project. Stdio transport, a typed tool signature and clean error strings are the core of most MCP integrations.
Related MCP server: gemini-mcp
Setup (uv)
git clone <this-repo-url> gemini-mcp-server
cd gemini-mcp-server
uv sync # creates .venv and installs mcp (+ pytest in the dev group)
read -rs GEMINI_API_KEY && export GEMINI_API_KEY # from Google AI Studio
uv run gemini-mcp-server # speaks MCP over stdio; normally your client launches it
uv run pytest -q # all HTTP is mockedConfiguration (environment variables)
Variable | Purpose | Default |
| API key (preferred) | none |
| Path to a file holding the key, used only if | none |
| Primary model |
|
| Comma-separated fallbacks (empty = none) |
|
| Retries per model on 429/500/503/network errors |
|
Error handling: 429/500/503 and network errors are retried with exponential backoff and jitter,
and a Retry-After header is honored. Once retries run out, or on a 404 (unknown model), the next
model in the chain is tried. 400/401/403 (bad request or bad key) fail fast, because a fallback
wouldn't help. Errors come back to the client as a readable Gemini error: ... string instead of a crash.
If a fallback model answers, its reply is prefixed with [answered by <model>].
Add it to an MCP client
Most clients (Claude Desktop, Cursor and others) accept a JSON entry like this:
{
"mcpServers": {
"gemini": {
"command": "uv",
"args": ["--directory", "/path/to/gemini-mcp-server", "run", "gemini-mcp-server"],
"env": { "GEMINI_API_KEY_FILE": "/path/outside/the/repo/gemini.key" }
}
}
}It's better to point GEMINI_API_KEY_FILE at a file with chmod 600 permissions than to paste the key into
client config. Restart the client and the gemini_ask tool will appear.
Free-tier caveats
The Gemini API free tier has low per-minute and per-day request limits that vary by model and change over time, so expect 429s under load. That's why the retry and fallback logic exists.
Free-tier prompts and responses may be used by Google to improve its products. Don't send confidential or personal data.
*-latestaliases can change underneath you. Pin a specific model version if you need reproducibility.Availability, quotas and terms are set by Google. Check the current Gemini API pricing and terms pages before relying on it.
Roadmap
Streaming responses (
streamGenerateContent)Token-usage and latency reporting in tool output
Optional per-process rate limiter to stay under free-tier quotas proactively
Multi-turn context and file/image inputs
Structured (JSON-schema) output mode
How this was built
Built with AI coding assistance as part of my AI-agent operations work. I defined the requirements and error-handling behavior, ran the tests, and reviewed the changes.
License
MIT. See LICENSE.
Available Tools
1 toolgemini_askA
Ask Google Gemini a question and return its text answer.
model: optional model name (default from GEMINI_MODEL or gemini-flash-latest); on rate limits or outages the server retries with backoff, then falls back to GEMINI_FALLBACK_MODELS. system: optional system instruction.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | Yes | ||
| system | No | ||
| max_output_tokens | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does valuable work: it documents default model resolution (GEMINI_MODEL or gemini-flash-latest), retry-with-backoff on rate limits/outages, and fallback to GEMINI_FALLBACK_MODELS. It omits auth/API-key requirements and latency or cost implications, so it is strong but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action in one sentence, then appends compact per-parameter notes. Every sentence adds information, though the run-on model sentence could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format explanation is unnecessary, and the description still notes the text-answer return. It covers defaults and failure behavior, which is the main risk area for an external LLM call; only auth requirements and the token limit remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it explains only 2 of 4 parameters (`model` and `system`). `prompt` is self-evident from its name, but `max_output_tokens` (default 2048) is undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb (ask), resource (Google Gemini), and the return type (its text answer). There are no sibling tools to disambiguate against, and the purpose is unambiguous on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (a question-in/text-answer-out operation) and explains fallback behavior, but gives no explicit when-to-use guidance, prerequisites, or exclusions. With no siblings this is acceptable but thin.
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.
1 tool update
v0.1.0- First observed
gemini_ask
TDQS
Scored across 1 tool
With only a single tool (gemini_ask), there is no possibility of confusing it with another tool. Its purpose—send a prompt to Gemini and return the answer—is unambiguous.
The lone name gemini_ask follows a clean snake_case verb_noun pattern and is fully self-consistent. There are no competing conventions to create inconsistency.
A one-tool surface is thin for a server, even though asking Gemini is genuinely the core capability. The rubric treats a single tool as borderline, and there is no supporting surface (e.g. conversation or model listing).
The basic one-shot question/answer flow is covered, including model and system-instruction options. However, there is no multi-turn conversation, model discovery, or other lifecycle operations, leaving notable gaps for a general Gemini integration.
Maintenance
Related MCP Connectors
Remote MCP for Gemini upgrade evals, prompt regressions, output diffs, and eval receipts.
Account-less MCP access to 45 Gemini models & autonomous agents via L402, x402, and MPP.
Proxy Gemini (Vertex AI) completions wrapped in OpenTelemetry trace spans; returns the answer plus t
Chat, image, video, and audio models from many vendors behind one remote MCP server and one key.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Google Gemini AI models through MCP protocol. Provides text generation capabilities with configurable model selection and temperature settings.62 npmMIT
- AlicenseNot gradedqualityDmaintenanceMinimal MCP server that provides access to Google's Gemini API with Google Search grounding for up-to-date information through a single ask_gemini tool.MIT
- AlicenseAqualityDmaintenanceMCP server that completes prompts with automatic provider fallback across OpenAI, Anthropic Claude, and Google Gemini. It is rate-limit aware, retries on transient failures, and provides a transparent attempt log.210 npmMIT
- AlicenseNot gradedqualityAmaintenanceConnects MCP clients to Gemini Cloud Assist APIs, enabling users to understand, manage, and troubleshoot their Google Cloud environment using natural language.69Apache 2.0