Skip to main content
Atlassian’s Rovo MCP server connects with a single OAuth approval. It authenticates with standard OAuth 2.1 and dynamic client registration, so you paste the remote URL, click Continue, and approve a consent screen — you bring no client ID, secret, or token. The server exposes Jira, Confluence, and Compass, scoped to your own Atlassian permissions.
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.

Before you start

Most of what you need is on the Atlassian side, and it’s about access rather than credentials:
  • 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.
  • Rovo MCP server access enabled for your organization. An Atlassian organization admin controls this from the Rovo MCP server settings page in Atlassian Administration, where they allowlist the domains permitted to connect. If access is off, the OAuth approval will fail until an admin turns it on.
  • 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.
You bring nothing to paste beyond the URL. There’s no OAuth app to register and no client ID or secret to create — Atlassian’s server handles client registration automatically for allowlisted domains, so the only manual step is approving the consent screen.

Connect the server

1

Confirm Atlassian admin enablement

Check with an Atlassian organization admin that Rovo MCP server access is enabled and the connecting domain is allowlisted under the Rovo MCP server settings in Atlassian Administration. If your organization enforces an IP allowlist, the admin must also permit MCP Manager’s egress traffic. 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:
Atlassian Rovo MCP URL
https://mcp.atlassian.com/v1/mcp
Newer OAuth 2.1 clients may use the equivalent 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.
Atlassian productWhat Rovo exposes
JiraSearch, read, create, and update issues
ConfluenceSearch and read pages, create and update content
CompassSearch and read components, run cross-product searches
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.

Further reading

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.