Atlassian MCP server: setup, admin controls and per-user access

The Atlassian MCP server is Atlassian's official remote MCP server for Jira, Confluence, Compass and other Atlassian Cloud apps. It runs at ^{https://mcp.atlassian.com/v2/mcp}, signs you in through OAuth 2.1 or an admin-enabled API token, and acts as you, so an agent only reaches the Jira work items and Confluence pages you can already see.

For one person in Claude Code, Cursor or Codex, setup is one command and a browser sign-in. The harder parts are the admin controls that decide which AI tools may connect, and giving your own product's agent Jira access for many customers, which needs a different design from single-user MCP integrations.

TL;DR

• Use the v2 endpoint, ^{https://mcp.atlassian.com/v2/mcp}. The v1 endpoints still work, the legacy ^/v1/sse endpoint is no longer supported after June 30, 2026, and on March 1, 2027 existing v1 connections start using v2 tools.
• OAuth 2.1 connections only succeed from domains your organization allows. Atlassian allows a list of supported AI tools by default, such as claude.ai, chatgpt.com and Cursor, and admins add any other domain under Connectors, then Atlassian MCP server.
• Your own product's agent is an OAuth client too, so each customer's admin has to allow its redirect domain, or you go through Atlassian's REST APIs with one authorization per user. Scalekit AgentKit offers both routes and stores each user's tokens.

What the Atlassian MCP server covers

Atlassian's docs and the MCP Registry list it as the Atlassian Rovo MCP Server. It is hosted on Atlassian Cloud and needs an Atlassian Cloud site. Version 2, the current release, adds more tools and products: besides Jira and Confluence, its tool list includes Jira Service Management, Bitbucket Cloud, Loom, Goals, Projects, Teams, Assets, Focus, Talent and the Teamwork Graph.

Tools are grouped into permission groups by product and intent, and admins grant or revoke access per group. The supported tools page lists each tool and the OAuth scope its group needs, such as ^{read:jira:agent-interface}.

Atlassian's GitHub repository lists Compass under OAuth 2.1 only. Bitbucket and Loom tools need their workspaces linked to your Atlassian organization or site.

How tools reach the agent

The server does not send every tool definition when a client connects. It exposes a small set of primary tools, such as ^getJiraIssue, ^{createJiraIssue} and ^{searchConfluence}, plus a ^discover tool that searches the rest of the catalog and three execution tools, ^executeRead, ^executeWrite and ^{executeDestructive}, that run what discover finds. Splitting execution by type lets clients apply confirmation per type. Gateways that need a flat list can use ^{https://mcp.atlassian.com/v2/mcp?tools=all}, which returns every tool as a paginated list.

Every tool call needs a ^cloudId, so agents usually call ^{getAccessibleAtlassianResources} first. Atlassian suggests putting your site URL, Jira project key and Confluence space ID in AGENTS.md to skip that call.

Rovo credits

Atlassian's getting-started guide says calls through the server that retrieve data or generate insights consume Rovo credits from the organization-wide pool shared with Rovo Chat, Studio, Agents and the Teamwork Graph. Larger data pulls and more complex queries use more.

How the server authenticates

OAuth 2.1 is the default and recommended method. A request without a token gets a 401 whose ^{WWW-Authenticate} header points to protected resource metadata at ^{mcp.atlassian.com}, which names an ^{auth.atlassian.com} authorization server. That server supports dynamic client registration, Client ID Metadata Documents and PKCE with S256, so clients register themselves and run the browser consent flow. An OAuth token is typically consented for a specific site, and the server checks that each request targets that site's ^cloudId.

API tokens are the headless option, and an organization admin has to turn them on first. A client sends either a personal API token as ^{Authorization: Basic} with the base64 of ^{email:api_token}, or a service account API key as a bearer token. Atlassian lists three trade-offs:

• Some tools are missing, because certain product scopes, including some Compass scopes, cannot be added to API tokens.
• Tokens are not bound to one site, so every call must pass the right ^cloudId.
• Domain allowlists do not apply, since there is no OAuth redirect. Only IP allowlists and the token's scopes govern the connection.

With a service account key, the audit log shows the service account, not each person who used the tool.

Admin controls that decide whether a connection works

Most of the settings live in Atlassian Administration under Connectors, then Atlassian MCP server. Atlassian's settings guide covers each tab. For a call to succeed, the client's domain must be allowed (for OAuth 2.1), the request must come from an allowed IP address (if you use IP allowlists), and the authentication method must be enabled.

• Domains. Atlassian-supported domains are allowed by default. The list includes ^claude.ai, ^chatgpt.com, ^vscode.dev, ^{mcp.docker.com}, ^{cursor://cursor.mcp} and ^localhost. You can add your own domains or patterns such as ^{https://*.example.com/**}, and you can block the supported list as a whole, though not one domain from it.
• Permissions. The Permissions tab turns Read, Write and Search on or off for each app, and it takes precedence over Connected Apps settings. A blocked user sees "Access denied: Your organization admin has not authorized the write permission." Changes take effect immediately.
• Destructive and admin tools. ^delete_jira and ^manage_jira are off until an admin enables them.
• IP allowlists. These apply to MCP calls too. Hosted AI clients can call from the provider's own outbound IP addresses, so being on your corporate VPN may not be enough.
• Data security policy. With Atlassian Guard Standard, the Atlassian MCP server control in a data security policy can stop AI agents reading covered Jira work items and Confluence pages through the server, even where the user can see them directly. It applies to OAuth connections only.
• Audit log. Every tool call is recorded with the tool name, action and user. Filter for Rovo MCP User Actions under Insights, then Audit log.
• Enterprise-managed authentication. For Claude, admins can hand MCP authorization to Okta through Cross App Access.

A separate Connected apps setting for each site can stop users installing any OAuth app at all.

Add the Atlassian MCP server to Claude Code

Atlassian's plugin is in Anthropic's official marketplace and bundles the server settings with Atlassian's skills, such as triaging an issue or turning a spec into a backlog:

To add only the server, use the command from Atlassian's guide, then start a session, run ^/mcp, select atlassian and sign in through your browser:

Add ^{--scope user} to make it available in every project. If you added a v1 URL earlier, remove that entry with ^{claude mcp remove} and add the v2 URL. Atlassian treats v2 as a separate OAuth resource, so you sign in again.

Add it to Cursor

The Atlassian plugin for Cursor includes the server and Atlassian's skills; open it and select Add to Cursor. To add the server by hand, put this in ^{~/.cursor/mcp.json} for every project or ^{.cursor/mcp.json} for one project, then sign in when Cursor prompts you:

By default, Cursor asks for approval before it uses an MCP tool.

Add it to Codex

In the Codex desktop app, open Plugins or Connectors and install Atlassian Rovo. In the Codex CLI, add the server and complete the browser sign-in:

Here is the same server in ^{~/.codex/config.toml}, set to prompt before any tool the server does not mark read-only:

Run ^{codex mcp login atlassian} to sign in again later.

VS Code and headless clients

In VS Code, open the Extensions view, search for ^{@mcp Atlassian} and select Install. You can also run MCP: Add Server, choose HTTP and enter the v2 URL.

For a CI job with no browser, ask your admin to enable API token authentication and create a service account API key with only the scopes the job needs. Codex can read the key from an environment variable so it stays out of the file:

Clients that take a headers map, such as Cursor's ^mcp.json, send the same key as an ^{Authorization: Bearer} header.

Official, self-hosted or managed: which to use

The official server is the right default for anyone working in their own client: Atlassian maintains the tools, and your admin's controls apply automatically.

The community server sooperset/mcp-atlassian is MIT-licensed and published on PyPI as ^{mcp-atlassian}. It covers Jira and Confluence on Cloud and on Server or Data Center (Jira 8.14 and later, Confluence 6.0 and later), with 98 tools, and it states that it is not an official Atlassian product. The quick start runs it over stdio with an API token:

On Server or Data Center, set ^{JIRA_PERSONAL_TOKEN} instead of the username and API token. Run with ^{--transport streamable-http}, it can also serve many users: each request carries the user's own OAuth token and an ^{X-Atlassian-Cloud-Id} header, and requests without user credentials are rejected unless you set ^{ALLOW_GLOBAL_CRED_FALLBACK=true}. You still issue and refresh those user tokens yourself.

Connect your own agent for many users

A product that runs its own agent for its customers has two ways in. It can connect to Atlassian's MCP server as an OAuth client, or call the Jira and Confluence REST APIs through an OAuth 2.0 (3LO) app. Atlassian Rovo MCP vs Atlassian API compares what each surface can do; for issue workflows in depth, see Jira MCP vs Jira API.

On the MCP route, your agent receives OAuth redirects on your own domain. Unless that domain is on Atlassian's supported list, each customer's organization admin has to add it before any of their users can connect, and their Permissions tab, IP allowlists and data security policies all apply to your calls. On the REST route, you register one OAuth 2.0 (3LO) app in the Atlassian developer console and each user consents to it. Built by hand, that route looks like this:

1. Create the app, choose the Jira and Confluence scopes, add ^{offline_access} to get refresh tokens, and register your callback URL.
2. Send each user through consent, exchange the code, and call Atlassian's ^{/oauth/token/accessible-resources} endpoint to find the sites and ^cloudId values they granted.
3. Store each user's tokens encrypted, keyed by your user ID. One grant covers every site a user adds for your app.
4. Refresh with rotating refresh tokens. Each refresh returns a new refresh token and disables the old one, a refresh token expires after 90 days of inactivity, and a 10-minute reuse interval allows for concurrent retries. Workers that keep an old token get ^{invalid_grant}.
5. Send the user through consent again when a refresh fails, and delete the tokens when they disconnect.

Per-user OAuth for MCP integrations covers this design and its failure modes in more depth.

With Scalekit AgentKit

AgentKit is an MCP gateway that runs each user's OAuth flow, stores their tokens encrypted with AES-256-GCM under a key per environment, refreshes them and calls tools as that user. It supports both Atlassian routes:

• The Atlassian Rovo MCP connector, connection name ^atlassianmcp, routes tool calls to Atlassian's own MCP server and registers through dynamic client registration, so there is no client ID or secret to manage. It lists 40 tools, 26 read and 14 write. Each customer's Atlassian admin controls which apps can connect from the Domains tab of the Atlassian MCP server settings, and the connector guide shows where to add the Scalekit redirect URI.
• The Jira connector (374 tools: 189 read, 130 write, 55 destructive) and the Confluence connector (147 tools: 103 read, 27 write, 17 destructive) call Atlassian's REST APIs over OAuth 2.0. You can use Scalekit's OAuth app, or your own 3LO app with Scalekit's redirect URI as its callback URL.

Choose the Rovo MCP connector when you want Atlassian's own tools and want each customer's MCP controls to govern your agent. Choose the Jira and Confluence connectors when you need REST operations that the MCP server does not expose.

You create a Virtual MCP server once per agent role and choose its tools. All users share its URL. Before each run, your back end mints a session token for one user. Scalekit checks it, finds that user's Jira and Confluence accounts and calls Atlassian with them, so your agent never holds Atlassian tokens.

Once per agent role: create the server.

Before each run: check the user's accounts, then mint a token.

During the run: connect any MCP client with the server URL and the session token as a bearer header. With the Python MCP SDK (version 2):

To give an agent every tool of the Rovo MCP connector, use the connection's own MCP server instead. Every connection has one, at your environment URL followed by ^{/mcp/v3/connections/atlassianmcp}, and you mint the token for the connection:

How session tokens behave:

• A token is bound to one user and one server. Sent to any other server URL, it returns 401.
• It lasts one hour by default, and you can set anything from 60 seconds to 24 hours.
• It is short-lived by design and is not refreshed. Mint a new one per run, per chat session, or on a schedule for a long-running host. A new token does not revoke earlier ones.
• Add ^{access_level="READ_ONLY"} and the run sees only read-only tools; a call to ^{jira_issue_comment_add} or any other write tool is refused before it reaches Atlassian.

By default, ^tools/list also includes a ^{connect_account} tool, so an agent can fetch an authorization link for a user who has not connected yet. To revoke one user, delete their connected account; their next call fails until they authorize again, and other users keep working:

Security notes

• Start with read access. For an agent that only reads, block Write on the Permissions tab or use read-only session tokens, and leave ^delete_jira and ^manage_jira disabled.
• Require approval for writes. Agents read comments and pages written by other people, and Atlassian warns that prompt injection can make an agent change or leak data. In Codex, ^{default_tools_approval_mode = "writes"} prompts for tools not marked read-only. In Claude Code, an ask rule such as ^{mcp__atlassian__*} in ^/permissions makes every call to a manually added atlassian server wait for you; for the server installed by Atlassian's plugin, use ^{mcp__plugin_atlassian_atlassian__*}.
• Keep API tokens narrow. Use a least-privilege service account and rotate or revoke the key if you suspect misuse.
• Know how to revoke. Users revoke app authorizations from their Atlassian profile settings, and admins can review or revoke the MCP app's access from their organization's Marketplace and third-party app settings. With Scalekit, deleting a connected account removes one user's access without touching anyone else's.

FAQs

What is the Atlassian MCP server URL?

Use https://mcp.atlassian.com/v2/mcp for new setups. The v1 endpoints, /v1/mcp and /v1/mcp/authv2, remain supported, and on March 1, 2027 existing v1 connections start using v2 tools. The legacy /v1/sse endpoint is no longer supported after June 30, 2026.

Does the Atlassian MCP server cost anything?

Calls that retrieve data or generate insights consume Rovo credits from your organization's shared pool, the same pool Rovo Chat, Studio, Agents and the Teamwork Graph use. Admins can see credit usage under Insights, then Platform usage in Atlassian Administration.

Does it work with Jira Server or Data Center?

No. The official server needs an Atlassian Cloud site. The community server sooperset/mcp-atlassian supports Jira 8.14 and later and Confluence 6.0 and later on Server or Data Center, using personal access tokens or mTLS.

Can I connect without a browser sign-in?

Yes, if your organization admin enables API token authentication. Send a personal API token with Basic auth or a service account API key as a bearer token. Some tools are unavailable with tokens, calls must pass the cloudId, and domain allowlists do not apply.

Why do tool calls fail after I signed in?

Common causes are an IP allowlist that excludes your AI client's outbound addresses, a permission your admin has blocked, or missing scopes. A blocked permission returns an "Access denied" message that names it. A 403 can also point to app permissions or another access policy, so confirm the reason before changing an IP allowlist.

Can my own product's agent connect to the Atlassian MCP server?

Yes. The server supports dynamic client registration and Client ID Metadata Documents, so any MCP client can register. Each customer's organization admin must allow your redirect domain first, unless it is an Atlassian-supported domain. Scalekit's Atlassian Rovo MCP connector handles registration and per-user tokens, and its Jira and Confluence connectors use Atlassian's REST APIs instead.

Details checked October 2026.