Allows interaction with Google's Gemini CLI, providing tools for one-shot queries, interactive sessions, and extension management.
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., "@mcp-cli-gemini Explain how async/await works in JavaScript"
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.
MCP server that wraps Gemini CLI for use with other AI tools via the Model Context Protocol.
Single unified gemini tool that supports:
One-shot queries to Gemini CLI
Interactive mode session commands
Extension management
Related MCP server: Gemini CLI MCP/OpenAI Bridge
Gemini CLI installed and configured
Node.js 18+
npm install
npm run buildEdit your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the server:
{
"mcpServers": {
"gemini-cli": {
"command": "node",
"args": ["D:\\WORKSPACE\\tools-node\\mcp-cli-gemini\\dist\\index.js"]
}
}
}Use stdio transport with:
node dist/index.jsUnified tool for all Gemini CLI operations.
Parameters:
query (required): Query to send to Gemini CLI
model (optional): Model to use (e.g., "gemini-pro", "gemini-1.5-flash")
sandbox (optional): Run in sandbox mode for code execution
yolo (optional): Auto-approve all actions
interactive (optional): Run in interactive mode (returns command for manual execution)
extensions (optional): Extension command: "list" or "info:extensionName"
Examples:
Basic query:
{
"query": "Explain how async/await works in JavaScript",
"model": "gemini-1.5-flash"
}Interactive mode:
{
"query": "Let's discuss design patterns",
"interactive": true
}List extensions:
{
"query": "",
"extensions": "list"
}Get extension info:
{
"query": "",
"extensions": "info:extension-name"
}# Install dependencies
npm install
# Run in development mode
npm run dev
# Build
npm run build
# Watch mode
npm run watch
# Lint
npm run lint
# Lint and fix
npm run lint:fixMIT
Execute Gemini CLI commands. Supports queries, interactive mode, and extension management.
| Name | Required | Description | Default |
|---|---|---|---|
| yolo | No | Auto-approve all actions (YOLO mode) | |
| model | No | Model to use (e.g., gemini-pro, gemini-1.5-flash) | |
| query | Yes | Query to send to Gemini CLI (or extension command when using extensions) | |
| sandbox | No | Run in sandbox mode for code execution | |
| extensions | No | Extension command: 'list' or 'info:extensionName' | |
| interactive | No | Run in interactive mode (returns command for manual execution) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only lists capabilities without addressing side effects, safety, or operational nuances. The schema hints at behaviors like yolo mode (auto-approve), sandbox, and interactive mode, but the description itself does not mention these or any potential risks, making it inadequate for a command-execution tool.
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 exceptionally concise, consisting of two short sentences that immediately state the core action and enumerate supported modes. There is no redundancy or fluff, and the most critical information is front-loaded.
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?
Despite having six parameters and no output schema, the description provides only a high-level summary of capabilities. It does not explain how the modes interrelate, what the tool returns, or any execution details, leaving the agent to rely entirely on the schema for context. This is insufficient for a tool of this complexity.
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 each parameter is already well-defined in the input schema. The tool description adds no additional meaning beyond the schema, which is acceptable per the baseline; it neither enhances nor detracts from parameter understanding.
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 'Execute Gemini CLI commands' with a specific verb and resource, and further enumerates the tool's main capabilities: queries, interactive mode, and extension management. This fully clarifies the tool's purpose and differentiates it from potential siblings (though none are present).
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 on the tool's intended use cases by listing the three supported modes (queries, interactive mode, extension management). While it does not explicitly state when not to use this tool or name alternatives, the absence of siblings and the explicit enumeration offer sufficient guidance for an agent to determine applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0geminiWith only one tool, there is no risk of confusing it with another. The tool's purpose is clearly stated, so an agent can unambiguously select it.
The single tool name 'gemini' is simple, matches the server name, and follows a consistent pattern. With only one name, there are no inconsistencies to penalize.
Exposing only one tool is too few for the apparent scope, as it tries to cover queries, interactive mode, and extension management all in one. This forces the agent to rely on a single catch-all, which is impractical and not a well-structured tool set.
The single tool is a thin wrapper around the entire CLI, providing no first-class operations for distinct tasks. Agents must manually construct CLI commands, which is error-prone and represents a shallow API surface compared to a more complete, structured set.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rlaksana/mcp-cli-gemini'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
