·

Jira MCP With Gemini CLI

Set up Jira MCP in Gemini CLI so your AI agent can read and update issues, sprints, and boards right from your editor.

Gemini CLI's MCP config lives in settings.json, either at ~/.gemini/settings.json for global servers or .gemini/settings.json at the repo root for project-scoped ones — the same two-tier pattern you'll recognize from Claude Code, with different file names and a slightly different JSON shape. This topic covers the setup, a bug-triage-and-labeling workflow that plays to Gemini's strengths, and an honest comparison of output quality against Claude Code for the same Jira tasks.

Installing and Connecting Jira MCP to Gemini CLI

Add the server under mcpServers:

{
  "mcpServers": {
    "jira": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_USERNAME": "you@company.com",
        "JIRA_API_TOKEN": "$JIRA_API_TOKEN",
        "JIRA_PROJECTS_FILTER": "PROJ"
      },
      "timeout": 30000
    }
  }
}

The timeout field is worth setting explicitly — Gemini CLI's default MCP timeout has historically been tighter than Claude Code's, and jira_search calls against a large project with a broad JQL filter can take a few seconds longer than the default allows, especially on Server/Data Center instances with heavier load.

Check the connection with:

gemini mcp list

Expected output includes the server name and a connection status. If it shows disconnected, run with verbose logging to see the raw stderr from the spawned process:

gemini --debug mcp list

Docker works the same as with other clients, useful if you want a consistent runtime across a team that isn't all running uv:

{
  "mcpServers": {
    "jira": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "JIRA_URL", "-e", "JIRA_USERNAME", "-e", "JIRA_API_TOKEN",
        "ghcr.io/sooperset/mcp-atlassian:latest"
      ],
      "env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_USERNAME": "you@company.com",
        "JIRA_API_TOKEN": "$JIRA_API_TOKEN"
      }
    }
  }
}

Tips
- Set an explicit timeout value above the default for the Jira server — broad JQL queries against large projects are a common cause of spurious timeout errors that look like connection failures.
- Use gemini --debug mcp list the moment a server shows disconnected — the raw stderr almost always names the actual problem (bad token, malformed URL, missing binary) faster than guessing.
- Keep project-scoped .gemini/settings.json out of version control if it contains anything beyond an environment variable reference — treat it the same as any other secrets-adjacent config file.

Querying Sprints, Boards, and Issues from Gemini CLI

Gemini CLI handles structured, multi-step Jira queries well, and tends to be explicit about which tool it's calling and why in its intermediate output — useful when you're debugging why a query returned what it did.

gemini "List all boards in the PROJ project, then show me the sprints
on the first Scrum board, then summarize the current sprint's issues by status"

Calling jira_get_agile_boards(project_key="PROJ")...
Found 2 boards: "PROJ Scrum Board" (id: 42, type: scrum), "PROJ Kanban" (id: 43, type: kanban)

Calling jira_get_sprints_from_board(board_id=42)...
Active sprint: "Sprint 25" (id: 119, started 2026-08-11, ends 2026-08-25)

Calling jira_get_sprint_issues(sprint_id=119)...

Sprint 25 status breakdown (22 issues total):
- To Do: 6
- In Progress: 9
- In Review: 4
- Done: 3

For direct JQL, Gemini CLI passes it straight through to jira_search without much reinterpretation, which is a feature, not a limitation — if you already know JQL, you get predictable results:

project = PROJ AND type = Bug AND created >= -7d ORDER BY priority DESC

gemini "Run this JQL: project = PROJ AND type = Bug AND created >= -7d
ORDER BY priority DESC, then group the results by priority and give me counts"

For board-level reporting across multiple boards — useful if your org splits work across several teams within one Jira instance — chain the calls explicitly rather than trusting the model to infer scope:

gemini "For each board returned by jira_get_agile_boards, get the active
sprint's issue count and completion percentage, then rank the boards by
percentage complete"

Tips
- Feed Gemini CLI raw JQL directly when you already know exactly what you want — it passes queries through with minimal reinterpretation, which makes results predictable and easy to verify.
- Watch the intermediate "Calling jira_X..." output closely during multi-step queries — it's your fastest way to catch a wrong board ID or sprint ID before the final summary hides the mistake.
- When reporting across multiple boards, instruct the agent to loop explicitly over each board rather than asking a vague aggregate question — it reduces the chance of one board silently being skipped.

Practical Example: Automated Bug Triage and Labeling in Gemini CLI

This is where Gemini CLI's structured, rule-following style shines: given a batch of new, unlabeled bugs and a clear rubric, it applies the rubric consistently across every item rather than drifting partway through a long list.

gemini "Find all bugs in PROJ created in the last 3 days with no priority
set. For each one, read the summary and description, then:
1. Assign priority using this rubric:
   - Highest: data loss, security issue, or production outage
   - High: broken core feature with no workaround
   - Medium: broken feature with a workaround
   - Low: cosmetic or edge-case issue
2. Add a label: 'frontend', 'backend', 'infra', or 'unclear' based on
   the component mentioned
3. Post a comment explaining the assigned priority and label
Show me the full list before applying any changes."

project = PROJ AND type = Bug AND created >= -3d AND priority is EMPTY

Found 5 unlabeled bugs. Proposed triage:

PROJ-701 "Checkout fails with 500 on Safari" 
  -> Priority: High (broken core feature, no workaround mentioned)
  -> Label: backend
  -> Comment: "Auto-triaged: 500 error on checkout blocks purchase
     completion with no stated workaround. Flagging High priority
     pending confirmation."

PROJ-702 "Button color slightly off on dark mode"
  -> Priority: Low (cosmetic)
  -> Label: frontend

PROJ-703 "Customer database export includes deleted rows"
  -> Priority: Highest (data integrity issue)
  -> Label: backend

PROJ-704 "Redis connection pool exhausted under load"
  -> Priority: Highest (production outage risk)
  -> Label: infra

PROJ-705 "Search results order seems inconsistent"
  -> Priority: Medium (workaround exists: re-run search)
  -> Label: unclear

Apply these 5 updates? (yes/no)

Confirming this batch triggers 5 rounds of jira_update_issue (priority + label) and jira_add_comment. The rubric-following behavior here is consistent enough to trust for the labeling and initial priority pass — but keep Highest/High assignments in a human review queue before they hit an on-call rotation, since a false-positive "Highest" from a poorly worded bug report can trigger unnecessary paging.

Tips
- Give an explicit, numbered rubric for priority and label assignment — Gemini CLI applies stated rules more consistently across a batch than it infers implicit ones from examples alone.
- Always require a "show me before applying" confirmation step for batch triage — reviewing 5-10 proposed changes takes under a minute and catches rubric misapplications before they touch real tickets.
- Route AI-assigned Highest/High priority bugs through a human check before they trigger paging or on-call alerts — a confidently wrong severity call is worse than a slow one.

Comparing Jira MCP Output Between Gemini CLI and Claude Code

Running the same triage prompt through both tools on the same backlog surfaces real differences, not just style preferences:

Rule-following consistency: Gemini CLI tends to apply an explicit numbered rubric more literally across every item in a batch — useful for triage, less useful when you actually wanted some judgment applied to edge cases. Claude Code is more likely to flag an ambiguous case explicitly ("PROJ-705 could be Medium or Low depending on how often this reproduces — I went with Medium") rather than silently picking one.

Tool-call transparency: Gemini CLI prints its intermediate tool calls more verbosely by default, which is genuinely helpful for debugging a wrong JQL query mid-conversation. Claude Code's tool call visibility depends on your terminal settings and whether you're in verbose mode — comparable information is there, but it takes an extra flag to surface by default.

JQL interpretation: both pass raw JQL straight through to jira_search without meaningful differences — this is a mcp-atlassian behavior, not a client behavior, so don't expect one CLI to "understand JQL better" than the other. The differences that matter are entirely in how each model translates natural language into JQL when you don't supply it directly.

Sprint math and multi-step reasoning: for the sprint-planning-style query from earlier in this module, both tools produce comparable velocity calculations when given the same tool results — the underlying data from mcp-atlassian doesn't change based on which client is asking. Differences you'll notice show up in how each explains its reasoning, not in factual accuracy of the Jira data itself.

Bottom line: pick based on workflow fit, not raw capability. If your team wants a rules-based, auditable triage pipeline, Gemini CLI's literal rule-following is an asset. If you want an agent that flags its own uncertainty on judgment calls, Claude Code's tendency to surface ambiguity is worth more.

Tips
- Test any triage rubric against both tools on a small backlog sample before committing to one for a recurring automated job — the differences in judgment-call handling are real and matter for edge cases.
- Don't attribute JQL quality differences to the CLI — mcp-atlassian handles JQL identically regardless of which client is calling it; differences come from how each model builds the query when you don't supply it directly.
- For audit-sensitive workflows (compliance-adjacent triage, SLA-tied priority calls), prefer whichever tool surfaces its reasoning and intermediate tool calls most visibly in your terminal setup — that visibility is what makes a later audit possible.

Tips

Gemini CLI is a strong Jira MCP client when your workflow benefits from consistent rule application across a batch — the setup is nearly identical to other clients, and the main things worth tuning are the connection timeout and how explicitly you write your triage rubrics.

Tips
- Bump the MCP timeout above default for the Jira server before you hit a false-positive connection failure on a broad JQL query.
- Write numbered, explicit rubrics for any batch classification task — Gemini CLI rewards that structure with consistent, auditable output.
- Compare output against Claude Code on a small sample before standardizing on one tool for a recurring automated workflow — the differences are in judgment handling, not raw Jira data accuracy.

Next Jira MCP With Cursor