Skip to main content
Atlassian Rovo MCP Server is Atlassian’s official remote MCP server. It exposes Jira, Confluence, Bitbucket, Loom, Goals, Projects, Teams, Focus, and Talent as MCP tools, backed by the Teamwork Graph. It is a hosted remote endpoint, so it registers on the TrueFoundry MCP Gateway as mcp-server/remote with nothing to self-host. Outbound auth is OAuth 2.1 Authorization Code with PKCE plus Dynamic Client Registration (DCR) - there is no OAuth client to create in Atlassian, and every user authorizes their own Atlassian account, so tool calls always respect that person’s existing project and space permissions. By the end of this guide you will have an atlassian MCP server registered in TrueFoundry, authenticated per user over OAuth 2.1 DCR, with Atlassian tools available in the Agent Playground and any attached MCP client.
Use the v2 endpoint. Atlassian Rovo MCP v2 is Generally Available and is the version all current tools ship against. Existing v1 connections will start exposing v2 tools automatically, and v2 is a separate OAuth resource - v1 tokens and cached client IDs do not carry over, so users reauthorize after switching.

​
How it fits together

​
Using Atlassian through the MCP Gateway

Registering Rovo on the Gateway rather than wiring it into each client gives you:
  • Authentication - clients authenticate inbound to the AI Gateway. Gateway runs the Atlassian OAuth flow outbound and stores and refreshes each user’s tokens.
  • Per-user attribution - because DCR issues a per-user token, Jira transitions and Confluence edits are attributed to the real person, not a shared service account.
  • Tool-level access control - enable or disable individual tools from the server detail page. See MCP Tool Management.
  • Access control - collaborators and role-based policies decide who can use the server.
  • Observability - tool calls are traced with caller identity, tool name, inputs, and latency, and surfaced in MCP Metrics.
  • Guardrails and approval - apply pre-tool and post-tool guardrails and tool approval to write and destructive tools such as issue creation or page deletion.

​
Prerequisites

  • A TrueFoundry account with permission to add MCP servers, and your TrueFoundry control plane base URL.
  • An Atlassian Cloud site with Jira, Confluence, or the other products you plan to reach.
  • Atlassian organization admin access in admin.atlassian.com, to allowlist your TrueFoundry domain and to grant the permission groups your users need.
  • Optionally curl and jq, if you want to derive the OAuth endpoints by hand instead of letting the Gateway discover them.
Rovo MCP calls consume Rovo credits from the same shared pool as Rovo Chat, Studio, and Agents. Credit cost scales with context volume and reasoning depth, and is metered per call. See Rovo usage limits.

​
The endpoint

Register this URL, including the ?tools=all query parameter:
It returns a flat, paginated tools/list containing every tool, instead of hiding most of them behind discover/execute. Atlassian documents ?tools=all specifically for MCP gateway deployments, under MCP gateways or custom MCP. Use it so TrueFoundry can enumerate, govern, and selectively disable real tools.
How v2 exposes tools. By default Rovo v2 advertises only a small set of Primary tools - atlassianUserInfo, getAccessibleAtlassianResources, getJiraIssue, and the discover / executeRead / executeWrite / executeDestructive pathway - and lets clients find the rest on demand to save context. That indirection defeats Gateway tool-level governance, which is why ?tools=all is the right choice here: it flattens the catalogue so every tool appears in tools/list and can be individually toggled, traced, and approval-gated. tools/list is paginated at 50 tools per page. See Supported tools.
getAccessibleAtlassianResources is effectively a required first call - it returns the cloudId of every site the user can reach, and nearly every other tool needs a cloudId. Leave it enabled even when you trim the tool list.

​
Allow TrueFoundry in Atlassian

In Atlassian Admin, select your organization and open Apps > AI settings > Rovo MCP server. Under Allowed domains, add your TrueFoundry control plane domain:
Atlassian performs Dynamic Client Registration for allowlisted domains, so you never create or manage an OAuth client ID and secret. While you are here, confirm the permission groups your users need are granted. Atlassian admins grant and revoke access at the permission-group level (for example read_jira, write_confluence), and each tool inherits its group’s access - so a tool whose group is revoked fails even if the OAuth scope was consented.

​
Authentication model

This server uses OAuth 2.1, Atlassian’s recommended mechanism for interactive, user-driven use - which is exactly what an MCP Gateway serves. Authorization Code + PKCE (S256), with the client registered dynamically at connection time. Atlassian registers public clients - token_endpoint_auth_methods_supported includes none - so there is no client secret.
Leave Client ID and Client Secret blank. Supplying your own pre-registered client switches the server to a single shared machine identity, and every Jira transition and Confluence edit gets attributed to that one account instead of the person who asked for it. DCR is what preserves per-user attribution and per-user permission enforcement.

​
Register in TrueFoundry

The DCR registration endpoint is tenant-scoped and can be rotated, so let the Gateway discover it rather than hardcoding it. Atlassian moved DCR to its Atlassian Identity auth server, and the old fixed https://mcp.atlassian.com/oauth/register now returns 404.
1

Add a remote MCP server

In TrueFoundry, open MCP Servers and click Add new MCP Server. If an Atlassian card appears under Connect Official Remote MCP Servers, select it and confirm the URL matches the endpoint above. Otherwise choose Connect any Remote MCP Server.
2

Configure the server

Names must be lowercase and hyphen-separated.
3

Fill in the OAuth 2.1 configuration

Turn on Auth Data, select the OAuth2 tab, and click Refetch OAuth2 details - the Gateway walks Atlassian’s discovery chain and populates the endpoints for you. Confirm the result:The authorization and token URLs are stable. The registration URL is the one to re-verify - it carries the tenant-scoped <auth-server-id> segment, so a DCR setup that worked before and now returns 404 almost always means that segment changed. Click Refetch OAuth2 details again to pick up the new value.
4

Add collaborators

Add the users and teams that should use Atlassian tools. Assign MCP Server Manager to administrators and MCP Server User to consumers. See Access control.
5

Save and authorize

Click Add MCP Server. Each user then opens the server’s Tools tab, clicks Connect Now, signs in to Atlassian, and approves the requested scopes on Atlassian’s consent screen. The Gateway stores that user’s tokens and refreshes them automatically; access can be revoked from the same screen.If DCR is configured correctly, registration returns a client rather than a 404, and the consent flow launches on first use.
Use this to verify what Refetch OAuth2 details populated, or to debug a DCR failure. It needs curl and jq.First, find the authorization server:
authorization_servers[0] is a tenant-scoped URL of the form https://auth.atlassian.com/<auth-server-id>. The same response’s scopes_supported is the authoritative scope list for your tenant.Then read that server’s metadata:
Its authorization_endpoint, token_endpoint, and registration_endpoint are the three URLs in the table above. code_challenge_methods_supported is ["S256"], and token_endpoint_auth_methods_supported includes none - confirming Atlassian registers public DCR clients, which is why there is no client secret to configure.

​
Scope and permission-group reference

v2 uses one scope per permission group, all in the *:agent-interface family. The authoritative list for your tenant is the scopes_supported array returned by Atlassian’s protected-resource metadata endpoint. Always add offline_access for refresh tokens, plus read:me and read:account for current-user identity. Per-tool scope requirements are listed on Supported tools. Some toolsets have availability conditions beyond scopes:
  • delete_jira (permanent issue, comment, and attachment deletion) and manage_jira (space creation and configuration) are disabled by default. An Atlassian admin must enable each group before the tools can be used, even if you request the scope and the user consents.
  • Bitbucket tools require the Bitbucket workspace to be linked to an Atlassian organization. Unlinked workspaces are not even selectable during authorization.
  • Loom tools only cover Loom workspaces linked to an Atlassian site.
  • Compass is not a standalone v2 toolset. Compass components surface through Teamwork Graph and Rovo search rather than a dedicated scope.
Start read-only. Register read:* and search:* scopes first, then publish write-capable variants as separate Virtual MCP Servers scoped to trusted teams.

​
Connecting to an MCP client

Open the How To Use tab on the server detail page for your tenant-specific Gateway URL and ready-to-paste client snippets - don’t build the endpoint by hand. The tab covers Claude Code, Claude Desktop, Claude Web, Cursor, VS Code, Windsurf, Codex, and the Python and TypeScript MCP SDKs. See also Connect MCP from your IDE.