geminicli-mcp
The geminicli-mcp server acts as a stateless MCP bridge to the headless Gemini CLI, enabling programmatic interaction with Gemini models through three tools:
gemini_prompt: Send a direct text prompt to a Gemini model and receive a text response.gemini_prompt_with_context: Send a prompt along with a separate context block, automatically prepended inside a<context>tag before the prompt.gemini_prompt_structured: Request a model response conforming to a provided JSON Schema; the server validates and returns canonical JSON, or detailed error diagnostics on failure.
Key characteristics:
Model selection: All tools accept an optional
modelparameter (e.g.,gemini-2.5-pro).Stateless: Each tool call is independent with no sessions or persistent state.
Environment inheritance: The child Gemini CLI process inherits the server's environment, including
GEMINI_API_KEY.Configurable: Binary path via
GEMINI_CLI_BIN, output cap viaGEMINICLI_MCP_MAX_OUTPUT_BYTES, and debug logging viaGEMINICLI_MCP_DEBUG.Error reporting: Surfaces Gemini CLI exit codes with specific codes for auth issues, validation failures, and turn limits.
Security caveat: Hardcodes
--approval-mode yolo, meaning any tool calls or file edits the model requests are auto-approved — only use with trusted MCP clients.
Provides tools to invoke Google's Gemini AI models via the Gemini CLI, enabling prompt-based interactions, context injection, and structured JSON responses.
Click on "Install 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., "@geminicli-mcpsummarize this article about AI safety"
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.
geminicli-mcp
Stateless stdio MCP server wrapping the headless Gemini CLI.
stdio transport, spawn-per-client
three tools:
gemini_prompt,gemini_prompt_with_context,gemini_prompt_structuredno sessions, no
working_dir, no timeout enforcementruns in the server process's
cwdchild env inherits the server's env (so
GEMINI_API_KEYflows through) and pinsNO_COLOR=1,TERM=dumb; prompt is always a single argv element — never interpolated into a shell stringsingle runtime dependency:
@modelcontextprotocol/sdk
Prerequisites
Node.js ≥ 20
@google/gemini-cli ≥ 0.40.0 — this server uses both
--output-format jsonand--skip-trustfor reliable non-interactive execution. JSON output first appeared in 0.6.1 (upstream PR #8119);--skip-trustrequires 0.40.0 or newer.
Related MCP server: gemini-cli-mcp
Install from source
geminicli-mcp is not currently published to npm. Until the first release,
install and link a checkout:
git clone https://github.com/trevoraspencer/geminicli-mcp.git
cd geminicli-mcp
npm ci
npm run build
npm linkThis exposes the locally built geminicli-mcp binary on your PATH. Point
your MCP client at it:
// e.g. ~/.config/<your-client>/mcp.json
{
"mcpServers": {
"gemini": {
"command": "geminicli-mcp"
}
}
}You also need the headless Gemini CLI installed and authenticated:
npm install -g @google/gemini-cli
gemini # one-time interactive authTools
gemini_prompt
field | type | required | notes |
prompt | string | yes | prompt text |
model | string | no | e.g. |
Returns the CLI's response text.
gemini_prompt_with_context
field | type | required | notes |
prompt | string | yes | prompt text |
context | string | yes | prepended to the prompt inside |
model | string | no | e.g. |
Returns the CLI's response text.
gemini_prompt_structured
field | type | required | notes |
prompt | string | yes | prompt text |
schema | object | yes | JSON Schema the response must conform to (see below) |
context | string | no | optional context block prepended inside |
model | string | no | e.g. |
The server appends an explicit "respond with JSON conforming to this schema"
instruction to your prompt, extracts JSON from the model's response (it
tolerates surrounding prose or a ```json fence), and validates the
result against schema. On success the tool returns the canonical JSON
string. On failure the result is isError: true with a diagnostic that
includes both the validation errors and the raw response.
A minimal schema looks like:
{
"type": "object",
"required": ["title", "tags"],
"properties": {
"title": { "type": "string" },
"tags": { "type": "array", "items": { "type": "string" } }
},
"additionalProperties": false
}The bundled validator supports a useful subset of JSON Schema: type (with
all primitive types plus array and object), required, properties,
items, additionalProperties, enum, const, minLength/maxLength,
minItems/maxItems, minimum/maximum, pattern, and the anyOf /
oneOf / allOf combinators. It is deliberately small — if you need full
JSON Schema 2020-12, pre-validate on the caller side. Schema input is limited
to 1 MiB, 10,000 nested schema nodes, and 64 levels of schema nesting.
Potentially super-linear pattern shapes are rejected conservatively before
the model is invoked; patterns containing repetition must be start-anchored.
Individual pattern inputs are limited to 65,536 characters, with a
262,144-character aggregate pattern-evaluation budget per response.
Examples
The examples/ directory contains runnable JSON-RPC request
files you can pipe into the server over stdio. See
examples/README.md for a one-liner that lists tools
or invokes a tool from the command line.
Environment
GEMINI_CLI_BIN— override thegeminibinary path (default:geminionPATH). On Windows this must point at the CLI's JavaScript entry (npm'sgemini.cmd/gemini.ps1shims cannot be spawned without a shell); see the Windows note under Troubleshooting.GEMINICLI_MCP_MAX_OUTPUT_BYTES— cap (per stream) on bytes accumulated from the gemini child's stdout/stderr before the server kills it (default: 33554432 / 32 MiB). The value must be a positive base-10 integer; invalid values use the default. Guards against a runaway child OOM-ing the server.GEMINICLI_MCP_DEBUG— when set to1,true, oryes, emits structured JSON diagnostics to stderr (redacted prompt length, invocation flags, exit codes, durations, output byte counts, and kill-failure markers). Safe for MCP use: diagnostics go to stderr only and never corrupt the stdio protocol on stdout. Leave unset in production; enable only for targeted debugging.Child process env inherits the server's environment, plus forced
NO_COLOR=1/TERM=dumb. Anything the server can read — includingGEMINI_API_KEYand friends — the gemini CLI can read.
Exit codes
The server surfaces the gemini CLI's exit code via the errorKind /
exit= prefix on error responses (e.g. [error exit=1] ...).
code |
| meaning |
|
| success |
|
| general model error or API failure |
|
| gemini CLI is not authenticated; run |
|
| bad arguments (or bad schema, for the structured tool) |
|
| gemini CLI sandbox setup failed |
|
| gemini CLI configuration is invalid |
|
| gemini's turn / tool-call budget was exhausted |
|
| gemini binary not found (set |
|
| the request or gemini CLI was cancelled |
other |
| gemini reported a code outside the documented set |
Security caveats
--approval-mode yoloand--skip-trustare always on. The server hardcodes both flags so it can run non-interactively even when the current workspace has no saved Gemini trust decision. Any workspace configuration, tool calls, or file edits the gemini CLI accepts are trusted or auto-approved. Do not expose this MCP server to MCP clients or workspaces you don't trust.No quota controls. A caller that can reach this server can make unlimited gemini API calls at your expense. Gate access at the MCP-client layer.
Child inherits the server's env. Don't place secrets in the server's env that you don't want the gemini CLI (and its plugins) to see.
Prompts are process arguments. Other users with permission to inspect this process may be able to read prompt and context text from the operating system's process list.
Windows cancellation kills the direct child only. POSIX hosts signal the whole Gemini process group, but Gemini-spawned descendants may outlive a cancelled request on Windows.
Troubleshooting
Unknown arguments: output-format / skip-trust
Your @google/gemini-cli is older than the supported 0.40.0 minimum.
--output-format json was added in 0.6.1
(upstream PR #8119),
and this server also requires the newer --skip-trust flag. Upgrade:
npm install -g @google/gemini-cli@latest
gemini --version # confirm ≥ 0.40.0"Gemini CLI binary not found" (exit 127)
The server could not spawn the gemini executable. Either:
Install the Google headless Gemini CLI (
npm install -g @google/gemini-cli), then verify withwhich gemini && gemini --version; orSet
GEMINI_CLI_BIN=/absolute/path/to/geminiin the server's environment.
If you launch the MCP server from a GUI (Claude Desktop, IDE), it may not
inherit your shell PATH. Either pass an absolute path via GEMINI_CLI_BIN
or configure your MCP client's env block, e.g.:
{
"mcpServers": {
"gemini": {
"command": "geminicli-mcp",
"env": {
"PATH": "/usr/local/bin:/usr/bin",
"GEMINI_CLI_BIN": "/usr/local/bin/gemini"
}
}
}
}Windows: exit 127 even though gemini works in your terminal
On Windows, npm installs the gemini command as a gemini.cmd /
gemini.ps1 shim. The server spawns the child without a shell (by design —
shell-spawning .cmd files is restricted since CVE-2024-27980), so the
default gemini binary name cannot be executed and every call returns the
exit-127 "binary not found" result. On Windows you must point
GEMINI_CLI_BIN at the CLI's JavaScript entry; the server runs
.js/.cjs/.mjs paths with its own Node runtime:
{
"mcpServers": {
"gemini": {
"command": "geminicli-mcp",
"env": {
"GEMINI_CLI_BIN": "C:\\Users\\you\\AppData\\Roaming\\npm\\node_modules\\@google\\gemini-cli\\bundle\\gemini.js"
}
}
}
}Find the right path with npm root -g — the entry point is
<npm root -g>\@google\gemini-cli\bundle\gemini.js.
"Auth not configured" / authentication errors
The Gemini CLI handles its own auth (Google account, API key, or Vertex AI). This server does not touch credentials. Run the CLI directly once to authenticate:
gemini # follow the interactive prompts
echo "ping" | gemini -p "Reply with the single word: ping"If you're using an API key, make sure the relevant env vars (e.g.
GEMINI_API_KEY, GOOGLE_APPLICATION_CREDENTIALS) are present in the MCP
server's env block — children inherit the server's environment but the
server's environment is whatever your MCP client gave it.
"Gemini response did not match schema" (gemini_prompt_structured)
The error text includes both the validation errors and the raw response so you can see what the model produced. Common fixes:
Tighten the prompt so it can't ramble (the server already appends a JSON-only instruction).
Make the schema friendlier — e.g. allow
additionalProperties: truefor fields you don't need to constrain.Pick a stronger model (
model: "gemini-2.5-pro").
Design invariants
These are intentional, not omissions. See
CONTRIBUTING.md for the full list.
Stateless: no session IDs, no
--resume, noworking_dir.Spawn-per-client: one server process per MCP client.
No timeout enforcement in the server — the client and CLI are authoritative.
No shell interpolation.
One runtime dependency (
@modelcontextprotocol/sdk).
License
Available Tools
2 toolsgemini_promptA
Invoke the headless Gemini CLI with a single prompt. Stateless — each call is an independent turn. Runs in the MCP server's current working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt text sent to the Gemini CLI. | |
| model | No | Optional model identifier (e.g., gemini-2.5-pro). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: statelessness, independence of calls, and execution directory. However, it lacks details on permissions, rate limits, error handling, or output format. For a tool with no annotations, this is adequate but leaves gaps in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: three short sentences with zero waste. Each sentence adds value—stating the purpose, behavioral trait (statelessness), and execution context—earning its place efficiently.
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?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally complete. It covers purpose and basic behavior but lacks details on output, errors, or advanced usage. For a stateless CLI tool, this is adequate but not comprehensive.
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 100%, so the schema already documents both parameters ('prompt' and 'model') fully. The description doesn't add any parameter-specific meaning beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Invoke the headless Gemini CLI with a single prompt.' It specifies the verb ('invoke') and resource ('Gemini CLI'), and distinguishes it from the sibling tool by noting it's 'stateless — each call is an independent turn.' However, it doesn't explicitly name the sibling tool for full differentiation.
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 provides clear context for usage: 'Stateless — each call is an independent turn' and 'Runs in the MCP server's current working directory.' This implies when to use it (for independent prompts) and hints at an alternative (the sibling tool likely handles context). However, it doesn't explicitly name the sibling or state when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gemini_prompt_with_contextA
Invoke the headless Gemini CLI with a prompt plus a separate context block. Stateless — each call is an independent turn. The context is prepended to the prompt inside a tag. Runs in the MCP server's current working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt text sent to the Gemini CLI. | |
| context | Yes | Context block prepended to the prompt (e.g., file contents, prior notes). | |
| model | No | Optional model identifier (e.g., gemini-2.5-pro). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: statelessness, context prepending inside a <context> tag, and execution in the MCP server's current working directory. However, it lacks details on permissions, rate limits, error handling, or output format, which are important for a CLI invocation tool with no output schema.
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?
The description is highly concise and well-structured: three sentences that efficiently cover purpose, behavior, and execution context without redundancy. Each sentence adds distinct value, and it's front-loaded with the core functionality.
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?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the basic operation and statelessness but lacks details on output format, error conditions, or model-specific behaviors. Without an output schema, the description should ideally hint at return values or response structure, which it doesn't, leaving gaps for an AI agent.
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 100%, so the schema already documents all three parameters (prompt, context, model) with descriptions. The description adds minimal value beyond the schema, mentioning that context is 'prepended to the prompt inside a <context> tag' and that the tool is stateless, but doesn't provide additional syntax, format, or usage details for the parameters. This meets the baseline of 3 for high schema coverage.
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?
The description clearly states the tool's purpose: 'Invoke the headless Gemini CLI with a prompt plus a separate context block.' It specifies the verb ('invoke'), resource ('Gemini CLI'), and distinguishes it from the sibling tool 'gemini_prompt' by mentioning the separate context block. However, it doesn't explicitly name the sibling for differentiation, keeping it at 4 rather than 5.
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 provides some usage context: 'Stateless — each call is an independent turn' and 'Runs in the MCP server's current working directory.' It implies when to use this tool (for prompts with separate context blocks) but doesn't explicitly state when to use it versus the sibling 'gemini_prompt' or other alternatives, nor does it provide exclusions or prerequisites.
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.
2 tool updates
v0.1.0- First observed
gemini_prompt - First observed
gemini_prompt_with_context
TDQS
The two tools have clearly distinct purposes: one handles simple prompts, while the other adds a separate context block. The descriptions explicitly differentiate them, making misselection unlikely. However, the core functionality is similar, which could cause minor confusion in edge cases.
Both tools follow a consistent 'gemini_prompt' prefix with descriptive suffixes ('with_context'), using snake_case throughout. The naming pattern is predictable and clearly indicates their relationship and differences.
With only 2 tools, the server feels thin for a CLI interface, potentially lacking operations like configuration management, history, or batch processing. While the tools cover basic prompt execution, the scope seems limited compared to typical CLI toolkits.
The server is severely incomplete for a Gemini CLI domain, missing essential operations such as model selection, parameter tuning, file handling, conversation history, or error management. Agents will face dead ends when trying to perform common CLI tasks beyond basic prompting.
Maintenance
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
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
MCP server for AI dialogue using various LLM models via AceDataCloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn 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-
- AlicenseAqualityDmaintenanceA secure MCP server that wraps the Google Gemini CLI, allowing clients to query Gemini models using local OAuth sessions without requiring an API key. It provides tools for model interaction and diagnostics with built-in protection against command injection.2175MIT
- FlicenseAqualityDmaintenanceWraps the Gemini CLI as an MCP server, enabling AI tools to perform Gemini queries, interactive sessions, and extension management via a unified tool.11-
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that wraps the Gemini CLI, enabling AI assistants to send prompts, research topics, analyze code, and summarize content using Gemini.12MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/trevoraspencer/geminicli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server