Atlassian MCP Setup: Use the v2 Endpoint and Existing Permissions
Use Atlassian’s current v2 remote MCP endpoint, https://mcp.atlassian.com/v2/mcp, with OAuth for interactive clients. Verify Jira and Confluence reads under the signed-in user’s existing permissions, then enable mutations only for named sites, projects, spaces, and actions.
Use Atlassian’s current v2 remote MCP endpoint, https://mcp.atlassian.com/v2/mcp, with OAuth for interactive clients. Verify Jira and Confluence reads under the signed-in user’s existing permissions, then enable mutations only for named sites, projects, spaces, and actions.
Table of contents
- What the official Atlassian MCP server connects
- Choose v2 OAuth or scoped token authentication
- Connect a supported client
- Verify Jira, Confluence, and site context with reads
- Control writes with existing roles and explicit targets
- Fix cached clients, legacy SSE, 429, and admin restrictions
- FAQ
What the official Atlassian MCP server connects
The official Atlassian Rovo MCP Server connects Jira, Confluence, and Compass Cloud through the hosted v2 endpoint https://mcp.atlassian.com/v2/mcp, using HTTP transport and OAuth authentication. Atlassian’s official server documentation lists the current endpoint and connection model.
Atlassian hosts the service, so there is no local Atlassian MCP server installation to maintain. It exposes read and write tools for Jira, Confluence, Compass, and other supported Atlassian Cloud products.
The permission boundary comes from the authenticated Atlassian identity. OAuth and scoped API-token access remain subject to configured Atlassian scopes, existing Jira and Confluence permissions, and any IP allowlisting enforced by the organization.
This remote server supports Atlassian Cloud sites with Jira, Confluence, and/or Compass. It does not support Server or Data Center deployments. For the practical connection reference, see the Atlassian Rovo MCP Server directory page.
Choose v2 OAuth or scoped token authentication
Choose OAuth 2.1 for an interactive client with browser access. Choose a scoped Atlassian API token for a headless or long-running process only when an organization administrator has enabled token authentication.
OAuth is the normal option for a person connecting a desktop assistant, IDE, or hosted client. The client opens a browser authorization flow, you sign in to Atlassian, approve the requested access, and return to the client. A modern browser is required to complete this process.
A scoped API token is intended for a process that cannot complete an interactive browser flow. The token should cover only the access required by that process, and the organization administrator must enable headless or token authentication. Neither method grants access beyond the authenticated user’s Atlassian scopes and roles.
| Situation | Use | Requirement |
|---|---|---|
| Interactive desktop or IDE client | OAuth 2.1 | A modern browser can complete authorization |
| Headless or long-running process | Scoped API token | An organization admin has enabled token access |
| Organization uses IP restrictions | OAuth or token | The connection is allowed by IP policy |
| Server or Data Center deployment | Not this remote server | Use a compatible community server |
The authentication choice does not replace Jira project roles, Confluence space permissions, or organization controls. Review the remote MCP announcement for Atlassian’s hosted connection model, and see MCP OAuth explained for authorization terminology.
Connect a supported client
Add https://mcp.atlassian.com/v2/mcp as a remote MCP server, choose OAuth when the client supports browser authorization, and complete the Atlassian sign-in flow. Use the supplied mcp-remote proxy only when a local client needs a bridge to the hosted endpoint.
For a client with native remote MCP support, create an HTTP MCP server entry with the endpoint above. Start the connection and sign in with the Atlassian account whose Jira, Confluence, or Compass access should be used.
Some local clients require Node.js 18 or newer and the following proxy command:
npx -y mcp-remote https://mcp.atlassian.com/v2/mcp
After authorization, inspect the client’s MCP tool list. It should show the remote Atlassian service and use the permissions of the authorized account. If the client displays an old endpoint, an old transport, or stale authorization, replace the saved entry with the current HTTP endpoint and reconnect.
Do not add unverified flags or configure the service without authentication. For Claude-specific setup, use the Claude client guide. Other supported clients use the same hosted endpoint, although their configuration screens and OAuth prompts can differ.
Verify Jira, Confluence, and site context with reads
Start with read-only checks: identify the accessible Atlassian site, read one known Jira issue, and read one known Confluence page. These checks confirm account context and product access without changing Atlassian data.
First ask the client to identify the site or sites visible to the signed-in user. If several sites appear, record the intended site before testing later operations. Successful OAuth proves that authorization completed; it does not prove access to every project or space.
Next, perform a narrow Jira read using a known issue key or tightly scoped JQL. Confirm that the issue belongs to the expected site and that the returned fields are visible to the current user. Avoid beginning with a broad search when a known issue can establish the connection.
Then read a known Confluence page from the intended space. Confirm its title, space, and site context. If the page is missing, check direct Confluence access with the same account before treating MCP as the cause.
Use this verification order:
- Confirm the current site context.
- Read one known Jira issue.
- Read one known Confluence page.
- Compare the results with the user’s expected access.
- Record successful reads before enabling writes.
If Compass is part of the Atlassian Cloud setup, test it separately after Jira and Confluence reads succeed. MCP separates the client, MCP server, and connected service, so a failure can arise from client configuration, authorization, or Atlassian access. The MCP architecture guide explains these boundaries.
Control writes with existing roles and explicit targets
Enable mutations only after read checks succeed, and name the exact site, project, space, and action in every write request. Existing Atlassian permissions remain the authorization boundary.
For Jira, identify the target site and project before a mutation. For Confluence, identify the site and space; for Compass, name the component scope.
Use instructions such as “add a comment to issue ABC-123” or “update this page in the Engineering space.” Avoid broad requests that leave the target unclear. When the client supports confirmation, ask the agent to restate the target and proposed mutation before execution.
The permissions are the same ones used in Atlassian directly. If the user cannot edit a Jira project, transition an issue, or write in a Confluence space through Atlassian, the MCP server should not be expected to provide that access.
Administrators can prevent MCP access through organizational controls. Atlassian’s access-control documentation covers these restrictions.
For repeatable operations, record the approved site, project key, Confluence space, permitted mutation, and responsible identity. Keep authorization checks active throughout the workflow, consistent with the MCP security best practices.
Fix cached clients, legacy SSE, 429, and admin restrictions
Refresh stale client configuration, use the current HTTP endpoint instead of a legacy SSE setup, slow repeated requests after a 429 response, and confirm organizational policy before changing authentication settings. Keep OAuth, TLS, and permission checks enabled while troubleshooting.
| Symptom | Likely cause | Action |
|---|---|---|
| Old tools or endpoint appear | Cached configuration | Replace the saved entry with https://mcp.atlassian.com/v2/mcp and reconnect |
| Client expects SSE | Legacy transport setting | Configure the current HTTP remote connection |
| OAuth does not complete | Browser or authorization issue | Use a modern browser and repeat the flow |
| 429 response | Rate or temporary service limit | Narrow the operation, wait, and retry |
| Atlassian data is missing | Role or site restriction | Verify direct access with the same identity |
| Token is rejected | Admin policy or token scope | Confirm enablement and scope with an administrator |
| Cloud works but Data Center does not | Unsupported deployment | Use a compatible community server |
Cached clients can preserve old connection state. Remove the obsolete entry, add the v2 URL, authorize again, and use MCPtrove Config Doctor to inspect the resolved configuration.
A 429 response means the client should stop repeating the same requests rapidly. Reduce repeated or concurrent activity, narrow the query, wait, and retry. Do not disable authentication or permission checks to address a rate response.
If the endpoint connects but returns no useful Atlassian data, check the account directly in Jira or Confluence. Then confirm that the organization has not blocked Atlassian MCP access and that OAuth or token scopes are appropriate. The MCP debugging guide provides a structured way to separate client, server, and authorization failures.