Atlassian MCP Server Cursor IDE Setup (2026)

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

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): Community npx Server with an API Token

If your org can't use the OAuth flow (locked-down browser policies, headless environments) or you specifically want a scoped, per-product token instead of one OAuth grant covering everything, a community npx-based server with an API token is the fallback:

1. Go to id.atlassian.com/manage-profile/security/api-tokens
2. Click Create API token, name it "Cursor MCP," and copy it

{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-atlassian"],
      "env": {
        "ATLASSIAN_URL": "https://your-domain.atlassian.net",
        "ATLASSIAN_EMAIL": "your@email.com",
        "ATLASSIAN_API_TOKEN": "your-api-token-here"
      }
    }
  }
}

Replace your-domain, your@email.com, and your-api-token-here with your actual values. Community package names and maintainers shift over time in this corner of the ecosystem — verify current npm activity before standardizing a team config on one.

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. Your only option there is the community npx server with an API token (Step 2), and even that depends on whether your Data Center instance exposes a REST API surface compatible with the community package — test with a read-only query before you commit a team config to it.

Combining With Other MCP Servers

For maximum productivity, combine Atlassian MCP with other servers:

{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-atlassian"],
      "env": {
        "ATLASSIAN_URL": "https://your-domain.atlassian.net",
        "ATLASSIAN_EMAIL": "your@email.com",
        "ATLASSIAN_API_TOKEN": "your-api-token"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    }
  }
}

Now Cursor can cross-reference your Jira tickets with GitHub PRs automatically.

Troubleshooting

"Server failed to start" — Check your API token is correct and hasn't expired.

"Permission denied" — Make sure your Atlassian account has API access enabled.

Jira not returning results — Verify your ATLASSIAN_URL ends with .atlassian.net and doesn't have a trailing slash.

Confluence works but Bitbucket doesn't (or vice versa) — A single Atlassian API token doesn't automatically mean access to every product. Confirm the account tied to the token actually has a license/seat for the product that's failing — a token can authenticate fine and still get empty results if the underlying account has no Bitbucket access.

Wrong Atlassian site connected — If you belong to more than one Atlassian organization (common if you're an external contractor or agency), double-check ATLASSIAN_URL points at the exact site you meant. Tokens are tied to your Atlassian account, not a single site, so a typo'd subdomain silently connects you to the wrong org's data instead of erroring out.

OAuth browser window doesn't open, or "something went wrong" after clicking approve — This is a reported issue on some Cursor builds connecting to the official Rovo endpoint. 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: Add the server twice under different keys in mcp.json, each with its own ATLASSIAN_URL, email, and token. Give each entry a distinct name (e.g., atlassian-clienta, atlassian-clientb) so Cursor — and you, reading the tool list — can tell them apart.

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 older community npx 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. If your org runs Jira or Confluence Data Center, use the community npx server with an API token instead, and confirm your instance's REST API surface is compatible before relying on it for write operations.

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.

Related Guides

---