Atlassian's MCP Server Is Now GA: How Claude Reads and Writes Jira, Confluence, and Compass via OAuth
Atlassian's remote MCP server went GA in February 2026 with Claude as first partner. It searches, summarizes, and creates issues across Jira, Confluence
Atlassian’s MCP Server Went GA in February 2026 — Here’s What Claude Can Actually Do with Jira
Atlassian’s remote MCP server hit general availability in February 2026, with Claude as its first official partner. That’s the specific thing worth paying attention to. Not “Atlassian added AI features” — they exposed Jira, Confluence, and Compass as a structured, OAuth-authenticated, agent-readable and agent-writable surface over Cloudflare infrastructure.
If you’ve been waiting for a production-grade way to let Claude search, summarize, create, and update Jira issues without scraping the UI or building a custom integration, this is it.
This post covers what the integration actually does, how to get it running, where it breaks, and what you can realistically build on top of it.
What Claude Can Actually Do with Your Atlassian Data
Before you set anything up, it’s worth being precise about the capability surface. The Atlassian remote MCP server supports:
- Search and summarize across Jira issues, Confluence pages, and Compass components
- Create and update Jira issues and Confluence pages
- Respect existing permissions — Claude only sees what the authenticated user can see
- Admin controls and whitelisting — your Atlassian admin can restrict which MCP clients are allowed
The Cloudflare infrastructure underneath means this is a remote MCP server, not a local one you run yourself. You’re connecting Claude Desktop (or any MCP-compatible client) to Atlassian’s hosted endpoint via OAuth. No Docker container, no self-hosted proxy.
That permission model is the part that matters most for enterprise use. The agent does not get to do more than the human whose OAuth token it’s using. If you can’t see a Jira project, neither can Claude. This is the same principle OpenAI’s Symphony spec assumes when it uses Linear as a control plane for autonomous coding agents — the tracker’s permission model becomes the agent’s permission model.
What You Need Before You Start
Atlassian account with admin access (or a cooperative admin)
You need to be able to authorize the MCP server against your Atlassian organization. If you’re on a company-managed instance, your Atlassian admin will need to whitelist the MCP client. On a personal or team-managed site, you can do this yourself.
Claude Desktop (or another MCP-compatible client)
The Atlassian MCP server uses the Model Context Protocol. Claude Desktop supports MCP natively. If you’re using the Claude API directly, you’ll need an MCP client library — the official @modelcontextprotocol/sdk package handles this.
A Jira project with real data in it
The integration is most useful when there’s actual work state to query. A project with a few dozen issues, some in different statuses, with assignees and comments, will demonstrate the capability much better than an empty board.
Basic familiarity with OAuth flows
The setup involves an OAuth authorization step. You don’t need to write OAuth code, but you should understand that you’re granting the MCP server access to your Atlassian account and that you can revoke it later from your Atlassian account settings.
Setting Up the Atlassian MCP Server with Claude
Step 1: Add the Atlassian MCP server to your Claude Desktop config
Open your Claude Desktop configuration file. On macOS this lives at ~/Library/Application Support/Claude/claude_desktop_config.json. Add the Atlassian remote MCP server entry:
{
"mcpServers": {
"atlassian": {
"command": "npx",
"args": [
"-y",
"@atlassian/mcp-server"
]
}
}
}If Atlassian has published a direct remote endpoint (check their developer documentation for the current URL), you can configure it as a remote server instead of running it via npx. The remote configuration looks like:
{
"mcpServers": {
"atlassian": {
"url": "https://mcp.atlassian.com/v1/sse",
"transport": "sse"
}
}
}Restart Claude Desktop after saving. You should see the Atlassian tools appear in the tools panel.
Now you have: Claude Desktop configured to talk to the Atlassian MCP server.
Step 2: Authorize via OAuth
When you first ask Claude to do anything Atlassian-related, it will trigger the OAuth flow. Claude will present you with an authorization URL. Open it in your browser, log into your Atlassian account, and grant the requested permissions.
The scopes the server requests cover reading and writing Jira issues and Confluence pages. Review them before accepting — you’re granting real write access.
After authorization, the OAuth token is stored locally by the MCP client. You won’t need to re-authorize on every session, but tokens do expire and you’ll occasionally need to re-authenticate.
Now you have: An authenticated connection between Claude and your Atlassian workspace.
Step 3: Test with a search query
Start simple. Ask Claude something like:
“Search Jira for open bugs assigned to me in the PLATFORM project.”
Or:
“Summarize the last five issues created in the BACKEND project.”
Not a coding agent. A product manager.
Remy doesn't type the next file. Remy runs the project — manages the agents, coordinates the layers, ships the app.
If the connection is working, Claude will call the Atlassian search tool, retrieve the results, and give you a structured summary. You’ll see the tool call in Claude Desktop’s interface — it shows which MCP tools were invoked and what they returned.
A good test for Confluence:
“Find the Confluence page about our deployment process and summarize the key steps.”
Now you have: Confirmed that Claude can read your Jira and Confluence data.
Step 4: Try creating and updating issues
This is where the integration earns its keep. Ask Claude to:
“Create a Jira issue in the PLATFORM project: title ‘Fix null pointer in user auth flow’, type Bug, priority High, assign to me.”
Claude will call the create-issue tool with the structured fields. Check your Jira board — the issue should appear with the correct metadata.
For updates:
“Update PLATFORM-247: change status to In Review and add a comment that the PR is up for review.”
The MCP server handles the field mapping. You don’t need to know the Jira field IDs or the exact status transition names — Claude infers them from the tool schema.
Now you have: Bidirectional read/write access to Jira through natural language.
Step 5: Query Compass (if your org uses it)
Compass is Atlassian’s component catalog — it tracks services, their owners, their health scores, and their dependencies. If your engineering org uses Compass, the MCP server exposes it too.
“Find all services owned by the payments team in Compass and list their current health status.”
This is particularly useful for incident response workflows, where you need to quickly understand which team owns a degraded service.
Now you have: A complete picture of what the Atlassian MCP server can reach across Jira, Confluence, and Compass.
Where This Actually Breaks
OAuth token scope mismatches
If Claude can read issues but can’t create them, the OAuth token was probably authorized with read-only scopes. Revoke the token from your Atlassian account settings (under “Authorized apps”), then re-authorize and make sure you accept all requested scopes.
Project-level permission walls
The MCP server respects Atlassian’s permission model, which means if a Jira project is restricted to certain groups, Claude won’t see it. This is correct behavior, not a bug. If you need Claude to access a restricted project, your Atlassian admin needs to add your user account to the appropriate project role.
Confluence space permissions
Same issue applies to Confluence spaces. If a space is restricted, Claude can’t read it. The error message from the MCP server is usually clear about this — it’ll say the resource wasn’t found or access was denied, not give you a confusing tool failure.
Status transition failures
When updating a Jira issue’s status, the MCP server needs to use valid workflow transitions, not arbitrary status names. If you ask Claude to move an issue to “Done” but the workflow requires going through “In Review” first, the update will fail. The workaround is to be explicit about the transition: “transition PLATFORM-247 to In Review” rather than “mark PLATFORM-247 as Done.”
Rate limiting on large searches
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
If you’re querying a large Jira instance and asking for broad searches (“show me all open issues in all projects”), you’ll hit rate limits. Scope your queries to specific projects or time ranges. The MCP server passes Atlassian’s standard API rate limits through — there’s no additional buffering.
MCP client version mismatches
The @atlassian/mcp-server package updates frequently. If you installed it a few months ago, run npx -y @atlassian/mcp-server to force the latest version. Breaking changes in the tool schema between versions can cause Claude to call tools with incorrect parameters.
What to Build on Top of This
The read/write access to Jira is the foundation. Here’s where it gets interesting.
Automated triage workflows. Point Claude at your incoming Jira service desk queue and have it classify issues, assign them to the right team, and add initial diagnostic comments. The MCP server’s create/update capabilities mean Claude can do this without a human in the loop for the mechanical parts.
Cross-system context aggregation. Claude can pull a Jira issue, find the related Confluence design doc, and summarize both in a single response. This is the “search and summarize across Jira + Confluence + Compass” capability working together — useful for onboarding engineers to unfamiliar parts of the codebase.
Agent control planes. This is the deeper pattern. OpenAI’s Symphony spec uses Linear as a control plane for autonomous coding agents — defining polling intervals, per-issue workspaces, active and terminal states, retries, and handoff states. The Atlassian MCP server enables the same pattern with Jira. An agent can poll a Jira board, claim an issue by updating its assignee and status, do work, and write results back as comments or status transitions. The issue tracker becomes the coordination layer, not just a UI.
If you’re building that kind of multi-agent workflow and want to avoid writing the orchestration code yourself, MindStudio handles this at the platform level — 200+ models, 1,000+ integrations, and a visual builder for chaining agents and tools, including MCP-connected ones.
Incident response assistants. During an incident, Claude can query Compass for service ownership, pull recent Jira issues for the affected service, search Confluence for runbooks, and surface all of it in a single summary. The permission model means it only surfaces what the on-call engineer is already authorized to see.
The underlying reason all of this works is the same reason Bugzilla worked in 1998: durable state, a state machine, explicit ownership, and audit history. Terry Weissman built those primitives for Mozilla to track software defects, and they’ve survived every wave of tooling change since. The Atlassian MCP server is just making those primitives agent-accessible.
If you’re thinking about building a full application on top of this kind of structured work data — something that compiles Jira state into a custom dashboard or workflow tool — Remy takes a different approach to that problem: you write an annotated markdown spec describing the application, and it compiles a complete TypeScript backend, SQLite database, frontend, and auth layer from it. The spec is the source of truth; the generated code is derived output.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
For teams evaluating whether to build agent workflows on Jira versus Linear, the honest answer is: both are viable substrates. Linear’s opinionated model (issues → cycles → projects) produces cleaner data because people actually fill in the fields — good UX drives better data quality, which agents depend on. Jira’s configurability means it can map to almost any organizational process, but that same configurability is why every Jira deployment becomes its own maze. The Atlassian MCP server works with whatever your Jira actually looks like, maze and all.
The Anthropic partnership angle is worth understanding in context. Atlassian launched the remote MCP server in beta in May 2025 and chose Claude as its first official partner — not a generic “supports any LLM” approach, but a specific named integration. The multi-year Anthropic partnership with Atlassian Williams Racing F1 team, announced in February 2026, is a separate brand relationship, but the pattern is consistent: Anthropic is positioning Claude as the enterprise agent layer, and Atlassian owns one of the largest installed bases of structured work state in enterprise software. Jira knows the projects, the dependencies, the owners, the history, the approvals. That’s exactly the context an agent needs to do real work.
Whether or not the acquisition rumors circulating online ever materialize — and there’s no SEC filing, no formal announcement, nothing concrete — the strategic logic is obvious enough that people take the rumor seriously. That’s the tell.
Where to Take This Further
The five-question diagnostic from the source material is worth applying to every tool in your stack, not just Jira: Does it have records or just content? A state machine or just labels? Explicit ownership fields? Structural verbs (create, assign, resolve, block) or just conversational ones (reply, forward)? Queryable history or just visible history?
Jira scores well on all five. That’s why the MCP server is worth the setup time.
For Claude-specific workflows, the Claude Code Dispatch setup for remote control is a natural complement — once you have Claude reading and writing Jira, being able to trigger those workflows from a phone via Telegram changes what’s practical.
If you’re running longer autonomous coding sessions where Claude needs to track its own work state, the token management techniques for extended Claude Code sessions become relevant — the same context-window limitations that make external state (like Jira) valuable also make session management important.
For teams building on top of Claude’s capabilities more broadly, the Claude Code source code leak analysis surfaces several patterns that apply directly to MCP-based workflows, particularly around how Claude handles tool call sequencing.
The Atlassian MCP server is in production. The OAuth flow works. The permission model is sound. The interesting question now is what you build on top of it.
