Gemini MCP: Connect Tools to Google Gemini
Gemini can use MCP tools through Gemini CLI and, for a narrower audience, custom Connected Apps in Gemini Spark.
Gemini MCP lets Google’s Gemini models call external tools through Gemini CLI, while eligible Gemini Spark users can connect remote servers by URL. The practical choice is Gemini CLI: it supports local and remote transports, exposes permission controls, and is available without treating a limited consumer-app rollout as universal support.
Table of contents
- The short answer
- How Gemini MCP works today
- Step-by-step Gemini MCP setup
- Gemini CLI vs other MCP clients
- The catch most guides skip
- What to connect first
- What actually breaks
- Our verdict
The short answer
Gemini MCP is supported directly in Gemini CLI, which can launch local stdio servers or connect to SSE and Streamable HTTP endpoints. Custom MCP URLs also work in Gemini Spark, but only for eligible adult US users with personal accounts, English enabled, Keep Activity on, and only inside Spark tasks—not as a general switch for every Gemini chat.
There is no first-party product or package simply called “Gemini MCP server.” Gemini is normally the host and client; the server is the GitHub, Sentry, browser, database, or other integration it calls. Google’s Gemini CLI MCP documentation confirms the three transports and the mcpServers configuration, while Gemini Apps Help documents Spark’s narrower rollout.
How Gemini MCP works today
Gemini CLI reads server definitions, starts or contacts each server, discovers its tools, resources, and prompts, and registers compatible capabilities for the model. When Gemini selects a tool, the CLI applies its policy and confirmation rules before sending the request to that server.
Gemini chooses when to request a capability, while the server owns authentication, validation, external calls, and returned data. The MCP architecture guide explains why the same server can often work across Gemini, Claude, and Cursor.
Gemini CLI sanitizes schemas and namespaces discovered tools. Start with one server and a small allowlist; dozens of vaguely named tools make selection harder to predict. For candidates, use the MCP Directory’s best MCP servers, then verify the install instructions in the owner’s repository.
Step-by-step Gemini MCP setup
Use Gemini CLI’s documented paths and an official server image. This example comes from Google’s GitHub tutorial.
-
Install and open Gemini CLI. Follow the official Gemini CLI repository for installation and sign-in. Run
geminionce before adding another process. -
Choose the configuration scope. Use
~/.gemini/settings.jsonglobally or.gemini/settings.jsonin one project. We prefer project scope while testing. Thegemini mcp addcommand defaults to project scope;--scope userwrites user configuration. -
Create a narrowly scoped GitHub token. Create a fine-grained token with only needed repository permissions. Export it as
GITHUB_PERSONAL_ACCESS_TOKEN; never commit the secret. -
Add the documented server definition. Merge this block into
settings.json. Docker must be running.
{
"mcpServers": {
"github": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server:latest"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
}
}
}
}
-
Restart and inspect the connection. In Gemini CLI, run
/mcp list; the server should reportConnected. After a configuration change,/mcp reloadforces capability discovery again. Google’s setup tutorial documents this exact image, environment variable, path, and verification flow. -
Test a read before a write. Ask for open pull requests in one repository, inspect the proposed tool call, and confirm it. Only then try creating an issue or modifying data. Keep the server’s
trustfield false—the default—because true bypasses confirmations. -
Reduce the exposed surface. Use
includeToolsandexcludeTools; exclusions win. Follow our guide to adding an MCP server, but copy tool names only from the server owner.
Gemini CLI vs other MCP clients
Gemini CLI is the best fit here when the work already happens in a terminal and you want explicit project-scoped policy. Claude Desktop is friendlier for desktop knowledge work, while Cursor and Windsurf keep the tools beside an editor.
| Client | Local stdio | Remote transport | Main configuration | Permission posture | Best fit |
|---|---|---|---|---|---|
| Gemini CLI | Yes | SSE and Streamable HTTP | ~/.gemini/settings.json or .gemini/settings.json | Confirmations by default; include/exclude lists and policy rules | Terminal agents and scripts |
| Claude Desktop | Yes | Remote connectors | Desktop extensions/config plus connectors UI | User confirmations and connector controls | General desktop workflows |
| Cursor | Yes | SSE and Streamable HTTP | .cursor/mcp.json or user config | Tool approval is visible in the editor | Repository-focused coding |
| Windsurf | Yes | SSE and Streamable HTTP | Marketplace or ~/.codeium/windsurf/mcp_config.json | Per-tool toggles; team allowlists | Editor users wanting a marketplace |
Cursor documents project configuration in its official MCP guide; Windsurf documents three transports and a 100-tool ceiling in its Cascade MCP guide. Choose Cursor MCP for code-first visual work and Claude Desktop MCP for local documents. Transport, scope, and approvals matter more than model preference.
The catch most guides skip
The biggest limitation is product fragmentation: support in Gemini CLI does not mean the same server is available in every Gemini web or mobile conversation. Gemini Spark accepts remote MCP URLs only for a restricted audience and only inside Spark tasks; Gemini CLI can launch local commands, but Spark cannot consume a local stdio command or a localhost-only service.
Use Gemini CLI for local tools, or deploy authenticated Streamable HTTP when Spark is required. Avoid improvised public tunnels: remote hosting adds operational work, but removes dependence on a running laptop.
Permissions are the second catch. trust: true suppresses confirmations, while a server acts under your credential. Google’s custom-app safety guidance says third-party Spark servers remain the user’s responsibility. Least-privilege credentials and tool filters provide the real containment.
What to connect first
Start with tools that have a narrow job, clear ownership, and reversible output. We would connect GitHub, Sentry, and Playwright in that order, not email or a production database.
1. GitHub for repository context
GitHub’s owner-maintained server covers repositories, issues, pull requests, and workflows. Begin read-only with one repository, adding writes only after review. The official GitHub MCP server supports hosted and local deployment and documents toolsets.
2. Sentry for error investigation
Sentry moves from an error report to events and suspected code without broad business-data access. Its hosted service removes a local process but adds network authentication. Use the endpoint and sign-in instructions from the Sentry-maintained MCP repository, not an aggregator’s copied config.
3. Playwright for browser checks
Playwright can verify pages and reproduce UI paths. Because it acts in a browser, restrict domains and use test accounts first. Microsoft publishes the real options and install methods in the official Playwright MCP repository.
What actually breaks
Most Gemini MCP failures come from process, transport, credential, or schema mismatches—not from Gemini being unable to call tools. Diagnose the connection before rewriting prompts.
Disconnectedin/mcp list: run the configured command manually, verify Docker or the runtime exists, and check the working directory.- Works globally but not in a project: inspect both settings scopes and confirm the current folder is trusted; untrusted folders do not test local
stdioservers as connected. - Server connects but exposes no tools: run
/mcp reload, inspectincludeToolsandexcludeTools, and check whether Gemini rejected incompatible schemas. - Remote auth fails: use
/mcp authfor an OAuth-enabled server or the exact documented headers; never improvise an environment-variable name. - Spark cannot connect: confirm eligibility, English, personal-account use, Keep Activity, a public MCP URL, and that the task is actually running in Spark.
The Gemini CLI diagnostics documentation notes that background connection errors are quiet by default and become detailed through interactive MCP commands or attempted tool use. That quiet startup is convenient, but it makes /mcp list the first command we would run.
Our verdict
Gemini MCP is ready for developer workflows through Gemini CLI, but the consumer experience remains conditional enough that it should not drive an organization-wide rollout. Treat Spark’s URL connection as a targeted option, not proof that every Gemini surface is now an open MCP client.
We would deploy one vendor-owned server at project scope, leave confirmations on, expose only the tools a real workflow needs, and measure whether it saves time. We would avoid giant server bundles, copied configs, and broad production tokens. Gemini CLI’s advantage is transport flexibility and policy control; its price is terminal-oriented setup and more configuration ownership than a curated desktop marketplace.