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.

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:

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.

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.

Inbound — four supported methods:

One caveat matters especially here: Virtual Account tokens give every request identical access, so they cannot express per-user Atlassian permissions — they collapse your whole permission model into whatever that one identity can reach. Use a PAT or IdP token inbound.

Outbound — for Atlassian this is OAuth2. Each user authorizes their own account through Connect Now, and TrueFoundry manages consent, token storage, and refresh, injecting tokens per user on every call. TrueFoundry never receives Atlassian credentials.

The practical effect, stated plainly in the docs: each user operates with their existing Jira, Confluence, and Compass permissions. No shared service account holds tenant-wide Confluence read access, and when someone’s Atlassian access is revoked, their agent’s reach dies with it.

Users authenticate twice — gateway, then Atlassian. That’s what makes per-user attribution possible.

Scoping tools before you ship

The Tools tab lists everything the server exposes.

Per-tool toggles. Turn a tool off and it’s omitted from tools/list entirely — clients never see it and it cannot be invoked. This is not prompt-layer filtering. Changes save immediately with a Tool settings updated toast.

For Atlassian, the highest-value move is usually not “disable all writes.” It’s disabling the Confluence tools for agents that only work in Jira. A sprint-triage agent needs Jira search and issue reads, not the ability to search every Confluence space in the tenant — and a tool it cannot call is one no poisoned issue description can talk it into calling.

Enable new tools by default. This decides what happens when Atlassian ships a new tool. Left on, new tools appear automatically and your capability surface grows on its own. Turned off, only tools you explicitly enabled are available. For a server spanning three products with different sensitivity profiles, off is safer.

Bulk Action. Switches every row to checkboxes with Select all, for standing up a curated allowlist fast.

Click the pencil on any tool to override how it’s presented to the model:

Edit Tool modal with a Description override field and an MCP Tool Annotations selector offering None, Read-only, and Destructive

The Description override (up to 20,000 characters) steers tool selection when upstream wording is ambiguous — useful across Jira and Confluence, where “search” means two things. MCP Tool Annotations mark a tool Read-only or Destructive, setting readOnlyHint or destructiveHint. Annotating correctly is what lets the approval policies below gate a whole class of tools without naming each one.

Who can do what: collaborator roles

Access control attaches to users, teams, or virtual accounts, on two dimensions: which servers an identity can reach, and which tools it can invoke.

Update MCP Server drawer showing the Collaborators section with MCP Server Manager and MCP Server Approver roles assigned

‍