Where is Gemini CLI's MCP configuration?

Under the `mcpServers` key in `~/.gemini/settings.json` for user scope, or `.gemini/settings.json` inside a project. `gemini mcp add` writes to one or the other depending on the scope flag you pass.

What does the `trust` option do?

It bypasses confirmation dialogs for that server, so the agent stops asking before acting on its tools. The documentation restricts it to servers you completely control, and it is the single highest-consequence field in the file — worth a written policy rather than a per-engineer decision.

Can I limit which tools a server exposes?

Yes, and you should. `includeTools` allowlists specific tools and `excludeTools` blocks them, with exclusions taking precedence. Most servers expose more than any one project needs, and narrowing it also narrows how much model-facing tool description reaches the agent.

What is the difference between `url` and `httpUrl`?

`url` declares an SSE endpoint and `httpUrl` declares an HTTP streaming endpoint. Gemini CLI keeps them as separate fields where some other surfaces use one field with a type, so definitions copied across tools need checking rather than pasting.

MCP setup · Google

How to add an MCP server to Gemini CLI

Gemini CLI's MCP configuration is conventional in shape and unusual in one respect: it exposes per-server tool filtering and a `trust` flag that skips confirmation dialogs entirely. Both are genuinely useful. The second is the field most worth having an organisational opinion about before anyone uses it.

How this surface handles MCP

Servers are declared under `mcpServers` in a settings file, either at `~/.gemini/settings.json` for you across all projects or `.gemini/settings.json` inside a project. The `gemini mcp add` command writes to one or the other depending on the scope flag, which is the same shape Claude Code uses and means the scope decision is made at add time rather than by choosing a file.

The transport fields cover three cases rather than two: `command` for a local process over stdio, `url` for an SSE endpoint, and `httpUrl` for HTTP streaming. That is a slightly finer distinction than most surfaces draw, and it means a definition copied from a tool that collapses the last two needs a moment's attention rather than a straight paste.

Two fields here are governance-relevant and rare enough to call out. `includeTools` and `excludeTools` filter which of a server's tools are exposed at all, with exclusions taking precedence — that is a real least-privilege control applied to a server you have already decided to trust, and very few surfaces offer it. Use it: most servers expose more than any one project needs.

`trust` is the other one, and it points the opposite way. Setting it to true bypasses confirmation dialogs for that server, which the documentation is explicit about restricting to servers you completely control. In an organisation, that flag should not be a per-engineer judgement call made at eleven at night — it is the difference between an agent asking before it acts and an agent not asking, and it belongs in a written policy alongside the list of servers it may be set on.

Where servers are stored

User~/.gemini/settings.json

reaches You, across every project on this machine.

The default destination for convenience, and therefore where personal servers accumulate unreviewed.

Project.gemini/settings.json

reaches Anyone who works in this project directory.

Committed and reviewable, which makes it the right scope for anything the team is meant to share.

The config shape

JSON. Servers live under `mcpServers`. Transport is `command` (stdio), `url` (SSE) or `httpUrl` (HTTP streaming). `includeTools`/`excludeTools` filter the exposed tool set; `trust` skips confirmation dialogs.

Gemini CLI — MCP server definition

{
  "mcpServers": {
    "example-server": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server@1.4.2"],
      "env": { "EXAMPLE_MODE": "read-only" },
      "timeout": 30000,
      "includeTools": ["search_docs", "get_issue"]
    }
  }
}

Adding a server

Add the server with an explicit scope
`gemini mcp add` takes `-s` or `--scope` and writes to `~/.gemini/settings.json` or the project's `.gemini/settings.json` accordingly. Deciding the scope at add time is better than editing the wrong file later and wondering why a teammate cannot see the server.
Pick the right transport field
`command` for a local process, `url` for SSE, `httpUrl` for HTTP streaming. These are three distinct fields rather than one field with a type, so a definition copied from another surface's docs may need reshaping.
Filter the tool set down to what you need
Set `includeTools` to the tools this project actually uses, or `excludeTools` to remove the destructive ones. Exclusions take precedence over inclusions. Most servers expose a superset of what any single project needs, and this is the cheapest least-privilege win available on this surface.
Leave `trust` alone unless you have a policy
It bypasses all confirmation dialogs for that server. The documentation restricts it to servers you completely control, and in a company 'completely control' should mean something written down rather than something an engineer decided during a long debugging session.

Confirming it actually connected

Run the CLI's MCP listing and confirm the server is discovered and its tools enumerate. A server declared under the wrong transport field usually fails at connect rather than at parse.
Check that the exposed tool list matches your `includeTools` or `excludeTools` intent, rather than assuming the filter applied.
Grep both settings files for `"trust": true` before you consider the machine reviewed. It is one line, it is easy to add, and it changes the agent's behaviour more than any other field here.

Review this before you connect anything

the part the vendor docs will not tell you

A connected MCP server can read what its credential can read and do what its tools can do, and its tool descriptions reach the model as instructions. None of that is visible from a configuration file that parses correctly.

Decide the trust posture before the server, not after
Confirmation dialogs are the last human checkpoint between a poisoned tool description and an executed action. Turning them off for convenience removes the control that catches the attacks the config file cannot.
Reduce the tool surface on day one
It is far easier to add a tool to `includeTools` when someone needs it than to discover months later that a server has been exposing a delete operation nobody used and nobody noticed.
Read tool descriptions as model input
Descriptions are instructions to the agent. Tool filtering limits which descriptions reach the model at all, which makes it a partial defence against tool poisoning as well as a least-privilege control.
Pin versions on stdio servers
An unpinned package launcher resolves at start time. Approval and execution then refer to different code, and nothing in the settings file records the difference.

Organisational controls

Per-server tool filtering
`includeTools` and `excludeTools` restrict which tools a connected server may expose, with exclusions taking precedence. This is least privilege applied inside an approved server, which is a control most surfaces do not offer at all.
Trust as an explicit, auditable setting
Because `trust` is a field in a file rather than a UI toggle, it is greppable and reviewable. That makes it a reasonable thing to assert in policy and to check in a pre-commit or fleet audit.
Project settings as the shared floor
A committed `.gemini/settings.json` gives a team one reviewed definition. It does not stop a user-scoped server being added alongside it, so treat it as the published good path rather than as enforcement.

What this cannot tell you

Two settings files on one machine describe that machine. They do not tell you how many engineers set `trust` to true, which servers exist across the fleet, or whether the tool filter you carefully wrote for one project was copied without its `excludeTools` into three others. Every one of those is a grep on a laptop you do not have.

Frequently asked

Where is Gemini CLI's MCP configuration?: Under the `mcpServers` key in `~/.gemini/settings.json` for user scope, or `.gemini/settings.json` inside a project. `gemini mcp add` writes to one or the other depending on the scope flag you pass.
What does the `trust` option do?: It bypasses confirmation dialogs for that server, so the agent stops asking before acting on its tools. The documentation restricts it to servers you completely control, and it is the single highest-consequence field in the file — worth a written policy rather than a per-engineer decision.
Can I limit which tools a server exposes?: Yes, and you should. `includeTools` allowlists specific tools and `excludeTools` blocks them, with exclusions taking precedence. Most servers expose more than any one project needs, and narrowing it also narrows how much model-facing tool description reaches the agent.
What is the difference between `url` and `httpUrl`?: `url` declares an SSE endpoint and `httpUrl` declares an HTTP streaming endpoint. Gemini CLI keeps them as separate fields where some other surfaces use one field with a type, so definitions copied across tools need checking rather than pasting.

Sources

Every path, key, table and flag on this page was read from Google's own documentation on 2026-07-26. Where a control varies by plan or is changing quickly, this page describes the mechanism rather than asserting a current state.