Connecting Claude to Jira, GitHub, and Confluence: An MCP Server Setup Guide

Your team wired Claude into GitHub. It reads the repo, drafts fixes, summarizes pull requests. Useful. But it still can't open the Jira ticket that explains why the code needs to change, or the Confluence spec that defines what "done" looks like.

I hit that wall on my own engineering team. A developer would ask Claude Code to help with a bug, and Claude had the code and none of the context that lived in Jira and Confluence. So I wired up all three. The first time I asked it to research a ticket, it read the ticket, its comments, the linked tickets, and the linked Confluence pages, and handed back a picture that would have taken me two hours to assemble by hand. It took about two minutes. One connection is a shortcut. Three working together is a workflow. Here's how to set up all three with Model Context Protocol (MCP) servers, and what it looks like when they run side by side.

What MCP Does Now

MCP is the open standard that lets Claude and other compatible clients read from and write to outside systems. Anthropic introduced it in November 2024. A year later it stopped being a single vendor's project: in December 2025 the Linux Foundation formed the Agentic AI Foundation, and MCP was donated to it as one of three founding projects, next to Block's goose and OpenAI's AGENTS.md. It is governed in the open now.

The mechanics are simple. A client (Claude Code) talks to a server (the piece wired into GitHub or Jira) over one standard protocol, using three primitives: Tools the model can call, Resources it can read, and Prompts you define. Think of it as a universal adapter. Configure a server once, and any compatible client can use it. The current spec is dated 2025-11-25, with a larger 2026-07-28 revision in release candidate as of late May 2026, so expect the surface to keep moving. This is past the experiment stage: Stacklok's January 2026 State of MCP report put 41% of software organizations in some form of MCP production use.

For the deeper question of when running an MCP server pays off, and where the protocol's vocabulary runs out, the MCP Servers in Production guide covers the ownership model. This post is the wiring.

Setting Up the GitHub MCP Server

GitHub is the connection you probably already have. Treat it as the first of three, not the finish line. Its official MCP server gives Claude dozens of tools across roughly two dozen toolsets: repositories, pull requests, issues, Actions and CI status, Dependabot and code-scanning alerts, and projects. Setup is one command. No Docker, no local process to babysit.

claude mcp add --transport http \
  github https://api.githubcopilot.com/mcp \
  --header "Authorization: Bearer $GITHUB_PAT"

On Claude Code 2.1.1 and newer, GitHub's install guide also shows an equivalent claude mcp add-json form; either one connects the same remote endpoint. Drop the --header flag and Claude Code falls back to a browser OAuth flow on first connection, which you finish by typing /mcp. Both work. The token route gives you finer-grained control.

The --scope flag decides who sees the config: local (default, this project, just you), project (written to .mcp.json so your team shares it), or user (all your projects).

Scope the token down. Generate a fine-grained personal access token with only the permissions the workflow needs. If Claude is reading PRs and issues, it has no business holding write access to repository contents. Least privilege applies here the same way it does everywhere else. For the full pre-connection scope review, see MCP authorization scope: least privilege before you connect.

One trap: the older @modelcontextprotocol/server-github npm package was deprecated back in April 2025. If a tutorial points you at it, close the tab and use the official server above. And once a server is wired in, treat it as a maintained dependency, because upstream APIs change underneath you. Here is how to audit an MCP server before its upstream API breaks it.

Setting Up the Atlassian MCP Server

Jira and Confluence carry the why and the what that the code alone is missing, which is the whole reason to wire up all three. Here the path forks on your deployment.

Jira Cloud and Confluence Cloud: use Atlassian's official Rovo MCP Server. Authentication for the core Jira and Confluence tools is OAuth 2.1. You authorize in the browser on first connection, and the server honors your existing Atlassian permissions. There is no marketplace app to install.

claude mcp add --transport http \
  atlassian https://mcp.atlassian.com/v1/mcp/authv2

Rovo MCP covers Jira, Confluence, Jira Service Management, Bitbucket Cloud, Compass, and a newer Atlassian Platform surface (Teamwork Graph and the cross-product search_atlassian tool): search and summarize content, create and update issues and pages, transition issues through workflows, leave comments and worklogs. One wrinkle worth knowing up front: the OAuth flow above covers Jira and Confluence, but Jira Service Management and Bitbucket tools authenticate with an API token instead. The tool list keeps growing, so check Atlassian's supported-tools doc before you build a workflow around a specific operation. One date for the calendar: the legacy SSE endpoint (/v1/sse) was slated to lose support after June 30, 2026, a date now past, which is one more reason that audit-playbook link matters.

Jira Data Center or Server: Rovo is Cloud-only. For self-hosted Atlassian, use the community-maintained sooperset/mcp-atlassian server. It carries 72 tools and stays actively maintained. Authentication is a personal access token, passed through environment variables:

claude mcp add --transport stdio atlassian-dc \
  --env JIRA_URL=https://jira.yourcompany.com \
  --env JIRA_PERSONAL_TOKEN="$JIRA_PAT" \
  -- uvx mcp-atlassian

That requires uv installed. Store the token in an environment variable. Not in a JSON config file, not in your shell history. This is the step every other setup guide skips.

The Cross-Tool Workflow

Here is why three beats one. With Jira, GitHub, and Confluence all reachable, Claude can walk the same trail your developers walk, without the tab-switching.

Say you are picking up ticket PROJ-142. Instead of opening three browser tabs, you ask:

"Read PROJ-142 from Jira. Find the linked Confluence spec. Check whether there is an open PR in the frontend repo that references this ticket. Tell me where things stand."

Claude pulls the ticket, follows the Confluence link in its description, searches GitHub for PRs that mention PROJ-142, and gives you the status in one response. That is the task that took me two hours by hand and about two minutes through Claude the first time I ran it. The pieces were scattered across several engineers' tickets, comments, and docs, and stitching them together was the slow part. Claude had no trouble.

It is not only research. My team now uses Claude Code through these servers every day to manage tickets, edit Confluence pages, leave comments, and tag the right teammates, from the same place the code lives. The connection that started as a way to read context turned into the way work moves through it.

For how this fits into larger Claude Code workflows like CI and code review, see Why Claude Code Changes How SaaS Teams Ship. Once the servers are connected, the agentic development starter guide covers building structured workflows on top of them.

Where It Bites (and What to Connect First)

Now the honest part. Connecting all three is not free, and a few things will bite you if you wire everything up in one sitting.

Context budget. Every connected server loads its tool definitions into context before you ask anything. Apideck reported three MCP servers eating 143,000 of a 200,000-token window at startup, and Microsoft Research has documented "tool-space interference," where adding tools can lower an agent's performance instead of raising it. The mitigation is built in: Claude Code's Tool Search defers a server's tool schemas until the model needs them, on by default. Still, do not connect everything at once. Wire up the two tools where your team loses the most time to context-switching, usually Jira and GitHub, then add Confluence once those are stable. Fewer overlapping tools also means less mis-selection, which is the half of the interference problem Tool Search doesn't touch.

Three servers also means three sets of credentials, and a wider attack surface than any single connection. OWASP's MCP security guidance flags cross-server risks like credential leakage and confused-deputy attacks, and a January 2026 security analysis found MCP's design can raise attack success rates by 23 to 41% over equivalent non-MCP integrations, with implicit trust between servers as a cause. Scope every token to least privilege, keep them in environment variables or a secrets manager, and decide where each one lives before you connect.

Atlassian auth has rough edges, and they're getting filed down. The Rovo server earned a reputation as a token hog with short OAuth sessions that needed constant reauthentication. That has improved: Atlassian added API-token authentication in February 2026 for longer-lived, non-interactive use, and shipped OAuth connection fixes in May. What hasn't changed is OAuth session length (tokens still expire in tens of minutes) and rate limiting (users report a large query locking them out for around half an hour, with no signal the model can see). Better than it was. Not solved.

Read what Claude writes back. This one's on you, not the tooling. Claude can create and update Confluence pages, which is useful and risky in the same breath. Don't let it publish docs that other teams, people, or other LLMs will treat as a source of truth without proofing them first. AI-written documentation compounds quietly: when the next query reads a wrong page back as fact, the mistake spreads instead of getting caught. Validate before you publish, the way you would review a pull request.

FAQ

A three-tool setup raises a few recurring questions.

What is the difference between the Atlassian Rovo MCP server and mcp-atlassian?

Rovo is Atlassian's official remote server, covering Jira, Jira Service Management, Confluence, Bitbucket Cloud, and Compass on Atlassian Cloud. sooperset/mcp-atlassian is a community-maintained server that also supports self-hosted Jira and Confluence Data Center and Server. On Cloud, reach for Rovo. On Data Center, reach for mcp-atlassian.

Do I need Docker to connect the GitHub MCP server?

No. The remote GitHub MCP server is a hosted HTTP endpoint, so a single claude mcp add command connects it. Docker only comes in if you decide to run the server locally instead of using the remote endpoint.

Should I use OAuth or an API token for the Atlassian MCP server?

Use OAuth 2.1 for interactive Cloud sessions, since it respects your existing Atlassian permissions. Atlassian added API-token authentication in February 2026 for longer-lived or non-interactive use, which sidesteps the short OAuth window. For GitHub, use a fine-grained personal access token scoped to only what the workflow touches.

Get Connected

The setup path is short, and no single connection is the point. The payoff shows up when Claude can walk Jira, GitHub, and Confluence in one pass. The work that takes judgment is everything around it: scoping each token to least privilege, deciding where credentials live, and choosing which workflows are worth automating first. That's what I do. If you'd rather have Jira, GitHub, and Confluence wired into Claude in a day than spend a week debugging it, book a setup call.