What's the actual difference between Rovo MCP Server and mcp-atlassian?

Rovo MCP Server is Atlassian's own, officially-hosted remote server — you authenticate with OAuth 2.1, Atlassian runs the infrastructure, and it's covered by their support and security controls. mcp-atlassian (sooperset/mcp-atlassian on GitHub) is an independent, open-source project you self-host, authenticating with an API token or Personal Access Token against your own site. Same job — bridging Jira/Confluence to an AI client — different ownership, hosting, and auth model.

Is the Rovo MCP Server free?

Yes, currently. Atlassian has stated the server doesn't consume Rovo credits and isn't billed separately as of mid-2026 — it rides on Rovo Search, which is excluded from credit metering. That's a current-state answer, not a permanent guarantee; Atlassian has committed to at least 90 days' notice and an opt-in before any future billing change.

Can I use Rovo MCP Server with Claude, Cursor, or other clients besides Rovo itself?

Yes — that's the whole point of it being MCP. Atlassian's setup docs list Claude (Claude.ai, Desktop, and Code), Cursor, ChatGPT, VS Code with GitHub Copilot, GitHub Copilot CLI, Google Gemini CLI, Amazon Quick Suite, Docker, and Windsurf as supported clients, with one-click install links for most of them.

Does mcp-atlassian work with Jira Server or Data Center, not just Cloud?

Yes, and that's one of its real advantages over the official server. mcp-atlassian supports Jira Server/Data Center 8.14+ and Confluence Server/Data Center 6.0+ via Personal Access Tokens, alongside Cloud via API token or OAuth. The official Rovo MCP Server is Cloud-only.

My MCP client can't connect or shows no data — how do I troubleshoot?

For the official server: re-run the client's connection setup, confirm Jira/Confluence tools are enabled in that session, and re-authenticate if you're seeing empty or partial results (usually an expired token or a scope you didn't approve). OAuth redirect errors are almost always a blocked popup or a firewall blocking localhost — Atlassian's docs specifically call out allowing localhost:3334. For mcp-atlassian, check your API token or PAT is valid and that the account has the right product permissions; it fails the same way any REST integration fails — bad credentials or insufficient scope, not an MCP-specific issue.

Which one should I pick if I'm just setting up Jira access for Claude Code?

Start with the official Rovo MCP Server if you're on Atlassian Cloud — zero maintenance, Atlassian-supported, OAuth means no token to manage, and it's free today. Reach for mcp-atlassian if you're on Server/Data Center (the official server doesn't cover you), need fine-grained tool-level control the official server doesn't expose, or want a self-hosted setup you control end to end.

Rovo MCP Server vs mcp-atlassian: Which to Use

If you’ve searched “atlassian rovo mcp server,” you’ve probably also landed on a Reddit thread asking the same confused question everyone else is asking: is this the same thing as that other Atlassian MCP server people have been running for two years? No official page states the difference plainly, so here it is: Atlassian ships an official, hosted Rovo MCP Server (OAuth 2.1, Cloud-only, free today), and separately the community has run mcp-atlassian — a self-hosted, open-source server with 98 tools, its own maintainers, and Server/Data Center support the official one doesn’t have. Both connect an AI client to your Jira and Confluence data. They are not the same project, and picking between them isn’t obvious from the marketing. This page walks through what each one actually is, how to set each up, and when you’d pick one over the other.

What is the official Atlassian Rovo MCP Server?

It’s Atlassian’s own remote MCP server, generally available since February 4, 2026, connecting Jira, Confluence, Jira Service Management, Bitbucket, and Compass to any MCP-compatible AI client. Atlassian hosts it — you don’t run any infrastructure — at the endpoint https://mcp.atlassian.com/v1/mcp/authv2 (per the getting-started docs; an older /v1/sse endpoint was retired at the end of June 2026, so if you find a setup guide referencing sse, it’s stale — use authv2).

Auth is OAuth 2.1 by default: you sign in with your Atlassian account, approve scopes through a consent screen, and the tool only ever acts within your existing Jira/Confluence permissions. API token auth is also available for service-style, org-level setups that don’t want a per-user prompt (per Understand Atlassian Rovo MCP server), though API tokens are required specifically for Jira Service Management and Bitbucket regardless of which auth mode you’re otherwise using.

Admins get real controls here, not an afterthought: domain and IP allowlisting for which tools can connect, approval of custom client domains, org-wide API token policy, and audit logs. If you’re evaluating this for a team rather than yourself, that governance layer — not the feature set — is usually the actual reason to pick the official server over a self-hosted one.

What is mcp-atlassian, and how is it different?

mcp-atlassian is an independent, MIT-licensed open-source project (no Atlassian affiliation — the README says so explicitly) that’s been the de facto community standard for Jira/Confluence MCP access since before Atlassian shipped an official one. You run it yourself: via uvx, Docker, pip, or from source, pointed at your own Atlassian site through environment variables (JIRA_URL, JIRA_API_TOKEN, CONFLUENCE_URL, CONFLUENCE_API_TOKEN, and equivalents for Confluence).

Two differences matter more than the rest:

Auth is yours to manage. Cloud deployments use an API token (or OAuth 2.0 as an option); Server/Data Center deployments use a Personal Access Token. There’s no consent-screen flow — you generate the token, you put it in a config file, it’s your responsibility to rotate and scope it.
It covers Server/Data Center, not just Cloud — Jira 8.14+ and Confluence 6.0+ specifically. This is the single biggest reason to reach for mcp-atlassian over the official server: if your instance isn’t on Atlassian Cloud, the official Rovo MCP Server simply doesn’t apply to you.

It also currently exposes a much larger tool surface (98 tools per its documentation) covering granular JQL search, issue transitions, Confluence page and space management, and more — a byproduct of being community-driven and iterating faster than an enterprise-governed official release.

How do you set up each one?

Official Rovo MCP Server: there’s no separate install step for most clients — Atlassian’s setting-up-clients docs provide one-click connection links for Claude, Cursor, ChatGPT, VS Code with GitHub Copilot, GitHub Copilot CLI, Gemini CLI, and Amazon Quick Suite. You click the link for your client, sign in with your Atlassian account, approve the requested scopes, and you’re connected — no manual JSON config in most cases. For clients without a one-click link, you add the server URL and let the client’s own OAuth flow handle the rest.

mcp-atlassian: you manage the whole stack. A typical Claude Desktop or Cursor config point at a uvx mcp-atlassian command (or a Docker container) with your Jira/Confluence URLs and tokens set as environment variables. There’s no consent screen — the server authenticates with whatever credential you gave it, at whatever scope that credential has.

If you’re already using Rovo Dev, Atlassian’s coding-agent CLI, note it’s a separate product from both of these — Rovo Dev has its own MCP client support for pulling in external tools, which is the inverse direction from what this page covers (getting Jira/Confluence data into an external AI client).

Is the Rovo MCP Server actually free?

Currently, yes. Atlassian has said the MCP server doesn’t draw down Rovo credits and isn’t separately billed — it runs on Rovo Search functionality, which the usage-allowance docs exclude from credit metering. That’s a snapshot of current policy, not a forever-promise: Atlassian has committed to at least 90 days’ notice and an explicit opt-in before introducing any billing for overage usage. If you’re budgeting Rovo spend across your org, this is worth re-checking periodically rather than assuming it’s permanently free — see Rovo pricing and credits explained for the full two-meter model (Rovo credits vs. Rovo Dev credits), and our credit cost estimator if you want to model a team’s draw.

mcp-atlassian has no usage-based cost at all beyond your own infrastructure (running uvx locally is free; a hosted Docker container costs whatever your hosting costs) — its price is the time you spend running and maintaining it yourself.

When should you actually pick one over the other?

Pick the official Rovo MCP Server if: you’re on Atlassian Cloud, you want zero maintenance, you need admin-level governance (allowlisting, audit logs, org policy) for a team rollout, or you’d rather not manage a token yourself. It’s also the only sane choice if you specifically want a remote, always-on server you don’t have to keep running locally.
Pick mcp-atlassian if: you’re on Jira/Confluence Server or Data Center (the official server can’t reach you at all), you want a specific tool the official server doesn’t expose yet, you want to self-host for compliance reasons that require your data path to never leave infrastructure you control, or you’re fine trading OAuth’s convenience for a token you fully own.
A reasonable middle path: many teams on Cloud start with the official server for the zero-setup win, and only reach for mcp-atlassian later if they hit a specific tool-coverage gap. Going the other direction — migrating off a working mcp-atlassian setup just because Atlassian now has an official one — usually isn’t worth the churn unless you specifically need the OAuth/governance layer.

Troubleshooting a failed connection

For the official server, per Atlassian’s troubleshooting doc: verify by asking the client something that requires live data (e.g. “list my Jira issues”) — a working setup returns AI responses referencing real Jira/Confluence content. If you get no response, tools may be disabled in that session; re-run the connection setup. Empty or partial results usually mean an expired token or a scope you didn’t approve — re-authenticate and check the approved-scopes list. OAuth redirect loops are almost always a blocked browser popup or a firewall blocking localhost:3334 — allowlist it and retry.

For mcp-atlassian, the failure modes are the ones you’d expect from any self-hosted REST integration: an invalid or expired API token/PAT, a token missing the right product scope, or a URL pointed at the wrong site. Check your environment variables first — most reported issues trace back to a stale or mis-scoped token, not the MCP layer itself.

Need Jira/Confluence connected to an AI tool and don’t want to be the one debugging the OAuth flow or the token config? We take Rovo agents, MCP setups, and Atlassian customizations from spec to deployed. Configure what you need and see the price and timeline instantly →