Atlassian Rovo MCP Deep Dive
You are three hours into implementing a feature when you realize the Confluence page linked in the Jira ticket has been updated since you last read it. The acceptance criteria changed. The API contract in the architecture doc was revised. You have been building against stale requirements, and now half your implementation needs reworking. If only your AI had read the current docs before you started coding.
The Atlassian Rovo MCP server gives your AI direct access to Jira issues, Confluence pages, and Compass components through a single remote MCP endpoint. The AI reads the current ticket, pulls in linked documentation, and works from the latest version of every requirement — no manual context-switching required.
What You’ll Walk Away With
Section titled “What You’ll Walk Away With”- Full setup for the Atlassian Rovo MCP server with OAuth 2.1 authentication
- Prompts for ticket-driven development, documentation search, and cross-tool workflows
- Understanding of available tools: Jira issues, Confluence pages, Compass components
- Troubleshooting for OAuth flows, permission errors, and site admin requirements
How Rovo MCP Works
Section titled “How Rovo MCP Works”Unlike most MCP servers that run locally on your machine, the Atlassian MCP server is a remote server hosted by Atlassian at https://mcp.atlassian.com/v1/mcp. Authentication happens through OAuth 2.1 — the first time you connect, a browser window opens for you to authorize access to your Atlassian site. After authorization, the MCP client caches your credentials.
The server provides tools across three Atlassian products:
| Product | Capabilities |
|---|---|
| Jira | Search issues with JQL, read issue details, create issues, update status, add comments, manage sprints |
| Confluence | Search pages, read page content, create pages, update existing pages |
| Compass | Browse components, read component metadata, understand service dependencies |
{ "mcpServers": { "atlassian": { "command": "npx", "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp"] } }}When Cursor first connects, a browser tab opens for OAuth authorization. Select your Atlassian site, grant the requested permissions, and the connection completes automatically.
{ "mcpServers": { "atlassian": { "command": "npx", "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp"] } }}Add this to .claude/settings.json or use the CLI:
claude mcp add atlassian -- npx -y mcp-remote https://mcp.atlassian.com/v1/mcpThe OAuth flow opens in your default browser on first use.
[mcp.atlassian]transport = "http"url = "https://mcp.atlassian.com/v1/mcp"Jira Workflows
Section titled “Jira Workflows”Reading and Understanding Tickets
Section titled “Reading and Understanding Tickets”The most immediate value is letting the AI read the full context of a ticket before you start coding. No more switching to the browser to re-read requirements.
Creating and Updating Tickets
Section titled “Creating and Updating Tickets”The AI can also write back to Jira — creating bug reports from code analysis, updating ticket status as you work, or adding implementation notes as comments.
Sprint Management
Section titled “Sprint Management”Confluence Workflows
Section titled “Confluence Workflows”Searching Documentation
Section titled “Searching Documentation”Confluence search through MCP is faster than using the Confluence web UI because the AI processes results immediately rather than requiring you to click through and read each page.
Creating Documentation
Section titled “Creating Documentation”The AI can also create Confluence pages — useful for generating ADRs, runbooks, or technical specs from code analysis.
Compass Integration
Section titled “Compass Integration”If your organization uses Atlassian Compass for service catalog management, the MCP server can read component metadata, ownership information, and dependency maps.
This is particularly useful when working on a microservice and needing to understand what other services depend on it, who owns them, and what their SLAs are.
Combining Atlassian MCP with Other Servers
Section titled “Combining Atlassian MCP with Other Servers”The strongest workflows combine Atlassian MCP with version control:
- Read the ticket. The AI fetches the Jira issue, its acceptance criteria, and any linked Confluence docs.
- Create the branch. Using GitHub MCP, the AI creates a branch named after the ticket ID (e.g.,
feature/PLATFORM-1234). - Implement the change. The AI writes code grounded in the ticket’s actual requirements — not a paraphrased summary.
- Open a PR. Using GitHub MCP, the AI creates a pull request that references the Jira ticket in the description.
- Update the ticket. The AI moves the Jira issue to “In Review” and adds a comment with the PR link.
When This Breaks
Section titled “When This Breaks”OAuth flow never completes. The MCP remote proxy redirects to localhost for the OAuth callback. If you are on a VPN or corporate proxy that blocks localhost callbacks, the flow will hang indefinitely. Disconnect from the VPN temporarily, complete the OAuth flow, then reconnect. The cached credentials persist across VPN reconnections.
“Your site admin must authorize this app” error. This appears when no admin on your Atlassian site has completed the initial OAuth consent. The first authorization must be done by a user with admin-level access to both Jira and Confluence. After that, regular users can authorize normally.
AI cannot find the ticket. The AI searches using JQL, which requires the project key, not the project name. “Find bugs in PLATFORM” works because PLATFORM is the project key. “Find bugs in Platform Engineering” fails because that is the project name.
Permission denied on updates. The MCP server respects your Atlassian permissions. If you cannot edit a ticket in the Jira web UI, the AI cannot edit it through MCP either. This is a feature, not a bug.
Stale OAuth tokens. If the connection worked yesterday but fails today, your OAuth token may have expired. Remove and re-add the MCP server to trigger a fresh OAuth flow.