Jira MCP Server Guide (2026): Official vs Community Setup

TL;DR: which Jira MCP should you use

The decision collapses to two questions: where does your Jira live, and who should hold the credentials?

• Jira Cloud + you want it working in two minutes: use Atlassian’s official Rovo MCP Server (originally announced as the “Remote MCP Server”). It’s hosted — nothing to install. Point your client at https://mcp.atlassian.com/v1/mcp/authv2, approve the OAuth 2.1 consent screen in your browser, done. Every action runs as you, with your existing project and space permissions.
• Jira Server / Data Center, or you need headless automation: use sooperset/mcp-atlassian (MIT, Python). It runs locally via uvx, Docker, or pip, authenticates with an API token (Cloud) or Personal Access Token (Server/DC), and works behind a VPN. It’s the most established community implementation — our catalog entry is /servers/atlassian-cloud.
• You only need to pick a PM tool first: if you haven’t committed to Jira at all, read our Jira vs Linear vs Trello vs Productboard MCP comparison before installing anything.

The copy-paste, if that’s all you came for:

# Claude Code → official hosted server (Jira Cloud)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
# then run /mcp inside Claude Code to complete the OAuth flow

One deadline worth knowing today: the original SSE endpoint (https://mcp.atlassian.com/v1/sse) is deprecated. Atlassian’s docs state it will no longer be supported after June 30, 2026. If a tutorial — or an older saved config — points at /v1/sse, swap it for /v1/mcp/authv2 now.

The Jira MCP landscape (why this is confusing)

Search any MCP directory for “jira” and you get a wall of near-identical entries — we list more than a dozen ourselves. They sort into three tiers:

Some history explains the naming mess. Atlassian launched its remote server in beta in May 2025, with Anthropic as the first official partner and Cloudflare as the hosting infrastructure. It shipped as the “Atlassian Remote MCP Server”; the docs now call it the Atlassian Rovo MCP Server and no longer carry a beta label. Same thing, two names — when you see either, it’s the hosted endpoint at mcp.atlassian.com. Atlassian’s own framing of what it’s for, from the launch marketing era forward, has been consistent:

The two implementations that matter, as catalog cards — the official server first:

Atlassian (Jira & Confluence)atlassian

Official1-Click Ready

Atlassian's official remote MCP server. Securely connects Jira and Confluence to Claude, Cursor, or any MCP client. OAut

auth security16.5k898

Atlassian Cloudsooperset

1-Click Ready

Access Confluence pages and Jira in the cloud with Atlassian API. Integrate effortlessly using the REST API for Jira.

productivity1.8k14

Our directory also lists the suite-level Jira & Confluence entry and combos like Jira & Linear for teams mid-migration. For the broader ecosystem beyond Jira, our awesome MCP servers roundup covers what else is worth installing alongside it.

Our take: the single-purpose wrappers made sense in 2025 when there was no official option. In 2026 they’re mostly a maintenance liability — pick between the two real options above unless you have a specific reason to fork.

Auth: OAuth 2.1 vs API token (the real difference)

Auth is where the official and community servers genuinely diverge — more than tools, more than features. Pick based on your trust boundary.

Official server: OAuth 2.1, identity-bound

Atlassian’s docs are explicit: the Rovo MCP Server “uses OAuth 2.1 as its primary authentication mechanism, providing a secure and standardized way for users to authorize access to resources via an interactive consent flow.” You paste the endpoint into your client, a browser tab opens, you approve, and the client holds a token tied to your Atlassian identity. The README’s permission promise: “Access is granted only to data that the user already has permission to view in Atlassian Cloud. All actions respect existing project or space-level roles.” If you can’t see the payments board in the Jira UI, your agent can’t either.

For non-interactive use — CI pipelines, bots, backend agents — Atlassian added API token authentication: Basic auth with a personal API token, or Bearer auth with a service-account key, against the /v1/mcp endpoint. Two caveats. Org admins can disable this path entirely (“If your organization admin has disabled authentication via API token, MCP clients won’t be able to connect”), and the OAuth flow remains the default Atlassian recommends for anything a human drives.

Community server: env vars you control

sooperset/mcp-atlassian flips the model: credentials live in environment variables on the machine running the server, and the trust boundary is yours to manage. Three modes:

• Cloud API token: JIRA_USERNAME + JIRA_API_TOKEN (and the CONFLUENCE_* twins). Generate the token at id.atlassian.com/manage-profile/security/api-tokens.
• Server/Data Center PAT: JIRA_PERSONAL_TOKEN instead of username + token. This is the only practical MCP path for on-prem Jira — the official server cannot reach it.
• OAuth 2.0: supported for Cloud if you want consent-flow semantics on a self-hosted server; the docs at mcp-atlassian.soomiles.com cover the wiring.

Opinionated summary: OAuth 2.1 on the official server is the better default for humans — tokens never touch a config file, and offboarding an employee kills their grant. The API-token model is better for automation precisely because nothing interactive sits in the loop — but an API token in an env var is a long-lived secret, so scope a dedicated Atlassian account for the agent rather than reusing a human’s token.

Install the official server (every client)

The install card below comes from our canonical /servers/jira entry — the one-click remote config for Atlassian’s hosted server. One migration note: configs that still reference the /v1/sse URL keep working only until June 30, 2026. The current endpoint to use everywhere is https://mcp.atlassian.com/v1/mcp/authv2.

One-line install · Jira

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

Client-specific notes:

• Claude Code: claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2, then /mcp inside a session to authenticate. See /clients/claude-code for scope flags and config-file locations.
• Claude (web/desktop): add the endpoint as a custom connector in Settings → Connectors. Claude was Atlassian’s first official partner, so this path is well-trodden.
• Cursor / VS Code / other IDEs: if the client supports remote MCP with OAuth natively, paste the URL. If it only speaks stdio, Atlassian documents the mcp-remote proxy — a local Node process (Node.js v18+ required) that bridges stdio to the hosted endpoint and handles the browser OAuth round-trip:

  {
    "mcpServers": {
      "atlassian": {
        "command": "npx",
        "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp/authv2"]
      }
    }
  }

Browse other hosted servers like this one at /remote-mcp-servers.

Community server setup (sooperset/mcp-atlassian)

The community server is a local process. The README’s quick start uses uvx (Python’s npx-equivalent); Docker and pip installs are also documented. The Claude Desktop / Cursor config from the README:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://your-company.atlassian.net",
        "JIRA_USERNAME": "[email protected]",
        "JIRA_API_TOKEN": "your_api_token",
        "CONFLUENCE_URL": "https://your-company.atlassian.net/wiki",
        "CONFLUENCE_USERNAME": "[email protected]",
        "CONFLUENCE_API_TOKEN": "your_api_token"
      }
    }
  }
}

Server/Data Center users: set JIRA_URL to your on-prem base URL and replace the username/token pair with JIRA_PERSONAL_TOKEN. Jira-only shops can drop the CONFLUENCE_* block entirely. Beyond stdio, the server ships SSE and streamable-http transports with multi-user support — relevant if you want one shared deployment serving a whole team’s agents instead of per-laptop processes.

Tools walkthrough

The two servers expose similar capabilities under different names. Knowing the exact tool names helps when you’re writing agent prompts or allowlists.

Official server (Rovo MCP) — Jira tools

From Atlassian’s supported-tools reference, grouped the way the docs group them:

• Search: searchJiraIssuesUsingJql — the workhorse. Every “find me…” request compiles to this one tool.
• Read: getJiraIssue, getVisibleJiraProjects, getTransitionsForJiraIssue, getJiraProjectIssueTypesMetadata, getJiraIssueTypeMetaWithFields, lookupJiraAccountId (resolves “assign it to Priya” to an account ID), getIssueLinkTypes, getJiraIssueRemoteIssueLinks.
• Write: createJiraIssue, editJiraIssue, transitionJiraIssue, addCommentToJiraIssue, addWorklogToJiraIssue.

Confluence gets the same treatment (searchConfluenceUsingCql, getConfluencePage, createConfluencePage, updateConfluencePage, comment tools), and the server also exposes Compass component tools, JSM Ops alert tools, Bitbucket Cloud repo/PR/pipeline tools, cross-product searchAtlassian / fetchAtlassian, and Teamwork Graph context tools. Two utility tools matter for debugging: atlassianUserInfo (who am I?) and getAccessibleAtlassianResources (which cloud sites can this token see — the cloudId it returns is a parameter on most other calls).

Community server — Jira tools

sooperset uses snake_case: jira_search (JQL), jira_get_issue, jira_create_issue, jira_update_issue, jira_transition_issue, with confluence_search (CQL) and page CRUD on the Confluence side — 72 tools total per the README, covering boards, sprints, worklogs, and attachments beyond the headline five.

Takeaway: tool parity for everyday Jira work is effectively equal. The official server wins on breadth across Atlassian products; the community server wins on deployment flexibility. Don’t choose on tool lists — choose on auth and hosting.

Recipes

Four workflows that justify the install. All work on either server; tool names below use the official server’s.

Recipe 1 — Sprint triage before standup

Prompt: “Search the current sprint in project PAY for issues that are blocked, flagged, or haven’t moved status in 3+ days. For each, give me assignee, age in column, and the last comment. Rank by risk.” The agent compiles a JQL query, runs searchJiraIssuesUsingJql, pulls comments via getJiraIssue, and hands you a ranked triage table. This is the workflow with the strongest community evidence: an engineering manager on r/ExperiencedDevs (in a thread that drew over a thousand upvotes) described their team’s setup where “most of our tickets are now (initially) generated using Claude + the Atlassian MCP, and that’s allowed us to capture missed requirements up-front.”

Recipe 2 — File a bug from a stack trace

Paste a log excerpt or failing CI output into your agent and prompt: “File a bug in PAY for this. Summary under 80 chars, steps-to-reproduce from the trace, set priority based on whether it’s checkout-path, and link it to the epic PAY-1200. Check for duplicates first.” The duplicate check is one searchJiraIssuesUsingJql call (text-match on the exception class); the filing is createJiraIssue. The agent writes better repro steps from a stack trace than most humans do at 5 p.m. — it has the whole trace in context and no incentive to skip fields.

Recipe 3 — Standup / status summaries

Prompt: “Summarize what changed in project PAY in the last 24 hours: issues that moved status, new bugs, and anything that went to Done. Three bullets per section, mention assignees.” One JQL query per section (status changed AFTER -24h, created >= -24h AND issuetype = Bug, status changed TO Done AFTER -24h) and the model formats the digest. Teams pipe this into Slack via a second MCP server; if you also keep notes in Confluence, the same conversation can write the digest to a page with createConfluencePage.

Recipe 4 — JQL from natural language

JQL — Jira’s SQL-ish query language — is the skill most Jira users never learn. The agent already knows it. Ask: “Which bugs in PAY went into Blocked during the last two days and are still there?” and the model emits and executes:

project = PAY AND issuetype = Bug
  AND status = Blocked
  AND status CHANGED TO Blocked AFTER -2d
ORDER BY priority DESC

Because the tool call returns real results (or a real JQL parse error), hallucinated field names self-correct in one round-trip — the agent reads the error, fixes the query, reruns. Ask it to show the JQL it used and you get a learning loop: copy the query into a saved Jira filter and the agent has effectively taught you JQL.

Limits worth knowing before you commit

• Rate limits are the official server’s sharpest edge. Atlassian doesn’t publish hard MCP numbers, and community reports are consistently grumpy: a thread on Atlassian’s own community forum describes hitting the limit after listing ~30 issues in an epic and being locked out for roughly 30 minutes, with no reset-time information in the error. A r/atlassian thread (“Atlassian MCP server always just 429’s”) reports the same pattern. Plan agent workflows around few, precise JQL calls — not per-issue loops.
• Cloud only (official). No Server/Data Center support, full stop. That’s what the community server is for.
• Admin kill-switches. Org admins control whether the Rovo MCP Server is available and whether API-token auth is allowed. If the OAuth flow fails org-wide, talk to your Atlassian admin before debugging your client.
• Permissions are a floor and a ceiling. The user-scoped model means the agent can never see more than you — but also never less. There’s no built-in way to give the agent a read-only slice of your own access on the official server; if you want that, the community server with a restricted service account is the cleaner pattern.
• Cost: both servers are free. You pay for the Atlassian seats you already have. The practical budget constraint is rate-limit headroom, not dollars.

Troubleshooting

FAQ

Sources

• Atlassian Rovo MCP Server — getting started (endpoint, SSE deprecation, prerequisites): support.atlassian.com/atlassian-rovo-mcp-server
• Authentication and authorization (OAuth 2.1, API token, admin controls): support.atlassian.com — authentication-and-authorization
• Supported tools reference (exact tool names): support.atlassian.com — supported-tools
• Official repo and permission model: github.com/atlassian/atlassian-mcp-server (incl. issue #115)
• Launch announcement (beta, May 2025; Anthropic partnership; Cloudflare hosting): atlassian.com/blog/announcements/remote-mcp-server
• Community implementation (MIT; Cloud + Server/DC): github.com/sooperset/mcp-atlassian · docs at mcp-atlassian.soomiles.com
• Rate-limit reports: Atlassian Community — MCP Server Rate Limits · r/atlassian — “always just 429’s”
• Community adoption signal: r/ExperiencedDevs — “AI is working great for my team”
• First-party X post: @Atlassian, March 2, 2026
• Canonical MCP.Directory entries: /servers/jira · /servers/atlassian-jira-confluence · /servers/atlassian-cloud · /servers/jira-confluence