Atlassian Rovo MCP: Jira, Confluence and Bitbucket from Your Agent

The Atlassian Rovo MCP server is Atlassian’s official, cloud-hosted MCP endpoint (https://mcp.atlassian.com/v2/mcp) that lets Claude Code, Codex and Cursor read and update Jira, Confluence, Bitbucket, Jira Service Management and Compass. It authenticates with OAuth 2.1 or an admin-enabled API token and never exceeds the Atlassian permissions of the account it signs in as.

This page is for developers who pick up work from Jira and tech leads who configure the connection for a team. You are two days into PROJ-88 when the product manager asks why the export button ignores the date filter. The requirement was added to the Confluence spec after you read it, and nothing in the ticket told you. With the Atlassian server connected, one prompt has the agent re-read the ticket and the spec and tell you which requirements the code does not meet yet.

What you get from connecting Atlassian Rovo MCP

• The current /v2/mcp setup for Claude Code, Codex and Cursor, plus the API-token variant for headless runs and Jira Service Management.
• A decision table: official remote server, the vendor plugin, or sooperset/mcp-atlassian for Server and Data Center.
• A requirements-traceability workflow (Confluence spec → code and tests → Jira comment) with three copy-paste prompts.
• A verification step that proves each requirement is covered by a passing test, so nobody reads the whole diff to find out.
• The traps and failure modes that the vendor README does not group in one place.

Which Atlassian MCP server should you use?

Your situation	Use	Why
Atlassian Cloud, interactive work	Official server at https://mcp.atlassian.com/v2/mcp with OAuth 2.1	Vendor-hosted, no local process, respects each user’s permissions
Claude Code user who wants ready-made workflows	The atlassian plugin from claude-plugins-official	Wires the same /v2/mcp server plus six skills, including spec-to-backlog and triage-issue
Headless agent, CI job or Jira Service Management tools	Official server with an API token	JSM tools accept API tokens only; OAuth needs a browser
Jira or Confluence Server or Data Center	Community server sooperset/mcp-atlassian (PyPI mcp-atlassian 0.23.1), run with uvx	The official server connects to Atlassian Cloud sites only

Popularity as of 2026-09-26: the official atlassian/atlassian-mcp-server repository has about 1.1k GitHub stars, the atlassian plugin shows 92,289 installs on the Claude plugin directory, and the server is listed in the Official MCP Registry under com.atlassian. The community sooperset/mcp-atlassian repository has about 5.9k stars. Stars measure attention, not quality; the official server is the default for Cloud.

Connect the Atlassian Rovo MCP server with OAuth

The endpoint is the same in all three tools. What differs is how each tool registers a remote server and starts the OAuth sign-in.

Claude Code

Run in your terminal:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Then start a session, run /mcp, select atlassian and complete the browser sign-in. Choose the Atlassian site the agent should work on. The command writes to the local scope (this project, only you); add --scope project to commit the entry to .mcp.json for the team, or --scope user for all your projects.

For the plugin instead of the bare server:

claude plugin install atlassian@claude-plugins-official

Check what it costs before you keep it: run claude plugin details atlassian for its component inventory and projected token cost, and compare /context in a session before and after.

Codex

Run in your terminal:

codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp
codex mcp login atlassian

codex mcp login opens the browser for OAuth; add --no-browser on a remote machine to get a URL you open elsewhere. codex mcp list confirms the server is registered. The equivalent ~/.codex/config.toml entry:

[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v2/mcp"

The curated atlassian-rovo plugin in OpenAI’s plugin marketplace still points at https://mcp.atlassian.com/v1/mcp/authv2 (read 2026-09-26). That endpoint is supported and v1 connections now receive v2 tools, but configure the server directly if you want the recommended URL.

Cursor

Atlassian lists an Atlassian plugin on Cursor’s marketplace that bundles the MCP server and its skills. To configure it by hand, add this to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "atlassian": {
      "url": "https://mcp.atlassian.com/v2/mcp"
    }
  }
}

Cursor opens the OAuth sign-in when it first connects. The Cursor details on this page come from Atlassian’s README, not from a test: cursor.com was unreachable when this page was checked.

Confirm the connection before you rely on it. Ask the agent: “List the Jira projects I can see through the Atlassian MCP server.” A list of project keys means the sign-in, site selection and permissions all work.

Traps in older Atlassian MCP instructions

• https://mcp.atlassian.com/v1/sse has been unsupported since 30 June 2026. /v1/mcp and /v1/mcp/authv2 still work, but new setups should use /v2/mcp.
• claude mcp add atlassian https://mcp.atlassian.com/v2/mcp without --transport http is accepted and writes a stdio server whose command is the URL; it fails only at connect time.
• --url is a Codex flag. Claude Code (v2.1.283) rejects claude mcp add --url as an unknown option.
• There is no @atlassian/mcp npm package (the registry returned 404 on 2026-09-26). The official server is remote only.
• npx mcp-remote is a bridge for clients that speak only stdio. Claude Code, Codex and Cursor connect to the remote URL directly and do not need it.

When should you use an API token instead of OAuth?

Use an API token when no one is at a browser to approve OAuth (CI, a scheduled agent, a remote container) or when you need Jira Service Management tools, which the server offers only over API-token authentication. Two conditions apply first:

1. An organization admin must enable API-token authentication in Atlassian Administration → Rovo → Rovo MCP server → Authentication. Until then, token requests fail and only OAuth works.
2. The token needs the scopes for the tools you call. Create a scoped personal API token, or ask the admin for a service-account API key.

The server accepts two headers: Authorization: Basic <base64(email:api_token)> for a personal token and Authorization: Bearer <api_key> for a service-account key. Keep the secret in an environment variable or a secret store, never in a committed file or on a command line.

Claude Code

Build the Basic value once per shell. tr -d '\n' matters: GNU base64 wraps long output, and a newline inside the header breaks authentication.

export ATLASSIAN_BASIC_AUTH=$(printf '%s' "you@example.com:$ATLASSIAN_API_TOKEN" | base64 | tr -d '\n')

Reference it from .mcp.json; Claude Code expands ${VAR} in headers at load time, so the file holds no secret:

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v2/mcp",
      "headers": {
        "Authorization": "Basic ${ATLASSIAN_BASIC_AUTH}"
      }
    }
  }
}

Codex

For a service-account key, let Codex send the bearer header from an environment variable:

codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp --bearer-token-env-var ATLASSIAN_SERVICE_KEY

For a personal token, put the whole header value (Basic …, built as in the Claude Code tab) in a variable and map it in ~/.codex/config.toml:

export ATLASSIAN_AUTH_HEADER="Basic $ATLASSIAN_BASIC_AUTH"

[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v2/mcp"
env_http_headers = { "Authorization" = "ATLASSIAN_AUTH_HEADER" }

A headers = { … } key is silently ignored by codex-cli 0.157.1; the keys are http_headers, env_http_headers and bearer_token_env_var. Run codex mcp get atlassian --json to confirm the header is picked up.

Cursor

Use OAuth or the marketplace plugin in Cursor. Header-based token configuration for Cursor was not verified for this page, because cursor.com was unreachable; for headless runs, use Claude Code or Codex.

Pin the site, project and space so the agent stops searching

Every session otherwise starts with discovery calls: which sites you can access, which projects, which spaces. Atlassian’s README recommends pinning them in AGENTS.md (or CLAUDE.md for Claude Code). This block is theirs, with your values:

## Atlassian MCP

When connected to the Atlassian MCP server:
- MUST use Jira project key = PROJ
- MUST use Confluence spaceId = "123456"
- MUST use cloudId = "https://yourcompany.atlassian.net" (do NOT call getAccessibleAtlassianResources)
- MUST use `maxResults: 10` or `limit: 10` for ALL Jira JQL and Confluence CQL searches.

Replace PROJ, the space ID and the site URL with your own. The search limit keeps large result sets out of the context window.

How does the v2 server keep its context cost down?

The v2 server exposes a small set of primary tools and reaches the rest through discover and execute meta-tools, so the full tool list never lands in context. Two consequences:

• A gateway that needs every tool up front can request https://mcp.atlassian.com/v2/mcp?tools=all. Measure with /context before you adopt it; the flat list costs far more than the primary set.
• Tool names changed between v1 and v2. getConfluencePage became getConfluenceContent, searchConfluenceUsingCql became searchConfluence, and addCommentToJiraIssue became addOrEditJiraIssueComment. A custom skill or prompt that names v1 tools needs updating. Prompts that describe the outcome (“read the page”, “add a comment”) are unaffected.

For the general technique, see reducing MCP token cost.

Trace requirements from Confluence to code to Jira

This workflow turns “did we build what the spec says?” into a table that tests prove, instead of a question someone answers by reading the diff. It is the plan → build → verify → ship loop with the spec and the ticket as the inputs and a Jira comment as the record. For how to write criteria an agent can check, see acceptance criteria for agents.

Step 1: extract the requirements and find the gaps

Start with a prompt that reads but does not write. The agent pulls PROJ-88, follows the Confluence link and compares each requirement to the code.

Copy-paste prompt: list unmet requirements

Read Jira issue PROJ-88 and the Confluence page linked from it (the "Checkout v2 spec").
Do not modify anything in Jira or Confluence.
1. Extract every requirement and acceptance criterion from both. Give each an ID (R1, R2, ...) and quote the source sentence with the page section or ticket field it came from.
2. For each requirement, search src/checkout and its tests. Classify it as MET (name the file and the test that proves it), PARTIAL, or UNMET.
3. Flag any requirement that the ticket and the spec state differently, and any that is too vague to test.
Write the result to docs/traceability/PROJ-88.md as a table: ID | requirement | source | status | code | test.

Step 2: review the matrix, not the code

Read docs/traceability/PROJ-88.md. Resolve every “vague” or “conflicting” row with the product owner before anything is built. This is the only step where a person reads the requirements closely.

Step 3: turn each gap into a failing test, then implement

Tests come first so the evidence exists before the code.

Copy-paste prompt: tests first from the matrix

Using docs/traceability/PROJ-88.md, write one failing test for each PARTIAL or UNMET requirement.
Name each test after its requirement ID (for example "R4: export respects the date filter").
Run the test suite and show me that exactly these new tests fail and nothing else does.
Then implement the changes in src/checkout until all tests pass. Do not edit or delete an existing test to make it pass.
Update the matrix: status, code location and test name for every row.

Step 4: write the evidence back to Jira after CI is green

Writes happen last, and you approve them in the agent’s permission prompt.

Copy-paste prompt: record traceability on the ticket

CI is green on the PROJ-88 branch. Add one comment to Jira issue PROJ-88 containing:
the traceability table from docs/traceability/PROJ-88.md (ID, requirement, status, test name),
the pull request link, and any requirement still not MET with the reason.
Show me the comment text and wait for my confirmation before posting it.
Do not change the issue status; I will move it myself.

In Claude Code, the plugin’s spec-to-backlog skill covers the step before this one: it reads a Confluence spec, shows you a proposed Epic and child tickets, and creates them only after you approve the breakdown. For pull requests and branches in the same loop, pair this server with GitHub MCP or gh; for the Linear and Notion equivalents, see tickets and docs over MCP.

How do you verify the traceability output without reading every line?

The matrix is only useful if each row is backed by something a machine checked. Four checks, in order:

• Every row names a test, and CI runs it. A MET row with no test name is a claim, not evidence. Reject the matrix until each row has one.
• The new tests failed before the change. The step 3 prompt asks for the red run; keep it in the session log or the PR description. A test that never failed may not test the requirement.
• Sample, do not read everything. The reviewer opens two or three rows at random and reads the requirement, the test and the code together. If those hold, trust the rest; if one does not, send the whole matrix back.
• The Jira comment is the audit trail. It records which requirement maps to which test at merge time. Atlassian also logs every MCP tool call in Atlassian Administration → Insights → Audit log, so an admin can check what the agent changed. For a reusable format for this evidence, see the evidence bundle.

Sign-off is split. The product owner approves the requirement list (step 2); the tech lead or the reviewer on the PR approves the test mapping. For review standards beyond this page, see reviewing agent pull requests.

What about Jira Server and Data Center?

The official server works with Atlassian Cloud sites only. For Server or Data Center, use sooperset/mcp-atlassian (supports Jira 8.14+ and Confluence 6.0+ on Server/Data Center) with a personal access token per product. In a Claude Code .mcp.json, reference the tokens from environment variables:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://jira.yourcompany.internal",
        "JIRA_PERSONAL_TOKEN": "${JIRA_PERSONAL_TOKEN}",
        "CONFLUENCE_URL": "https://confluence.yourcompany.internal",
        "CONFLUENCE_PERSONAL_TOKEN": "${CONFLUENCE_PERSONAL_TOKEN}"
      }
    }
  }
}

It needs uv installed, and it runs on the developer’s machine, so its tools see whatever the token can see. Codex and Cursor take the same command and environment variables in their own config formats. The workflow above works unchanged.

When the Atlassian MCP connection breaks

“You don’t have permission to connect from this IP address.” Your organization uses IP allowlisting, and MCP tool calls must come from an allowed address. Ask the admin to add your office or VPN range, or connect from an allowed network. A CI runner with a changing IP will hit this every time; give it a fixed egress IP that is on the list.

OAuth fails for your tool, or the site is not offered. Admins control which AI tools and domains may connect in the Rovo MCP server settings page in Atlassian Administration; OAuth connections from a domain that is not allowed are refused. Ask the admin to allow the client. Individual users can also revoke their own authorizations from their profile, so check that yours is still there.

It worked yesterday on /v1, and sign-in now loops. After the move to v2 tools, some clients keep a cached client ID or .well-known credentials that no longer match. Remove and re-add the server (claude mcp remove atlassian, or codex mcp logout atlassian followed by codex mcp login atlassian) and sign in again, this time on /v2/mcp.

Jira Service Management tools are missing. They exist only with API-token authentication. Under OAuth, the agent cannot see them. Switch that connection to a token, and check that the admin has enabled token auth.

Compass tools vanish after switching to a token. Compass is OAuth-only. Keep one OAuth connection for Compass work if you also need a token connection for JSM.

Bitbucket repositories do not appear. Bitbucket Cloud tools work only for workspaces linked to an Atlassian organization. An unlinked workspace cannot be selected at sign-in.

The agent cannot delete issues or change project settings. The delete_jira and manage_jira permission groups are disabled by default. Leave them off unless an admin has a reason to enable them; an agent rarely needs either.

The agent searches for “Platform Engineering” and finds nothing. JQL uses project keys, not display names. Put the key (PROJ) in the prompt or in the AGENTS.md block above.

A ticket description tells the agent to do something you did not ask. Ticket and page text is untrusted input, and prompt injection through it is a real risk that Atlassian’s own README warns about. Keep write tools behind the permission prompt, never auto-approve Jira or Confluence writes, and read MCP security before you run this server unattended. For transport-level failures that affect every server, see MCP connection issues.

Where to go next with Atlassian and MCP

Tickets and docs over MCP Linear, Jira, Notion and Slack compared, with the ticket-to-PR loop.

GitHub MCP Branches, pull requests and CI logs to close the loop this workflow starts.

Spec-driven development Write specs an agent can implement and a test can check.

MCP registries and gateways Allowlist Atlassian and other servers across an organization.