You can connect Jira and Confluence to Claude in a few minutes using the Model Context Protocol (MCP), through Atlassian’s own remote MCP server. Once it’s connected, Claude can look up issues, search Confluence pages, and draft or update both without you copying ticket text back and forth. This guide covers both ways to do it: Atlassian’s server connected directly, and connecting it through a gateway if you also use other AI clients or tools.
What the Atlassian MCP server actually does
Atlassian publishes one official remote MCP server at mcp.atlassian.com/v1/mcp that covers Jira, Confluence, and Bitbucket in a single connection. It exposes your site’s issues and pages as tools Claude can call directly, instead of you switching tabs to look something up. In practice that means prompts like:
- “What’s still open in the current sprint for the platform team?”
- “Create a Jira ticket for the bug we just found, assign it to me.”
- “Find the Confluence page on our deploy process and summarize it.”
- “Update PROJ-482’s status to In Review and add a comment.”
Claude reads and writes through the same permissions your Atlassian account already has — it isn’t a separate export or read-only mirror, it’s your account acting on your behalf across whichever Jira and Confluence spaces you can already reach.
Option 1: Connect Atlassian to Claude directly
Claude supports remote MCP servers natively. The short version of the setup:
- Open Claude’s connector or MCP settings.
- Add a remote server pointing at Atlassian’s MCP endpoint.
- Sign in with your Atlassian account when prompted — this is standard OAuth, so Claude never sees your Atlassian password, and you can revoke access from Atlassian’s own account settings at any time.
That’s enough for one person using Jira and Confluence inside Claude. The tradeoffs show up once you add a second tool or a second person: every additional AI client (ChatGPT, Cursor, an agent) needs its own copy of that same connection, its own OAuth grant, and its own place where the config can go stale or get lost.
Option 2: Connect it once, through a gateway
If you’re already juggling more than one MCP server, or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl we wrote about in what an MCP gateway is. The alternative is connecting Atlassian (and everything else) to one gateway URL, then pointing every AI client at that single URL instead of reconfiguring each one.
With gate specifically, connecting Atlassian looks like this: add gate’s gateway URL to Claude once, then pick Atlassian from the Atlassian server page in the directory and sign in with OAuth the same way you would directly. From then on, Jira and Confluence are available in every client connected to your gate URL — Claude, ChatGPT, or Cursor — without a second setup step. You can see the full list of servers set up this way on the MCP servers page.
Why the connection method matters for Jira and Confluence
Atlassian is worth a moment’s thought before you connect it, because one grant covers three products at once: Jira, Confluence, and Bitbucket. That’s a wider surface than a single-purpose server. A few things worth checking before or right after you connect:
- Is it the official endpoint? Connect Atlassian’s documented server (
mcp.atlassian.com), not a third-party mirror claiming to proxy it. - What can it write, not just read? The same connection that lets Claude look up a ticket also lets it create, edit, and reassign issues, and edit Confluence pages. Know that before you hand it a broad prompt like “clean up the backlog.”
- Which sites and spaces does it reach? One Atlassian OAuth grant can span every site your account belongs to, not just the one project you had in mind.
- Who else on your team can reach it? If more than one teammate connects Atlassian to their own AI client, you likely want a shared, revocable setup rather than everyone holding their own token. That’s the same access-control question we cover in MCP access control for teams.
You can run a quick, no-signup check on any server’s tool list — including ones that require OAuth, once connected — with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.
Troubleshooting the connection
A few things that commonly go wrong when connecting any remote MCP server, Atlassian included:
- OAuth loop or sign-in fails. Make sure you’re signed into the right Atlassian site in your browser before authorizing — a mismatched site or organization is the most common cause.
- Claude can’t find an issue or page you know exists. Atlassian’s tools respect your permissions in Jira and Confluence themselves — if a project or space isn’t shared with your account, Claude won’t see it either.
- Tools disappear after an Atlassian update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that kind of change is exactly what drift detection is meant to catch.
The bottom line
Connecting Jira and Confluence to Claude with MCP takes a few minutes either way: point Claude directly at Atlassian’s server and sign in, or connect it once through a gateway if you want the same access available in every AI client you use, with the server’s tools checked before they go live. Either way, treat the OAuth grant for a connection that spans three products the same way you’d treat any other broad permission — worth a minute’s thought before you say yes.