Atlassian MCP Server Cursor IDE Setup 2026: Jira, Confluence & Bitbucket in One Config

What's the Atlassian (Jira + Confluence + Bitbucket) MCP server setup for Cursor IDE in 2026? Add one mcpServers entry pointing at https://mcp.atlassian.com/v1/mcp/authv2, restart Cursor, and authorize it via OAuth in your browser — no API token needed for most setups. This single connection gives your AI assistant access to Jira, Confluence, Bitbucket, and Compass together, instead of running three separate MCP servers. If you only need one product, the dedicated single-product guides (linked below) are lighter; this page covers the combined configuration, including the parts most guides skip: what happens when your org runs Data Center instead of Cloud, and how OAuth consent scoping actually works when you belong to more than one Atlassian site.

What You Can Do With Atlassian MCP + Cursor

A representative combined prompt: "Read the Confluence spec for the checkout flow, find the Jira ticket for the refund edge case, and tell me if the current implementation in /src/checkout/refunds.ts covers everything the ticket describes." That single request touches Confluence search, Jira issue lookup, and your local files in one pass — the kind of cross-referencing that's tedious enough over separate browser tabs that most people just skip it.

Prerequisites

Step 1: Add the Official Atlassian Remote MCP Server (Recommended)

Atlassian ships its own hosted MCP server — the Rovo MCP Server — at mcp.atlassian.com. It's OAuth-based, so there's no API token to generate or paste into a config file for the standard flow. This is the setup Atlassian's own docs recommend over the older community npx packages.

Open Cursor's MCP settings (Cmd/Ctrl + , → search "MCP" → Edit MCP Settings) and add:

{
  "mcpServers": {
    "Atlassian-MCP-Server": {
      "url": "https://mcp.atlassian.com/v1/mcp/authv2"
    }
  }
}

If you're on an older Cursor build that doesn't support a direct url entry, use the mcp-remote proxy instead:

{
  "mcpServers": {
    "Atlassian-Rovo-MCP": {
      "command": "npx",
      "args": ["mcp-remote@latest", "https://mcp.atlassian.com/v1/mcp/authv2"]
    }
  }
}

Restart Cursor. On first connection, it opens a browser window for you to sign in and authorize access to your Atlassian site — approve it, and the credential is cached for future sessions (no token to rotate manually). Some Atlassian admins also enable optional API-token auth alongside OAuth; check with your admin if the browser flow is disabled in your org.

Step 2 (Alternative): API Token Instead of OAuth

Use this only when a browser consent screen isn't possible — CI, bots, headless environments — or your org's security policy prefers a scoped, individually-revocable token over one OAuth grant. There is no separate community npx package for this: it's the same hosted Rovo MCP Server, just authenticated differently, on the /v1/mcp path rather than /v1/mcp/authv2. An organization admin must have API-token auth enabled for Rovo MCP first — if they haven't, a token in mcp.json won't connect no matter how correctly it's formatted.

1. Go to id.atlassian.com/manage-profile/security/api-tokens
2. Click Create API token, name it "Cursor MCP," and copy it. New tokens expire in 1 to 365 days.
3. Encode your-email@company.com:your-api-token as base64 for a personal token, or use a service-account key with the Bearer scheme instead of Basic.

{
  "mcpServers": {
    "atlassian-token": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Basic YOUR_BASE64_EMAIL_COLON_TOKEN"
      }
    }
  }
}

Two documented gotchas on this path: personal tokens use the Basic scheme (base64 of email:token), while service-account API keys use Bearer — sending a personal token as Bearer instead of Basic is a common cause of "authenticated but empty tool list." And tokens aren't bound to a single cloudId the way an OAuth session is, so a multi-site account needs to pass the right cloudId explicitly on tools that require one, or risk querying the wrong site's data. Don't commit a config file with a live header value — interpolate from your environment, or keep the token in the global (not project) mcp.json.

Step 3: Restart Cursor and Test

1. Restart Cursor completely
2. Open the AI chat panel (Cmd/Ctrl + L)
3. Try: "List my open Jira tickets"

If it works, you'll see your actual Jira issues returned in the chat. With the OAuth route, you may be prompted to authorize in-browser the first time a tool actually gets called, not just on server startup.

Useful Prompts to Try

Configuration Reference: What Each Piece Actually Controls

The full mcpServers block for the official route only has two meaningful parts, but it's worth knowing what each one does before you copy-paste it into a shared team config:

{
  "mcpServers": {
    "Atlassian-MCP-Server": {
      "url": "https://mcp.atlassian.com/v1/mcp/authv2"
    }
  }
}

Self-Hosted (Data Center) Atlassian: Not Supported by the Remote Server

This is the caveat most setup guides skip. The official Remote MCP Server at mcp.atlassian.com is a Cloud-only product — it authenticates against Atlassian's cloud identity system and has no path to an on-prem Jira/Confluence Data Center instance behind your company VPN. If your org still runs Data Center, the official OAuth route in Step 1 simply won't have anything to connect to, and the API-token route in Step 2 is also Cloud-only — there is no supported community package this page will point you at for Data Center, since compatibility with an on-prem REST surface varies too much to document generically here.

What Changed in 2026 (Read This Before Debugging a "Working" Config)

Two dated facts explain almost every "this used to work" report on this server:

The /v1/sse path is retired. Atlassian's IDE setup documentation states that after 30 June 2026, the old /v1/sse endpoint on mcp.atlassian.com is no longer supported. If a saved mcp.json still points at an sse URL from an earlier tutorial, the fix is the endpoint in Step 1 above, not your Atlassian permissions — a stale endpoint fails the same way a permissions problem does, with no useful error message.

OAuth registration moved on 27 May 2026. Atlassian's Rovo MCP changelog documents Dynamic Client Registration moving to a different authorization server (Atlassian Identity) on that date. A pre-migration OAuth session that was cached before the move won't be recognized afterward. If a working connection suddenly stops authenticating, clear the saved OAuth state for the Atlassian server in Cursor and re-run the consent flow rather than assuming your account lost access.

Neither change affects the API-token path in Step 2, since that authenticates over a header rather than a cached OAuth session.

Combining With Other MCP Servers

A common pairing is Atlassian for tickets and docs, GitHub for code, so Cursor can move between "what does this PR change" and "which Jira ticket does it close" in one session. Both servers authenticate independently — an OAuth session for one, a GitHub PAT for the other — and live as separate entries under the same mcpServers key:

{
  "mcpServers": {
    "Atlassian-MCP-Server": {
      "url": "https://mcp.atlassian.com/v1/mcp/authv2"
    },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_MCP_PAT}"
      }
    }
  }
}

With both green in Settings → MCP, a single prompt like "read PR #212, then find the Jira ticket it closes and check whether the PR covers all the acceptance criteria" resolves into separate tool calls against each server. See the GitHub MCP Server Cursor IDE Setup guide for GitHub-specific toolset and PAT-scoping details this page doesn't repeat.

Troubleshooting

Server never appears in Cursor. Confirm the config file is .cursor/mcp.json or ~/.cursor/mcp.json, the top-level key is mcpServers — not servers, which is VS Code's schema and a common copy-paste source — and the JSON is valid. One syntax error drops every server defined in that file, not just this one.

"Server failed to start" or the connection times out. On the OAuth route, confirm you're using the current authv2 path, not an old sse URL saved from a pre-June-2026 tutorial (see "What Changed in 2026" above). On the token route, confirm the token hasn't expired — personal tokens last 1 to 365 days depending on what you set at creation.

OAuth completed before, but the server won't authenticate now. This is almost always the 27 May 2026 Dynamic Client Registration migration described above. Clear the cached OAuth state for the Atlassian entry in Cursor's MCP settings and re-run the consent flow — a session authorized before that date isn't recognized by the new authorization server.

"Permission denied" or an empty tool list on the token route. Two common causes: a personal token sent with the Bearer scheme instead of Basic (personal tokens use Basic; only service-account keys use Bearer), or an org admin who hasn't enabled API-token auth for Rovo MCP at all — in which case no token, correctly formatted or not, will connect.

Confluence or Bitbucket tools missing even though Jira works. A single OAuth grant or API token authenticating successfully doesn't guarantee access to every product — confirm the underlying Atlassian account actually has a license/seat for the product that's coming up empty. JSM and Bitbucket Cloud tools are API-token-only on Atlassian's supported-tools page; Compass is OAuth-only. A token-based connection querying Compass, or an OAuth connection expecting Bitbucket tools that need a token, will look like a permissions bug but is actually a wrong-auth-path-for-that-product issue.

Wrong Atlassian site connected. If your account belongs to more than one Atlassian Cloud site — common for consultants and agencies — the OAuth consent screen lets you pick a site per connection. On the token path, tokens aren't bound to a single cloudId; call getAccessibleAtlassianResources first to confirm which site and cloudId a given tool call is actually targeting rather than assuming.

OAuth browser window doesn't open, or "something went wrong" after clicking approve. Try the mcp-remote proxy config from Step 1 instead of the direct url entry, confirm Node.js 18+ is installed, and check that your Atlassian site admin hasn't disabled third-party OAuth app access.

Frequently Asked Questions

Q: What's the actual difference between the official OAuth server and running separate Jira/Confluence/Bitbucket community servers?
A: The official Rovo MCP Server at mcp.atlassian.com gives you Jira, Confluence, Bitbucket, and Compass through one OAuth-authorized connection — no tokens to generate or rotate. Dedicated single-product servers (community, token-based) are lighter-weight if you genuinely only touch one product, and can be easier to lock down with a narrowly-scoped token. Teams using all three products daily generally get more value from the combined OAuth connection; single-product teams often prefer the dedicated Jira or Confluence guide instead.

Q: Does one API token really work across Jira, Confluence, and Bitbucket?
A: Yes, as long as the Atlassian account behind the token has access to all three products in your organization. If your account only has a Jira seat and no Bitbucket license, the Bitbucket tools will authenticate but return empty or permission-denied results — that's an account licensing issue, not a config bug.

Q: Can I scope this server to only Jira and Confluence, and skip Bitbucket entirely?
A: The server itself typically exposes all three tool sets once connected; you can't disable one at the config level in most versions. What you can do is simply not use the Bitbucket-related prompts — the unused tools sit idle and don't cause errors.

Q: I run multiple Atlassian Cloud sites (e.g., separate orgs for two clients) — can I connect to both at once?
A: Yes. On the OAuth route, add the server twice under different keys pointing at the same authv2 URL (e.g. Atlassian-ClientA, Atlassian-ClientB) and pick the correct site on each entry's own consent screen — OAuth sessions are independent per entry, so authorizing one doesn't affect the other. On the API-token route, add two entries with different keys, each with its own Authorization header value if the two sites use different tokens; tokens aren't bound to a single cloudId, so pass the right cloudId explicitly per call if one token happens to cover both.

Q: Is there an actual Atlassian-maintained server, or is everything community-run?
A: There is — the Rovo MCP Server (mcp.atlassian.com) is Atlassian's own hosted, OAuth-based server, not a community project. It's the setup covered in Step 1 above and is what Atlassian's support docs recommend by default. Community npx packages with API-token auth (Step 2) still work and remain useful for headless environments where an interactive OAuth flow isn't practical, but they're a fallback rather than the primary path now.

Q: What's the full Atlassian MCP server configuration for Cursor IDE, start to finish, in 2026?
A: Four things: add the url-only mcpServers block from Step 1 pointing at https://mcp.atlassian.com/v1/mcp/authv2, restart Cursor completely, trigger the OAuth browser prompt by calling a tool (e.g. asking it to list Jira tickets), and approve access to the correct site if you belong to more than one. There's no token to generate and no site URL to type into the config for this route — that's the main difference from the API-token setup in Step 2.

Q: Does the Atlassian MCP server work with a self-hosted Data Center instance?
A: No, not the official Remote MCP Server — it's Cloud-only. Neither the OAuth route (Step 1) nor the API-token route (Step 2) connects to an on-prem Jira or Confluence Data Center instance; both authenticate against Atlassian's cloud identity system.

Q: Is "Atlassian Jira MCP server" setup different from just "Atlassian MCP server" setup?
A: Not in terms of config — they're the same mcpServers entry. "Atlassian Jira MCP server" is usually how people search when Jira tickets are the specific thing they want working, even though the connection in Step 1 also brings Confluence and Bitbucket along for free. If Jira is genuinely all you need, the dedicated Jira-only guide documents just that surface with Jira-specific troubleshooting, without the Confluence/Bitbucket tool clutter in the AI's tool list.

Q: Did the Atlassian MCP server endpoint actually change in 2026?
A: Yes, twice. The old /v1/sse path stopped being supported after 30 June 2026 — use the authv2 URL from Step 1 instead. Separately, OAuth Dynamic Client Registration moved to Atlassian Identity on 27 May 2026, which means a connection authorized before that date needs its cached OAuth state cleared and re-consented, not just a config fix.

Related Guides