Connect an Atlassian Remote MCP Server

Atlassian hosts a remote server at mcp.atlassian.com, exposing Jira, Confluence, Jira Service Management, Bitbucket, and Compass from an Atlassian Cloud site. This guide covers the Arcade-side setup for connecting it as a remote MCP server, plus the Atlassian administrator controls that most commonly trip people up.

This guide is about connecting to Atlassian’s Rovo server, not an Arcade toolkit. Arcade already ships Optimized Jira and Confluence toolkits, with none of the setup below.

Reach for this remote-server path instead when you need:

Jira Service Management, Bitbucket Cloud, or Compass coverage (no Arcade toolkit exists for any of the three today)
Access enforced entirely through Atlassian’s own domain, permission-group, and IP controls

Rovo’s set is fixed and Atlassian-defined, not something a customer can extend, so the JSM/Bitbucket/Compass advantage above is a gap-filler, not a permanent one: it goes away if Arcade ships native toolkits for those products.

This guide is sourced from Atlassian’s own support documentation and the official atlassian-mcp-server repo . The Arcade-side field mapping hasn’t been walked through end-to-end against a live site. Confirm before treating this as authoritative.

Atlassian’s setup is structurally different from the other guides in this section. Salesforce, ServiceNow, Dynamics 365, and Snowflake all require an administrator to manually create an OAuth app or security integration and hand Arcade a Client ID and Secret. Atlassian’s Rovo server instead supports OAuth 2.1 with Dynamic Client Registration (DCR): Arcade registers itself as a client automatically on first connection. There’s no app-creation step on Atlassian’s side at all. The administrative work here is entirely about who’s allowed to connect and what they can touch, not about provisioning credentials.

Outcomes

Connect an Atlassian Remote server to Arcade and use its in gateways and SDKs.

You will Learn

Which Atlassian domain, permission, and IP controls matter for Arcade specifically, and why
Register the remote server in Arcade without manually configuring OAuth credentials
Diagnose the most common setup mistakes from their error messages

Prerequisites

An Arcade
An Atlassian Cloud site (Jira and/or Confluence)
Organization administrator access to Atlassian Administration, to configure Rovo server settings

Set up Atlassian

Allow Arcade’s domain to connect. In Atlassian Administration, go to Rovo → Rovo server, and check the domain settings. Atlassian’s default Allow Atlassian supported domains setting covers Atlassian’s own launch partners; it’s unlikely to include Arcade automatically. Add Arcade explicitly under allowed domains, or connections will be blocked at the domain-allowlist stage before OAuth is even attempted, regardless of how permissions are otherwise configured.
Set permission groups to Allowed for the products you need. Under the same Rovo server area, open Permissions. Atlassian groups by intent (for example read_jira, write_confluence, search_atlassian), and each tool inherits its group’s setting. A connection can complete OAuth successfully and still fail every tool call with an access-denied error if the relevant group isn’t set to Allowed.
Check your org’s IP allowlist separately. If your organization has IP allowlisting configured, it applies independently of the preceding domain allowlist. Arcade’s outbound IP addresses need to be added there too, or calls get blocked with an IP-specific error even when the domain and permission settings are both correct.
Complete the first-time install with a broadly permissioned . The first user to complete the OAuth consent flow for your site needs access to every Atlassian app you want to expose. If that first consent happens with a Jira-only account, Confluence never get registered for the site, even for other who do have Confluence access. Use an account with both Jira and Confluence access (whichever products you’re exposing) for that first authorization.
API token auth is available as an alternative, but changes the model. For headless or service-style connections, an organization administrator can enable API token authentication instead of per- OAuth 2.1 consent (Rovo server → Authentication). This is also the only supported auth method for Jira Service Management and Bitbucket Cloud ; those two product surfaces aren’t reachable through the OAuth 2.1 flow at all. If you need JSM or Bitbucket tools, plan for a scoped API token rather than expecting OAuth to cover them.

Configure the remote server in Arcade

Register the server

Go to the MCP servers dashboard , click Add Server, choose Remote , and enter a server ID and the server URL:

PLAINTEXT


https://mcp.atlassian.com/v1/mcp

Atlassian has changed this endpoint before. The legacy /v1/sse Server-Sent Events path is still supported but deprecated, and some documentation references /v1/mcp/authv2. Confirm the current recommended path in Atlassian’s docs if the connection behaves unexpectedly.

Configure OAuth2 authorization

Open Advanced settings → OAuth2 authorization and leave Client ID, Client Secret, Authorization URL, and Token URL all empty. This is the opposite guidance from the other guides in this section: Atlassian’s server supports Dynamic Client Registration, so populating these fields isn’t necessary and there’s nothing to create on the Atlassian side to get them from. Arcade registers a client and discovers the authorization server automatically on first connection.

There’s no redirect URI to manually configure anywhere in Atlassian Administration, either. DCR handles that as part of client registration.

Authorize and confirm

Save the server to open the authorization prompt. If this is the first time anyone has connected an client to this site, sign in with the broadly permissioned described in Set up Atlassian above, so the site-level app registration picks up access to every product you intend to expose.

Troubleshooting

“Access denied: Your organization admin has not authorized…”: the relevant permission group (read, write, or search, per product) isn’t set to Allowed under Rovo server → Permissions, even though OAuth itself succeeded.
“You don’t have permission to connect from this IP”: Arcade’s outbound IP addresses aren’t on the organization’s IP allowlist. This is a separate control from the domain allowlist and needs its own configuration.
Authorization fails outright, before any consent screen appears: Arcade’s domain isn’t in the allowed domains list under Rovo server settings. “Allow Atlassian supported domains” being enabled doesn’t guarantee Arcade is covered by it.
Confluence (or Jira) never show up, even for a with access to that product: the first user to complete the site’s initial OAuth consent didn’t have access to that product. Have an administrator with access to all needed products redo the initial authorization.
The connection stops responding, or behaves inconsistently: confirm you’re pointed at the current endpoint rather than the deprecated /v1/sse path.
Jira Service Management or Bitbucket Cloud are missing: those tool families require API token authentication, not OAuth 2.1. They won’t appear through a pure OAuth-based connection regardless of permission group settings.

Next steps

Create an MCP Gateway to expose this server’s .
Connect to MCP clients.