Atlassian MCP Server: Setup, Allowlist & Safe Access

What the Atlassian MCP server is

The Atlassian MCP server is Atlassian’s Rovo MCP server: a remote Model Context Protocol endpoint that exposes Jira, Confluence, and Compass as tools an AI agent can call. It lives at https://mcp.atlassian.com/v1/mcp and authenticates over OAuth2.

It spans three products:

The docs describe the surface in terms of searching issues, reading pages, and creating tickets rather than naming tool functions. The authoritative list is whatever appears on the Tools tab after you authorize, since the gateway reflects the live upstream list.

Because it is remote, there is nothing to run locally — no Docker container, no npx process per laptop. You point an MCP client at a URL and authenticate, which is the appeal of remote MCP servers generally.

What agents actually do with it

The interesting uses chain tools across products:

• Sprint triage. Search open Jira issues, cluster near-duplicates, pull each cluster’s linked Confluence spec to check whether the requirement changed, and create a consolidated ticket.
• Incident writeup. Read the Jira incident, search Confluence for the runbook, pull the owning service from Compass, and draft a postmortem citing all three.
• Spec-to-ticket. Read a Confluence spec, break it into Jira tickets with acceptance criteria lifted from the page, and link each back to the source.
• Ownership lookup. A question arrives about a service nobody recognizes. The agent queries Compass for the component, then answers from its Confluence architecture page.

The split that matters is not just read versus write — it’s public versus sensitive. Reading a Jira issue is harmless. Creating one is recoverable. Reading Confluence deserves the most thought: it’s where companies put board decks, compensation bands, postmortems naming individuals, and security architecture. A read-only agent with unrestricted Confluence access has a wider blast radius than a write-capable agent limited to one Jira project.

That asymmetry is specific to Atlassian, and it’s why “disable the write tools” is incomplete advice here.

Why connecting it raw breaks at team scale

One engineer wiring this into Cursor is fine. Thirty engineers plus a support agent and a docs agent is a different problem.

The allowlist is an org-wide decision. It is set per organization, not per team. Whoever holds org admin in admin.atlassian.com decides whether this integration exists at all. Connect tooling ad hoc and you accumulate allowed domains nobody reviews.

No audit trail of intent. Atlassian logs that an API call happened against a user’s account. It does not log that your triage agent made it while acting on a prompt from a Slack thread. When a ticket appears nobody remembers filing, there’s no chain to reconstruct.

Confluence read scope is “everything the user can see.” Per-user permissions are the right design, but most tenants have permissive Confluence space permissions by historical accident. What a user can see is usually far more than what a task needs, and the agent cannot tell the difference.

Prompt injection has somewhere to land. Jira descriptions and Confluence pages are text an agent reads and someone else may have written. An issue filed by an external reporter through a service desk portal, containing instructions, read during triage with Confluence access live in the same session — that’s a path from untrusted input to sensitive output. The failure isn’t that the agent misbehaved; it’s that its permissions were wider than its task.

None of these are reasons to avoid the server. They’re reasons to put a control plane in front of it — which is what an MCP gateway is for.

Try it yourself.

Spin up a TrueFoundry account, allowlist your domain in Atlassian once, and give your team governed Jira and Confluence access.

Get started free

Step 0: allowlist TrueFoundry in Atlassian

This is the step that blocks teams, so it goes first. It is an Atlassian-side prerequisite and no TrueFoundry setting substitutes for it.

You need: permission to add MCP servers in TrueFoundry, an Atlassian Cloud org with Jira, Confluence, or Compass, and organization admin access in admin.atlassian.com.

In Atlassian Admin, select your organization and open Apps → AI settings → Rovo MCP server. Under Allowed domains, add your TrueFoundry control plane domain:

https://<tfy-control-plane-base-url>/**

There is no OAuth client to create. Atlassian handles dynamic client registration for allowlisted domains. For most self-registered remote MCP servers you’d create an OAuth app in the provider’s portal, set a redirect URI, and store a client ID and secret. Here you don’t — the allowlist entry is the trust relationship.

The allowlist is your kill switch. Removing the domain revokes new OAuth connections. Stopping this integration org-wide is one change in Atlassian Admin, independent of the gateway. Few integrations give you a control that clean; write down where it lives.

One networking caveat: if Atlassian IP allowlisting is enabled, also allow traffic from the environment where TrueFoundry connects to the remote MCP server.

Connecting the Atlassian MCP server through TrueFoundry

Step 1 — Open the picker. In TrueFoundry, open MCP Gateway, click Add MCP Server, and select Atlassian.

Add MCP Server picker showing the available registration paths including official remote servers, any remote MCP server, TrueFoundry Managed MCPs, Hosted STDIO, and Import from OpenAPI Spec

This is not the TrueFoundry Managed MCP catalogue flow, where you supply only a name and the platform owns every field. Atlassian takes explicit values, because the trust relationship came from the allowlist rather than from platform-held credentials.

Step 2 — Configure the server. Use these values:

Field

Value

Name

atlassian

Description

Atlassian is a software development platform

URL

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

Authentication

OAuth2

Turn on Auth Data and select the OAuth2 tab. Because your domain is allowlisted, you do not need a client ID or secret — leave them empty.

Step 3 — Add collaborators. Add the users or teams that should use Atlassian tools. Assign MCP Server Manager to administrators and MCP Server User to consumers.

Step 4 — Save and authorize. Click Add MCP Server. Each user then opens the server’s Tools section and clicks Connect Now to complete Atlassian OAuth. Tools then appear and can be tried from the Agent Playground.

MCP Servers panel showing an unauthorized server in the “You’re not connected to this MCP Server” state with a Connect Now button

How authentication actually works

TrueFoundry separates inbound authentication — how a client proves itself to the gateway — from outbound, how the gateway proves itself to Atlassian. The layers are independent.

MCP Gateway authentication and authorization flow showing inbound authentication, access control, and outbound authentication as three distinct stages

Inbound — four supported methods:

‍