·

GitLab MCP With Gemini CLI

Set up GitLab MCP in Gemini CLI so your AI agent can manage repositories, merge requests, and CI/CD pipelines right from your editor.

Gemini CLI's MCP support has matured quickly, and GitLab integration works well for the read-heavy, summarization-flavored tasks Gemini models tend to handle confidently — project browsing, pipeline status digests, changelog-style summaries. Where it's more cautious is multi-step write chains, which this topic addresses directly with prompt patterns and a comparison against Claude Code's behavior on the same tasks.

Installing and Connecting GitLab MCP to Gemini CLI

Gemini CLI reads MCP server config from .gemini/settings.json (project) or ~/.gemini/settings.json (user-level). Add GitLab under mcpServers:

{
  "mcpServers": {
    "gitlab": {
      "command": "npx",
      "args": ["-y", "@gitlab-org/mcp-server"],
      "env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "$GITLAB_PERSONAL_ACCESS_TOKEN",
        "GITLAB_API_URL": "https://gitlab.com/api/v4"
      },
      "timeout": 30000
    }
  }
}

The timeout field is worth setting explicitly and a bit higher than the default — pipeline-related tools (get_pipeline_jobs, get_job_logs) can be slow to respond on projects with long job logs, and Gemini CLI's default MCP timeout has, in past versions, been aggressive enough to cut off a legitimately-in-progress call.

Alternatively, add it via the CLI helper if your Gemini CLI version supports it:

gemini mcp add gitlab npx -y @gitlab-org/mcp-server \
  --env GITLAB_PERSONAL_ACCESS_TOKEN=$GITLAB_PERSONAL_ACCESS_TOKEN \
  --env GITLAB_API_URL=https://gitlab.com/api/v4

Verify with:

gemini mcp list

Then confirm tool visibility from inside a session:

/mcp

This lists connected servers and their exposed tools — check that gitlab shows a non-empty tool list rather than "connected, 0 tools," which usually means the server started but auth failed silently on the handshake (a bad token format is the common cause — GitLab PATs always start with glpat-, double check you didn't paste a project access token, which has a different prefix, into the wrong field).

Tips
- Set an explicit timeout above the default (30000ms is a reasonable floor) for any project where CI jobs produce long logs.
- Run /mcp inside a Gemini CLI session after setup to confirm the tool list is populated, not just that the server shows "connected."
- Confirm your token prefix matches the token type you intended — glpat- for personal access tokens, a different format for project/group access tokens — a mismatched paste is a common silent-failure cause.

Managing GitLab Projects and Pipelines from Gemini CLI

Gemini CLI handles project-discovery and pipeline-status queries confidently — this is squarely in the "summarize structured data" zone these models are strong at.

Browsing projects when you don't remember the exact path:

Search my GitLab projects for anything with "billing" in the name and
show me the default branch and last activity date for each match.

Getting a pipeline health snapshot:

For my-group/billing-service, show me the status of the last 10
pipelines on the main branch. Flag any that failed and tell me which
stage failed.

This chains list_pipelines (filtered to main, limited to 10) with get_pipeline or get_pipeline_jobs for the failed ones specifically — Gemini CLI is reasonably good about not pulling job-level detail for pipelines that passed, which keeps the tool-call count sane on a project with a long pipeline history.

Cross-project pipeline health for a release check:

Check the latest main-branch pipeline status for these three projects:
my-group/billing-service, my-group/notifications-service, and
my-group/api-gateway. Give me a simple pass/fail table.

This is a good multi-project use case, but expect three sequential (not parallel) tool-call rounds in most Gemini CLI sessions — the MCP tool-calling loop is turn-based, so a "check three projects" request often takes noticeably longer wall-clock time than you'd expect from three independent API calls. If speed matters, it's sometimes faster to just run three separate prompts.

Tips
- For cross-project checks, expect sequential rather than parallel tool calls in most Gemini CLI sessions — factor that into how many projects you batch into one prompt.
- Ask for pass/fail tables or short flags rather than full narrative pipeline summaries when checking many pipelines at once — keeps the output scannable.
- Filter pipeline lists to a branch (main, release/*) explicitly; an unfiltered list_pipelines call on an active project returns merge-request pipelines too, which inflates the result set.

Practical Example: Monitoring CI/CD Pipeline Status with Gemini CLI and GitLab MCP

Walking through a realistic on-call-adjacent scenario: a pipeline just failed on main and you want a fast, structured triage without opening the GitLab UI.

Step 1 — get the failure detail:

The latest pipeline on main for my-group/billing-service failed. Tell me
which job failed and pull the last 100 lines of its log.

Gemini CLI calls get_pipeline (or list_pipelines limited to 1, most recent) to find the pipeline ID, then get_pipeline_jobs to find the failed job, then get_job_logs for that job specifically. Confirm it's pulling the actual failed job's logs and not the first job in the pipeline — with pipelines that have parallel stages, this is a real ambiguity a model can get wrong if the prompt doesn't disambiguate, so if you have multiple failed jobs, ask for each by name.

Step 2 — get a root-cause read:

Based on that log output, what's your best guess at the root cause?
Is this likely a flaky test, a real code regression, or an infrastructure
issue (timeout, OOM, network)?

This is a judgment call the model makes from log text alone — treat it as a strong first hypothesis, not a diagnosis. A log showing a timeout could be a genuine performance regression or just an overloaded shared runner; the log alone often can't distinguish these, and a good response should say so rather than asserting confidently.

Step 3 — decide whether to retry or escalate:

If this looks like a flaky infrastructure issue, retry the pipeline. If
it looks like a real code failure, don't retry — instead create an issue
in my-group/billing-service with the log excerpt and title it clearly.

This is exactly the kind of conditional, consequential action worth being explicit about rather than trusting an implicit "and fix it" instruction — you're giving the agent a decision tree with two well-defined branches (retry_pipeline vs. create_issue) instead of an open-ended "handle it."

Step 4 — close the loop with a human-readable summary:

Give me a 3-sentence summary of what happened and what action you took,
formatted for pasting into our team Slack channel.

Tips
- When multiple jobs fail in the same pipeline, name them explicitly rather than asking for "the failed job" — ambiguity here leads to logs from the wrong job.
- Treat AI root-cause guesses from log text as a hypothesis to verify, not a conclusion — especially for timeout/flaky-vs-real-regression calls.
- Give explicit branching instructions (if X, retry; if Y, create an issue) rather than an open "fix it" — this keeps a consequential action like retry_pipeline from firing on the wrong condition.

Comparing GitLab MCP Behavior Between Gemini CLI and Claude Code

Running the same prompts through both tools on the same project surfaces a few consistent differences worth knowing before you pick one for a given task.

Tool-call sequencing. Claude Code more reliably chains 3+ step tool calls (list → filter → act) without needing the steps spelled out explicitly in the prompt. Gemini CLI does fine with 2-step chains but benefits noticeably from more explicit step-by-step prompting for anything longer — the pipeline triage example above works better on Gemini CLI when you break it into the four separate prompts shown rather than one combined "investigate and fix the failed pipeline" instruction.

Read vs. write caution. Both tools respect explicit "don't do X" instructions, but Gemini CLI has, in practice, been more conservative by default about calling write tools (merge_merge_request, retry_pipeline) without an explicit go-ahead in the prompt — it's somewhat more likely to describe what it would do and ask for confirmation. Claude Code is more likely to proceed directly if the prompt reads as an instruction rather than a question. Neither behavior is objectively better; know which default you're getting and prompt accordingly (add "just do it, don't ask for confirmation" to Gemini CLI prompts if you want the more direct behavior).

Log and diff handling. For large get_job_logs output, Claude Code's larger typical context window handling in Claude Code CLI sessions tends to retain more of a long log for later reference in the same conversation. Gemini CLI sessions can lose earlier log detail sooner in a long back-and-forth, so if you're doing an extended triage conversation, periodically re-paste or re-fetch the relevant log excerpt rather than assuming it's still "in view."

Config format friction. Practically, Gemini CLI's .gemini/settings.json and Claude Code's .mcp.json use different field names for the same concepts (mcpServers key name is shared, but env vs env var interpolation syntax differs slightly) — if you support both tools in one repo, keep two separate config files rather than trying to hand-write one that's "compatible" with both; it isn't, and small syntax differences (missing $ vs ${}) are a common cause of a server that connects in one tool and silently fails in the other.

Tips
- For multi-step GitLab workflows, break instructions into explicit sequential prompts on Gemini CLI rather than one long combined instruction — it improves reliability noticeably.
- Add "proceed without asking for confirmation" to Gemini CLI prompts when you want write actions to fire immediately, matching Claude Code's more default-direct behavior.
- Maintain separate .mcp.json and .gemini/settings.json files rather than one shared config — the env var interpolation syntax isn't actually interchangeable despite looking similar.

Tips

Tips
- Gemini CLI is a strong fit for read-heavy pipeline and project summaries; give write-heavy MR/merge workflows to whichever tool you've tested more thoroughly for multi-step chaining on your team.
- Set MCP timeouts generously for pipeline/job-log tools — these are the calls most likely to be slow on real projects.
- Run /mcp after any config change to confirm tool visibility before trusting a session's output.

Next GitLab MCP With Cursor