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

Your team connected Claude to GitHub. Useful. But Claude still can't read the Jira ticket that explains why the code needs to change, or pull up the Confluence spec that defines the expected behavior.

I hit this gap on my own engineering team. A developer would ask Claude to help with a bug fix, and Claude had the code but none of the business context sitting in Jira and Confluence. One connection is a shortcut. Three connections working together is a workflow. Here's how to set up all three using Model Context Protocol (MCP) servers, and what it looks like when they're running side by side.

What MCP Does (30-Second Version)

MCP is the open standard that lets Claude and other compatible clients connect to external systems. Introduced by Anthropic in November 2024 and now under the Agentic AI Foundation, a Linux Foundation directed fund, it uses a simple client-server architecture with three primitives: Tools (functions the AI can call), Resources (data the AI can read), and Prompts (templates you define).

Think of it as a universal adapter. Instead of building a custom integration for every tool, you configure an MCP server once and any compatible AI client can use it. As of early 2026, thousands of MCP servers are publicly available across registries and open-source repositories.

Setting Up the GitHub MCP Server

GitHub's official MCP server gives Claude access to dozens of tools covering repository management, pull request workflows, issue tracking, CI/CD status, and security scanning alerts. The exact count depends on which toolsets you enable and your PAT scope. Setup takes one command.

In your terminal with Claude Code installed:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

That's it. No Docker container, no local process to manage. The --scope flag lets you control visibility: the default is local (current project only), --scope project writes the config into .mcp.json for your team to share, and --scope user makes it available across all your projects.

PAT scoping matters. Generate a fine-grained personal access token with only the permissions your workflow requires. If Claude just needs to read PRs and issues, don't grant write access to repository contents. Principle of least privilege applies here the same way it does everywhere else.

One note: the older @modelcontextprotocol/server-github npm package was deprecated in April 2025. If you see tutorials referencing it, skip them. Use the official server above.

Setting Up the Atlassian MCP Server

This is where it gets interesting, because you have two options depending on your deployment.

Jira Cloud + Confluence Cloud: Use Atlassian's official Rovo MCP Server. Authentication is OAuth 2.1. You'll authorize through your browser on first connection, and the server respects your existing Atlassian user permissions. No marketplace app install required.

Add it in Claude Code:

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

Rovo MCP covers Jira, Confluence, and Compass. You can search and summarize content, create issues and pages, and run cross-product queries. As of March 2026, Rovo MCP supports creating, updating, and transitioning issues through workflows, plus creating epics and linking them to Confluence pages. Some advanced write operations are still being added, so check Atlassian's supported tools documentation for the current list before designing workflows that depend on specific operations.

Jira Data Center / Server: The official Rovo MCP server is Cloud-only. For Data Center deployments, use the community-maintained sooperset/mcp-atlassian package instead. Authentication uses a personal access token rather than OAuth:

claude mcp add atlassian-dc -- \
  uvx mcp-atlassian \
  --jira-url https://jira.yourcompany.com \
  --jira-personal-token "$JIRA_PAT"

This requires uv installed on your machine. Docker is also an option if you prefer containerized setups.

Store that 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's why connecting all three matters more than connecting any one. With Jira, GitHub, and Confluence all accessible, Claude can follow the same information trail your developers follow, without the tab switching.

A real example: you're picking up ticket PROJ-142. Instead of opening three browser tabs, you ask Claude:

"Read PROJ-142 from Jira. Find the linked Confluence spec. Check if there's an open PR in the frontend repo that references this ticket. Summarize where things stand."

Claude pulls the Jira ticket details, follows the Confluence link in the ticket description, searches GitHub for PRs mentioning PROJ-142, and gives you a status summary in one response. Context that used to take five minutes of clicking now takes seconds.

This pattern scales to sprint planning, too. Claude can read a set of Jira tickets, cross-reference each against existing Confluence documentation, and flag tickets that reference outdated specs. On my team, this cut sprint planning prep time in half. The person who used to spend two hours before each planning session pulling context from three tools now spends twenty minutes reviewing what Claude already assembled.

For a deeper look at how MCP fits into broader Claude Code workflows like CI/CD integration and code review automation, see Why Claude Code Changes How SaaS Teams Ship.

What to Watch Out For

Token security. Environment variables for credentials. Always. I've seen MCP tutorials on well-known engineering blogs that drop raw tokens into JSON config files. Use .env files with .gitignore entries, or your team's secrets manager.

Cloud vs. Data Center is a real fork. The authentication model, available operations, and server packages differ. Decide which path you're on before starting setup, not halfway through.

Test before you depend on it. Rovo MCP's capabilities are expanding, but not every operation you'd expect is available yet. Before designing a workflow around a specific action, verify it works against Atlassian's current supported tools list.

One more thing worth calling out: don't wire everything up at once. Connect the two tools where your team loses the most time to context switching. For most engineering teams, that's Jira and GitHub. Add Confluence after the first two are stable. Debugging three simultaneous integrations in one afternoon is not how you want to spend a sprint.

Get Connected

The standard setup path is straightforward. The complexity shows up in permission scoping, credential management, and figuring out which workflows are worth automating first. That's what I do. If you want all three running in a day instead of debugging for a week, book a setup call.