Setting up the Atlassian Rovo MCP Server

The Atlassian Rovo MCP Server is hosted: nothing is installed locally, and the MCP client connects directly to mcp.atlassian.com. Atlassian currently recommends version 2 exclusively, at https://mcp.atlassian.com/v2/mcp.

Setting it up in Claude Code

claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Then run /mcp in a session to start the OAuth sign-in. After confirming in the browser, the Atlassian tools are ready.

Setting it up in Codex

codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp

Setting it up in other clients

For Cursor, VS Code with GitHub Copilot, ChatGPT, Gemini CLI, and Windsurf, the official repository provides ready-made install links or marketplace entries. Clients without native remote support connect via the mcp-remote npm package and the server URL https://mcp.atlassian.com/v2/mcp.

Authenticating without an interactive login

For automations without browser access, a personal API token (basic auth) or a service account API key (bearer token) can be used instead of OAuth. Both must first be enabled by an organization admin under Atlassian Administration → Rovo → Rovo MCP server → Authentication. For Jira Service Management tools, API token authentication is the only supported option anyway.

Keeping access tight

The tool catalog is organized into per-product permission groups (read, write, search, delete, manage). Organization admins should initially grant newly connected clients read-only access and only enable write, delete, or manage permissions once the agent proves reliable. Every action is still limited to whatever the signed-in account can already see and do in Atlassian Cloud.

Moving from v1 to v2

Per Atlassian, existing v1 connections automatically start using v2 tools. The legacy SSE endpoint https://mcp.atlassian.com/v1/sse will be retired after 30 June 2026; anyone with a client still configured for it should switch to /v2/mcp in time and may need to clear cached client IDs or .well-known credentials if authentication fails afterward.

Understanding permission groups in detail

Since the tool catalog is split into per-product permission groups, it's worth checking the specific mapping before granting access: a tool for creating Confluence pages falls into a different group than one for deleting Jira tickets, even though both touch the same Atlassian workspace. Organization admins should enable these groups per product rather than blanket-granting all of them.

Verifying the setup

After OAuth confirmation, test with a harmless, read-only task, such as "Show me the latest Jira tickets in project X" or "Search Confluence for onboarding documents." Only enable additional permission groups once this works reliably.

This staged rollout costs a bit of setup time but prevents an insufficiently tested agent from accidentally making far-reaching changes to production Jira or Confluence data.

Source: github.com/atlassian/atlassian-mcp-server and support.atlassian.com/atlassian-rovo-mcp-server, checked on 2026-09-06.