When you connect the Atlassian Rovo MCP URL, MCP Manager’s authentication
detection lands on Standard OAuth (dynamic client registration).
You don’t supply any keys — you just approve the Atlassian consent screen and pick the site(s) to authorize.
This guide is a convenience based on Atlassian’s setup at the time of writing. Atlassian’s own Rovo MCP Server
documentation is
authoritative and may be more current. The requirements below — the remote URL, admin enablement, and which products are exposed — come from
Atlassian, not from MCP Manager. If a step here has drifted or a connection problem is specific to how Atlassian works, Atlassian support is the
fastest path to an answer.
This guide covers Jira, Confluence, and Compass over OAuth. Bitbucket Cloud is not included — its tools authenticate only with a scoped API
token, not OAuth, and require extra admin setup (an org-linked workspace and API-token authentication enabled for the Rovo MCP server). If you’ve
connected here and don’t see any Bitbucket tools, that’s expected. See Connect Bitbucket.
What each authentication method unlocks
The Rovo MCP server accepts two authentication methods, and they reach different parts of the Atlassian ecosystem. This guide uses OAuth 2.1; the Bitbucket guide uses a scoped API token. Here’s what each unlocks today: How to read it: grey = reachable with either method; purple = OAuth only (Compass); green = API token only (Bitbucket Cloud and Jira Service Management). The OAuth path below covers Jira, Confluence, Compass, and the shared platform tools — for Bitbucket or Jira Service Management, use the API-token path in the Bitbucket guide.Before you start
Most of what you need is on the Atlassian side, and it’s about access rather than credentials. One part requires an organization admin — allowlisting MCP Manager’s callback domain — so line that up first.What you’ll need
- An Atlassian Cloud account with access to the Jira, Confluence, or Compass sites you want to reach. The Rovo MCP server respects your existing Atlassian permissions — it can only see what your account can already see.
- The site(s) you intend to authorize. A single Atlassian account can belong to several Cloud sites; you choose which ones to grant during the consent flow.
- An Atlassian login you can complete in a browser — the approval is an interactive, browser-based OAuth 2.1 flow.
Allowlist MCP Manager’s callback domain
For the OAuth approval to succeed, an organization admin must allowlist the domain MCP Manager’s callback comes from. Atlassian’s Rovo MCP server uses a domain allowlist to decide which AI tools may connect over OAuth 2.1 — if MCP Manager isn’t on it, the consent screen can still appear, but the connection fails. This is a one-time setup for the whole organization:1
Open the Rovo MCP server settings
Go to admin.atlassian.com and select your organization. In the left sidebar, open Apps → AI settings → Rovo MCP
server (in some organizations this lives under Rovo → Rovo MCP server).
2
Add MCP Manager's callback domain
Under Allowed domains, click Add domain, paste MCP Manager’s OAuth callback URL, and save:
MCP Manager OAuth callback
3
Confirm the exact value in MCP Manager
The callback URL for your instance is shown in MCP Manager under Settings → Security → OAuth
Callback. Copy it from there to be certain it matches before saving it in Atlassian.
Removing this domain from the allowlist immediately revokes access for all users connecting through MCP Manager. If your organization also
enforces an IP allowlist, the admin must also allow MCP Manager’s egress IPs — find the current list at MCP Manager’s IP
ranges (machine-readable JSON) — or the
OAuth flow and later tool calls will be blocked. Both are Atlassian-side controls — see Control Atlassian Rovo MCP server
settings.
Connect the server
1
Confirm the callback domain is allowlisted
Before connecting, make sure an admin has allowlisted MCP Manager’s callback domain in the Rovo MCP
server settings — and, if your organization enforces an IP allowlist, permitted MCP Manager’s egress traffic. Without it, the OAuth approval will
fail. This is an Atlassian-side requirement, not an MCP Manager one.
2
Open the Servers page and add a server
On the Servers page, add a server to begin a new connection.
3
Paste the remote MCP URL and click Continue
Paste Atlassian’s remote MCP server URL, then click Continue to trigger discovery:Newer OAuth 2.1 clients may use the equivalent
Atlassian Rovo MCP URL
https://mcp.atlassian.com/v1/mcp/authv2 endpoint. Both reach the same Rovo MCP server; use the
URL Atlassian’s current docs list for OAuth clients.4
Approve the Atlassian consent screen
Detection resolves to Standard OAuth (dynamic client registration), so MCP Manager redirects you to Atlassian’s browser-based OAuth 2.1 flow.
Sign in if prompted, then approve the consent screen. You provide no keys at this step.
5
Choose the site(s) to authorize
During the flow, pick which Atlassian Cloud site(s) and resources to grant. Authorization is per user and bounded by your existing permissions — the
server only exposes the Jira projects, Confluence spaces, and Compass components your account can already access.
6
Finish in MCP Manager
After you approve, MCP Manager stores the resulting OAuth token encrypted and attaches it to every request it makes to Atlassian. The server’s tools
are now available to add to a gateway.
Gotchas & things to keep in mind
- Admin enablement is the most common blocker. OAuth approval fails if your Atlassian organization hasn’t enabled the Rovo MCP server or hasn’t allowlisted the connecting domain. Removing a domain from the allowlist immediately revokes access for all users — confirm enablement before you connect.
- Access is per user and permission-bound. Each person authenticates with their own Atlassian account, and the server can only reach what that account already can. Granting the connection never widens anyone’s Jira, Confluence, or Compass permissions.
- Pick the right site(s) during consent. One Atlassian account can span multiple Cloud sites. If a project or space is missing after connecting, the most likely cause is that its site wasn’t selected during the OAuth flow — reconnect and authorize it.
- IP allowlists apply to MCP Manager’s egress. If your organization restricts inbound connections by IP, Atlassian needs MCP Manager’s egress traffic permitted, or the OAuth flow and subsequent calls will be blocked. This is an Atlassian-side network control.
- Per-user OAuth means per-user identity. Because each user approves their own consent, every action is attributable to that individual rather than a shared service account. See per-user versus shared identity for how this maps to gateway identities.
- Bitbucket Cloud isn’t part of this connection. OAuth exposes Jira, Confluence, and Compass only. Bitbucket tools require a separate API-token connection and extra admin setup — see Connect Bitbucket.
Further reading
Connect Bitbucket
Bitbucket Cloud rides on the same Rovo MCP server but needs a scoped API token and extra admin setup — covered separately.
Find & Connect MCP Servers
How MCP Manager detects authentication type, and how to find other servers’ URLs.
How MCP Manager authenticates
The OAuth flow Atlassian Rovo uses, in depth, plus per-user versus shared identity.
Identities for remote servers
How the OAuth credential you just approved is secured and made available.
Connect your AI client
Point Claude, Cursor, or another client at the gateway once the server is connected.
External sources
Getting started with the Atlassian Rovo MCP Server
Atlassian’s authoritative reference for the remote MCP server — the URL, supported products, and admin enablement.
Authentication and authorization
Atlassian’s detail on the OAuth 2.1 flow, dynamic client registration, and per-user consent.