Back to blog

Engineering · Jun 20, 2026

MCP Spotlight: Atlassian Rovo MCP Server — The Official Jira, Confluence & Compass Bridge That Went GA With OAuth 2.1, Claude First Partner

Atlassian's official Rovo MCP Server — GA February 2026 with Claude as first partner — exposes Jira, Confluence, Compass, and Jira Service Management via OAuth 2.1 with per-request scopes, JQL/CQL passthrough, and full tool annotations.

MCP ServerAtlassian RovoJiraConfluenceOAuth 2.1AI Agents

MCP Spotlight: Atlassian Rovo MCP Server — The Official Jira, Confluence & Compass Bridge That Went GA With OAuth 2.1, Claude First Partner

Server: Atlassian Rovo MCP Server by Atlassian Status: GA (February 2026) · License: Atlassian Cloud · Transport: Hosted (HTTP), OAuth 2.1 Coverage: Jira (issues, JQL, projects, boards) · Confluence (spaces, pages, comments) · Compass (components) · Jira Service Management Auth: OAuth 2.1 with per-request scopes, no long-lived API tokens Docs: support.atlassian.com/.../getting-started-with-the-atlassian-remote-mcp-server GitHub: github.com/atlassian/atlassian-mcp-server First partner: Anthropic (Claude Desktop / Claude Code)

The MCP ecosystem has thousands of community servers. But when the platform vendor itself — Atlassian, with 300,000+ customers running Jira, Confluence, Compass, and JSM — ships an MCP server, the entire agent-development model shifts. Atlassian's Rovo MCP Server went GA in February 2026 with Claude as the first launch partner. It exposes Jira, Confluence, and Compass to any MCP-compatible agent through OAuth 2.1, with per-request scope enforcement, no long-lived API tokens, and full Jira Query Language (JQL) support for power users.

This is the server that turns "agent helps me with Jira tickets" from a fragile REST wrapper into a first-class platform capability. It's also the template for how every major SaaS vendor should ship their MCP integration — hosted, OAuth-native, scope-minimal, and respecting the user's existing permissions.

What You Can Do

The Atlassian Rovo MCP Server bridges your Atlassian Cloud site to your agent through MCP tools:

CapabilityWhat It Covers
Jira issuesRead, create, update, comment, transition, assign, link, search via JQL
Confluence pagesRead, create, update, comment, search by space, CQL
Compass componentsRead component metadata, dependencies, on-call info
Jira Service ManagementRead and update service desk tickets
Projects & boardsList projects, sprints, epics, versions
Search across productsUnified Rovo search across Jira + Confluence + Compass

The unified search is the killer capability — your agent runs one query and gets results from Jira issues, Confluence pages, and Compass components in a single ranked list. No "search Jira, then search Confluence, then merge the results" dance.

OAuth 2.1 With Per-Request Scopes

The security architecture is the most important part of the Atlassian MCP story. It uses OAuth 2.1 with per-request scope enforcement — no long-lived API tokens, no shared secrets:

1. Add the MCP server to your client
2. Client initiates OAuth 2.1 flow → browser opens
3. You sign in to Atlassian Cloud
4. You approve the scopes the client requested
5. Short-lived access token is issued; refresh handled by OAuth
6. Every MCP call carries the token; the Atlassian server enforces scopes per request

The critical detail: the Atlassian server enforces the user's existing permissions, not a separate "agent role". If a user can read a Jira issue in their browser, their agent can read it through MCP. If they can't delete a Confluence page, the agent can't either. This is RBAC by inheritance, not by separate configuration.

For teams with strict security reviews, this means:

  • No service accounts — the agent acts as the user, with the user's permissions
  • No shared API tokens — OAuth tokens are short-lived and scoped
  • No new permission model — uses the existing Atlassian permission scheme
  • No audit gap — every MCP call shows up in Atlassian's existing audit log as the user

This is the right model for enterprise SaaS. The agent doesn't get a backdoor; it gets the same view the human has.

JQL and CQL: Power Users Keep Their Native Query Languages

The search tools accept the native Atlassian query languages:

  • JQL (Jira Query Language) — the same query language every Jira power user knows
  • CQL (Confluence Query Language) — the same query language every Confluence power user knows

Your agent writes standard JQL and gets standard JQL results:

project = "API" AND status != Done AND assignee = currentUser() ORDER BY priority DESC

This is the same JQL a Jira admin would type in the issue navigator. The agent doesn't need to learn an Atlassian-MCP-specific query syntax. The MCP server passes JQL through to the Jira API and returns the results.

For HITL workflows, the JQL passthrough is significant: a human who already knows JQL can write a complex query, copy-paste it into the agent prompt, and trust the results match what they'd see in Jira UI. No translation, no surprises.

Tool Annotations and Scope Discipline

The Atlassian Rovo MCP Server ships with full MCP Tool Annotations:

AnnotationExample Tools
readOnlyHint: trueSearch, get-issue, get-page, get-component, list-projects
destructiveHint: trueDelete issue, delete page, archive project
idempotentHint: trueCreate issue with same summary (returns existing), update with same value

A well-built MCP client uses these hints to surface confirmation prompts for destructive operations and skip them for read-only ones. The agent's deleteIssue call doesn't slip past silently — the client (Facio, Claude Desktop, etc.) sees the destructiveHint annotation and requires human approval.

First Partner: Anthropic Claude

Atlassian chose Anthropic Claude as the first launch partner, with integration in Claude Desktop and Claude Code. This is significant for two reasons:

  1. Strategic signal — Atlassian is betting on Claude for knowledge work, not just for code
  2. End-to-end polish — the Claude + Rovo integration is the reference implementation; other agents follow

The setup in Claude Code is one config.toml entry. The OAuth flow runs once in the browser. After that, "Claude, what tickets are assigned to me this sprint?" and "Claude, draft a Confluence page summarizing this week's incident review" both work as natural-language invocations.

For teams using Claude as their primary agent surface, the Atlassian MCP integration is what turns "Claude knows about my project" into a real capability — with proper auth, proper permissions, proper audit.

Facio Integration

{
  "mcpServers": {
    "atlassian-rovo": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "auth": {
        "type": "oauth",
        "client_id": "${credentials.ATLASSIAN_OAUTH_CLIENT_ID}",
        "scope": "read:jira-work write:jira-work read:confluence-content.summary write:confluence-content offline_access"
      }
    }
  }
}

Facio's audit trail captures every Atlassian MCP call with the OAuth user identity, the project, the JQL or CQL query, the action, and the result. Combined with Atlassian's own audit log, this creates a complete chain: "Agent updated ticket API-1234 at 14:32 UTC, user kevin@centerbit.co approved, status moved to In Review, Facio captured the diff."

For HITL workflows, the destructive operations are obvious:

  • deleteIssue, deletePage, archiveProject — hard confirm
  • transitionIssue, updateIssue, updatePage — soft confirm (review intent)
  • addComment, createIssue, createPage — autonomous for known patterns (e.g., daily standup notes)
  • All read operations — fully autonomous

The OAuth-scoped architecture means HITL gating happens at two layers: the Atlassian permission scheme (what the user can do in Jira) and Facio's destructive-operation confirmation (what the agent is allowed to do without review). Both layers enforce the same principle: the agent never acts beyond the user's authority.

Quickstart

# Claude Code — add the Atlassian MCP server
claude mcp add atlassian-rovo --transport https://mcp.atlassian.com/v1/mcp \
  --scope "read:jira-work write:jira-work read:confluence-content.summary write:confluence-content offline_access"

# Or in MCP client config:
{
  "mcpServers": {
    "atlassian-rovo": {
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

# OAuth flow runs once:
# - Browser opens → sign in to Atlassian Cloud
# - Approve scopes
# - Token issued; agent has access

# First prompts
# "What's on my Jira board this sprint? Group by epic."
# "Find all Confluence pages about the API redesign from the last 60 days."
# "Create a Jira ticket from this Slack thread — make it a bug, priority High, assign to me."
# "Draft a Confluence page summarizing this week's incident review and link it to the related tickets."
# "Move ticket API-1234 to In Review and add a comment that the PR is up for review."

Use Cases

Sprint standup automation: "What tickets did my team complete yesterday, what's in progress today, and what's blocked?" Agent runs JQL across the team's assigned issues, summarizes the sprint status, drafts the standup update, posts to Slack.

Incident retrospectives: "Pull all tickets closed this week with type=Bug, find related Confluence incident docs, summarize themes, draft a retrospective page." Cross-product query — Jira for the tickets, Confluence for the docs, Compass for affected components.

Ticket creation from context: "Read this Slack thread and create a Jira ticket for the feature request, properly tagged, with the right team assigned based on the component." Agent parses the conversation, identifies the request, creates the ticket with the right fields.

Documentation maintenance: "Find Confluence pages older than 12 months in the 'API' space that haven't been updated, and list them so we can review for archival." Agent runs CQL, surfaces the stale docs, drafts review tasks.

Cross-team dependency tracking: "For each ticket in our current sprint, what are the upstream and downstream dependencies in Compass?" Agent queries Jira + Compass, builds the dependency graph, surfaces the bottleneck tickets.

Service desk triage: "List all JSM tickets in the 'Billing' queue assigned more than 4 hours ago, grouped by priority. Draft responses for the top 3." Read the queue, prioritize by SLA, draft answers for human review.

Compass service catalog: "What services does our team own in Compass, and which ones have unresolved incidents this week?" Agent queries Compass + Jira Service Management, surfaces ownership with health status.

Bottom Line

The Atlassian Rovo MCP Server is the first major SaaS vendor to ship an MCP server as a GA platform capability, not a community experiment. OAuth 2.1, per-request scopes, native JQL/CQL passthrough, full tool annotations, Claude as first launch partner, hosted transport, no API tokens.

For the 300,000+ teams running on Jira, Confluence, and Compass, this is the missing layer that turns "agent helps with project management" into a real capability. For the broader MCP ecosystem, this is the template every major SaaS vendor should copy: hosted, OAuth-native, scope-minimal, user-permission-respecting, audit-log-inheriting.

If you're on Atlassian Cloud and you ship an agent, this is the integration. If you're a SaaS vendor thinking about your own MCP server, study this one — Atlassian just showed you what "enterprise-grade" looks like in the MCP era.


MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for auth architecture, vendor commitment, and integration fit with Facio's HITL-first agent runtime.