MCP servers in Gemini CLI: when they are worth it

Google's own description is the plain one: "An MCP server is an application that exposes tools and resources to the Gemini CLI through the Model Context Protocol". Tools the model can call, resources it can read. Both arrive with credentials attached and both persist past the task. Whether that trade is worth it depends on what you would have done instead.

Try a CLI first

Gemini CLI runs shell commands, sandboxed if you ask it to. If what you want to reach has a command-line client, the model can drive it under the same policy rules as any other command, with nothing new configured and nothing new holding a token. That is the cheaper answer for anything occasional.

A server earns its place when you need state the model queries live, when authentication should be handled once, or when a team should get the same tool by cloning the repository. Anything short of that is a standing connection for an intermittent need.

The folder decides before you do

Servers are configured under mcpServers in settings.json, and a project can carry its own settings. So a cloned repository can bring servers with it, and by default Gemini CLI connects to them on first run.

The control that changes this is Trusted Folders, which exists to prevent malicious code from running by "asking you to approve a folder before the CLI loads any project-specific configurations from it". Before you decide, it runs a discovery phase and lists what the folder would load — commands, MCP servers, hooks, skills, setting overrides. That list is exactly the inventory you want in front of you before trusting somebody else's checkout.

The feature is off until you enable it in your user settings. Turn it on before the first unfamiliar repository, and the question "which servers did this repo just connect" gets asked by the tool rather than answered by an incident.

The policy engine is the permission layer

Every MCP tool passes through the same policy engine as built-in tools. Rules in TOML name a tool or a server, carry a decision of allow, deny or ask_user, and the highest priority wins.

Two properties of that engine matter for servers specifically. A deny rule does more than block: the tool is removed from what the model can see at all, which both closes the door and saves the context the tool description would have cost. And ask_user becomes deny when the CLI runs headless, so a server you gate with prompts is a server that goes silent in a pipeline — which is the right default and worth knowing before you wonder why a stage produced nothing.

One caution the documentation states in its own box: "The Workspace tier (project-level policies) is currently non-functional". A policy file committed to the repository does nothing. Rules live at the user or administrator tier, which is also where they belong for anything that gates credentials.

Resources pull content in

Beyond tools, a server can expose resources, and Gemini CLI lets you reference one with the same @ syntax as a local file: @server://resource/path. On submit the CLI reads the resource and injects its content into the conversation.

That is convenient and it is also content from an external system entering the model's context on your request, with every property prompt injection depends on. A resource is only as trustworthy as the server that serves it and the data behind it.

What a server buys that a CLI does not

Live state in a form the model can query. Authentication handled once. A configuration a team shares by cloning. Resources that arrive with a reference rather than a paste.

Worth it for the integration in your daily loop. Overhead, plus a standing grant, for the one you needed in March.

What goes wrong

Reaching for MCP where a CLI exists. The command was already there, already covered by policy.

Cloning a repository with Trusted Folders off. Its servers connect on first run, and you find out from /mcp afterwards.

A policy file in the repo. The workspace tier is disabled; the rule never applied.

A gated server in a headless stage. ask_user is deny there, by design.

Treating a resource as a file. It is a fetch from a server, injected into context.

How to check it worked

Run /mcp in a session and read the list against the task in front of you. Then write one deny rule for a tool you do not need this week and confirm it disappears from what the model offers, rather than merely failing when called. That single check tells you the policy layer is doing its job, which is the thing a growing server list depends on.