Jira (Atlassian) MCP Server
The Atlassian Rovo MCP Server exposes 72+ tools across Jira, Confluence, and Compass to any MCP client. OAuth 2.1 with Dynamic Client Registration (no Atlassian app to register), all actions respect your existing project permissions. Built for QA chat assistants that generate acceptance criteria, triage bug reports, and pull sprint reports — without context-switching.
https://mcp.atlassian.com/v1/sse is being retired after 30 June 2026. If you set up Jira MCP before Feb 2026, you're likely on the legacy URL. Switch to https://mcp.atlassian.com/v1/mcp/authv2 (streamable HTTP). Most older guides on the internet still show the deprecated SSE URL.The Atlassian Rovo MCP Server is Atlassian's cloud-hosted MCP endpoint. It bridges your Atlassian Cloud site (Jira + Confluence + Compass) with any MCP client. It hit GA in February 2026, with Claude as the first launch partner.
- • OAuth 2.1 + Dynamic Client Registration (DCR): your MCP client auto-registers with Atlassian on first connect. No app to create in Atlassian admin, no client_id to manage. This is unusual — most enterprise OAuth flows require admin to pre-register the app.
- • Permissions follow the user: the AI can only read what you can read, only edit what you can edit. Project-level roles, page restrictions, all enforced.
- • API token fallback: useful when DCR isn't supported by your client (older versions).
All configs target the GA endpoint. If you set things up before Feb 2026, update from /v1/sse to /v1/mcp/authv2.
Claude Code (CLI)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
On first call Claude opens a browser tab for OAuth. Approve access to your Atlassian site. Done.
Cursor
Edit ~/.cursor/mcp.json:
{
"mcpServers": {
"atlassian": {
"type": "http",
"url": "https://mcp.atlassian.com/v1/mcp/authv2"
}
}
}Claude Desktop
Claude Desktop's native HTTP MCP is still flaky for OAuth flows. Use the mcp-remote proxy:
{
"mcpServers": {
"atlassian": {
"command": "npx",
"args": [
"-y",
"mcp-remote@latest",
"https://mcp.atlassian.com/v1/mcp/authv2"
]
}
}
}VS Code (with Copilot)
{
"servers": {
"atlassian": {
"type": "http",
"url": "https://mcp.atlassian.com/v1/mcp/authv2"
}
}
}Tool names are stable across the API. Common ones below — the full list is exposed by the server itself (your client's /tools command).
| Product | Tools | Example names |
|---|---|---|
| Jira | 40+ | searchJiraIssuesUsingJql, createJiraIssue, transitionJiraIssue, addCommentToJiraIssue, getJiraIssue, editJiraIssue, getAccessibleAtlassianResources |
| Confluence | 25+ | getConfluencePage, searchConfluence, createConfluencePage, updateConfluencePage, getConfluenceSpaces |
| Compass | 5+ | listComponents, getComponent, createComponent (DevEx catalog) |
JQL is the killer feature: searchJiraIssuesUsingJql takes any JQL string. This is how every advanced QA workflow gets built — your assistant writes JQL, fetches issues, reasons over them, optionally writes back.
Atlassian's Rovo MCP is Cloud only. If you're on Jira Data Center or self-hosted Server, the community-maintained sooperset/mcp-atlassian is the standard choice. It supports both Cloud and Data Center via Personal Access Tokens.
{
"mcpServers": {
"atlassian": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "CONFLUENCE_URL",
"-e", "CONFLUENCE_USERNAME",
"-e", "CONFLUENCE_API_TOKEN",
"-e", "JIRA_URL",
"-e", "JIRA_USERNAME",
"-e", "JIRA_API_TOKEN",
"ghcr.io/sooperset/mcp-atlassian:latest"
],
"env": {
"CONFLUENCE_URL": "https://confluence.your-corp.com",
"JIRA_URL": "https://jira.your-corp.com",
"JIRA_USERNAME": "your.email@corp.com",
"JIRA_API_TOKEN": "<PAT>",
"CONFLUENCE_USERNAME": "your.email@corp.com",
"CONFLUENCE_API_TOKEN": "<PAT>"
}
}
}
}Not maintained by Atlassian. Track the project on GitHub for security advisories. Use a read-only PAT scoped to the projects you actually need.
The OAuth model makes blast radius equal to your own permissions — but if you're a project admin, so is the AI. The matrix below ranks the tools you'll actually hit.
| Tool | Risk | What can go wrong |
|---|---|---|
| searchJiraIssuesUsingJql | 🟢 Read | Respects project permissions. Safe even with full-access token. |
| getJiraIssue / getConfluencePage | 🟢 Read | Returns only what the OAuth user can already see. |
| addCommentToJiraIssue | 🟡 Write (low) | Posts visible comment under your user. Reversible by deleting. |
| createJiraIssue | 🟡 Write (low) | Creates real ticket. Stakeholders get notifications. |
| editJiraIssue / updateConfluencePage | 🟠 Write (medium) | Mutates existing content. Confluence keeps version history; Jira field history is patchy. |
| transitionJiraIssue | 🟠 Write (medium) | Moves ticket through workflow (e.g. Open → Done). Can trigger automations and SLA timers. |
| deleteJiraIssue | 🔴 Destructive | Hard delete on most plans. Recovery requires admin restore. Never enable for chat agents. |
- 1. Use a dedicated Atlassian account (e.g.
qa-bot@corp.com) with role Viewer on most projects, Reporter only on the QA project where ticket creation is expected. - 2. For read-only chat: API token of the bot user with read scope; never use a project admin token.
- 3. In every system prompt: "Do not transition issues, do not delete content. If you would mutate state, post a comment proposing the action instead."
- 4. Audit log: Atlassian logs every MCP-driven action under the bot user — easy to review.
Replace {ISSUE-KEY}, {PROJECT}, {SPRINT-ID} with your values.
Acceptance Criteria from User Story
Read a Jira story, propose Given/When/Then acceptance criteria, save them back as a comment for the PO to review.
Use the Jira MCP to fetch issue {ISSUE-KEY}.
1. Read summary, description, and any attached design links.
2. Identify the user role, the goal, and the success measure.
3. Generate 3-7 acceptance criteria in Gherkin format (Given/When/Then), covering happy path + 2 negative scenarios.
4. Format as a markdown bullet list under a heading "Proposed acceptance criteria — please review".
5. Use addCommentToJiraIssue to post the criteria as a comment. Do not transition the ticket.Bug Report Triage (deduplicate)
Scan recent bugs, group duplicates, normalize severity, surface candidates for closure as duplicates.
Use Jira MCP to find all issues created in the last 14 days where type = Bug and status = "To Do" in project {PROJECT}.
For each new bug:
1. Use searchJiraIssuesUsingJql to find issues with similar summary or affected component (JQL: 'project = {PROJECT} AND type = Bug AND (summary ~ "<keyword>" OR component = <c>)').
2. Group reports that describe the same root cause.
3. For each group, pick the oldest as the canonical issue; mark the rest as candidates to be closed as duplicates.
4. Build a markdown report: "Canonical issue | Duplicate candidates | Confidence (high/med/low) | Recommended action".
Do not edit, transition, or comment on any issue. Output only.Sprint Retro Brief
Pull data on a closed sprint, summarize what shipped, what slipped, what got added mid-sprint.
Use Jira MCP to summarize sprint {SPRINT-ID} for project {PROJECT}.
1. Fetch all issues in the sprint (JQL: 'sprint = {SPRINT-ID}').
2. Bucket them:
- "Completed" — status = Done at sprint close
- "Slipped" — still open at sprint close
- "Added mid-sprint" — created after sprint start date
- "Removed" — removed from sprint before close (via changelog if available)
3. For each bucket, summarize: count, story-point total, top 3 issues by points.
4. Identify the biggest single-ticket carry-over and propose a 1-sentence root cause guess.
Format as a retro brief ready to paste into Confluence. Do not modify Jira data./v1/mcp/authv2 — the legacy /v1/sse endpoint stops working after 30 Jun 2026 and may already be unreliable.getAccessibleAtlassianResources tool first to list your cloudIds, then pass the correct one in subsequent calls.Does it work with self-hosted Jira (Data Center / Server)?
Atlassian's Rovo MCP server is Cloud-only. For Jira Data Center / Server, use the community server sooperset/mcp-atlassian — it supports both Cloud and Data Center via PAT. It's not maintained by Atlassian but it's the de-facto standard for self-hosted teams.
What's the difference between OAuth 2.1 and API token?
OAuth 2.1 (recommended) uses Dynamic Client Registration — your client auto-registers with Atlassian on first connect, no app to create in Atlassian admin. API tokens are simpler to set up but a single token has full account scope; OAuth scopes can be narrowed. After 30 Jun 2026 the old /v1/sse endpoint is dropped — make sure your client uses /v1/mcp/authv2.
Can the AI accidentally close tickets or transition workflows?
Yes — transitionJiraIssue is a write tool and is enabled by default. The OAuth scope and your Jira project role gate it, but if you have permission, the AI does too. For QA chat assistants, prompt explicitly 'do not transition issues' and consider issuing a token with scope project:read only.
Does it index attachments and design files?
Confluence page content (text) is fully indexed and searchable. Attachments are referenced by URL but not OCR'd — the AI can fetch the URL but won't 'see' image content unless your client has a vision model. Figma/Miro links are returned as-is.