Wiring MCP servers into Gemini CLI

Out of the box, Gemini CLI reads your repo, runs shell commands, and fetches from the web. That covers most pure coding work. It does not cover the moment the agent needs the staging database's actual schema, the ticket it's supposedly implementing, or a browser to check that the fix rendered. Those are the places where real tasks live, and that gap is what MCP fills. Gemini CLI treats it as first-class plumbing.

Where the wiring goes

Servers are declared in settings.json: ~/.gemini/settings.json for things you want everywhere, .gemini/settings.json inside a repo for servers that only make sense there. A minimal local server looks like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Local servers run as child processes speaking stdio. Remote servers are declared with a URL instead and talk HTTP or SSE. That's how hosted services expose MCP without you running a process. Restart, then run /mcp to list every connected server and the tools each one contributed. Credentials ride in through env config, which is one more argument for the project-scoped file over your globally synced dotfiles. If the protocol itself is still fuzzy, the MCP explainer covers the architecture. For today it's enough that servers vend tools and the CLI is a client.

What a good server buys

• Databases. Schema inspection and read-only queries: the agent stops guessing column names from ORM code and starts checking them.
• Issue trackers. It reads the real ticket, acceptance criteria included, instead of your lossy paraphrase of it.
• Browsers. After a UI change it drives an actual page and reports what rendered, closing a loop that a green build only pretends to close.

The common thread: good servers ground the agent in systems of record. The config is portable too: the same server declaration works, near verbatim, in Claude Code, Goose, or Junie. That's the point of a standard. The integration outlives whichever client you happen to run this year.

Every MCP server is ambient context and ambient risk — wire in the ones that ground the agent, and not one more.

The discipline

Two bills arrive with every server. Context first: each server's tool schemas are presented to the model on every request, so a chatty server with forty tools bloats sessions and measurably worsens tool selection. The agent starts reaching for the wrong instrument. Risk second: tool results are untrusted input, and a server that reads from the outside world is a prompt-injection path into a process that can execute shell commands. My rules: scope servers per project rather than globally, prefer read-only variants when they exist, filter down to the tools you actually need when the config allows it, and be stingy with trust settings that skip confirmation prompts (maximally convenient, and exactly how bad days begin). The same judgment applies whether you adopt servers or design the tools yourself. And when you catch yourself pasting the same three servers into every repo, that's the cue to package them as an extension.

Start at zero servers. Work a normal week and notice where the agent guesses because it can't see. That's your first server, usually the tracker or the database. Add it project-scoped, watch what /mcp reports, and drop anything that hasn't earned a tool call in a month.