MCP Atlassian

Model Context Protocol (MCP) server for Atlassian products (Confluence, Jira, Bitbucket, and Xray for Jira). This integration supports Confluence, Jira, and Bitbucket for both Cloud and Server/Data Center deployments. Xray for Jira is available only on Server/Data Center deployments and always uses the Jira URL and credentials you configure. Note: This project is a fork from mcp-atlassian. The project at the time of making a fork has not been maintained for a while with couple of dozen pull requests and a few issues on the github project. Hence, it was about time to fork the project and make some fixes.

Example Usage

Ask your AI assistant to:

• 📝 Automatic Jira Updates - “Update Jira from our meeting notes”
• 🔍 AI-Powered Confluence Search - “Find our OKR guide in Confluence and summarize it”
• 🐛 Smart Jira Issue Filtering - “Show me urgent bugs in PROJ project from last week”
• 📄 Content Creation & Management - “Create a tech design doc for XYZ feature”
• 🧪 Test Management with Xray for Jira - “Get test execution results for the latest sprint”
• 📊 Quality Assurance Tracking - “Update test run status and add defects found during testing”

Feature Demo

https://github.com/user-attachments/assets/35303504-14c6-4ae4-913b-7c25ea511c3e

Compatibility

Quick Start Guide

🔐 1. Authentication Setup

MCP Atlassian supports four authentication methods:

A. API Token Authentication (Cloud) - Recommended

1. Go to https://id.atlassian.com/manage-profile/security/api-tokens
2. Click Create API token, name it
3. Copy the token immediately

B. Personal Access Token (Server/Data Center)

1. Go to your profile (avatar) → Profile → Personal Access Tokens
2. Click Create token, name it, set expiry
3. Copy the token immediately

C. OAuth 2.0 Authentication (Cloud) - Advanced

[!NOTE] OAuth 2.0 is more complex to set up but provides enhanced security features. For most users, API Token authentication (Method A) is simpler and sufficient.

1. Go to Atlassian Developer Console
2. Create an “OAuth 2.0 (3LO) integration” app
3. Configure Permissions (scopes) for Jira/Confluence
4. Set Callback URL (e.g., http://localhost:8080/callback)
5. Run setup wizard:

   docker run --rm -i \
     -p 8080:8080 \
     -v "${HOME}/.mcp-atlassian:/home/app/.mcp-atlassian" \
     ghcr.io/SharkyND/mcp-atlassian:latest --oauth-setup -v
   

6. Follow prompts for Client ID, Secret, URI, and Scope
7. Complete browser authorization
8. Add obtained credentials to .env or IDE config:
   • ATLASSIAN_OAUTH_CLOUD_ID (from wizard)
   • ATLASSIAN_OAUTH_CLIENT_ID
   • ATLASSIAN_OAUTH_CLIENT_SECRET
   • ATLASSIAN_OAUTH_REDIRECT_URI
   • ATLASSIAN_OAUTH_SCOPE

[!IMPORTANT] For the standard OAuth flow described above, include offline_access in your scope (e.g., read:jira-work write:jira-work offline_access). This allows the server to refresh the access token automatically.

D. Dynamic Header-Based Authentication - Multi-Tenant

[!NOTE] Header-based authentication enables dynamic, per-request credential management without requiring environment variables or server restarts. This is ideal for multi-tenant applications, serverless environments, or when credentials need to be managed dynamically.

With header-based authentication, you can pass Jira, Confluence, and Bitbucket credentials directly through HTTP headers on each request. Xray for Jira automatically reuses the Jira headers. This method supports both Personal Access Tokens (PAT) for Server/Data Center and API tokens for Cloud deployments.

Required Headers:

For Jira authentication:

• X-Atlassian-Jira-Personal-Token: Your Jira PAT or API token
• X-Atlassian-Jira-Url: Your Jira instance URL

For Confluence authentication:

• X-Atlassian-Confluence-Personal-Token: Your Confluence PAT or API token
• X-Atlassian-Confluence-Url: Your Confluence instance URL

For Bitbucket authentication:

• X-Atlassian-Bitbucket-Personal-Token: Your Bitbucket PAT or app password
• X-Atlassian-Bitbucket-Url: Your Bitbucket instance URL

For Xray for Jira authentication:

• Reuses your Jira headers (X-Atlassian-Jira-Personal-Token and X-Atlassian-Jira-Url), which must point to a Server/Data Center Jira with Xray installed.
• Xray for Jira tools are disabled by default. To enable Xray for Jira tools, set the X-Atlassian-Enable-Xray header to true.

Benefits:

• ✅ No environment variables required
• ✅ Per-request authentication
• ✅ Multi-tenant support
• ✅ Dynamic credential management
• ✅ Zero server configuration needed
• ✅ Works with both Cloud and Server/Data Center

Example MCP Client Configuration:

{
  "Atlassian": {
    "url": "http://localhost:8000/mcp",
    "headers": {
      "X-Atlassian-Jira-Personal-Token": "your_jira_pat_or_api_token",
      "X-Atlassian-Jira-Url": "https://your-jira-instance.com",
      "X-Atlassian-Confluence-Personal-Token": "your_confluence_pat_or_api_token",
      "X-Atlassian-Confluence-Url": "https://your-confluence-instance.com",
      "X-Atlassian-Bitbucket-Personal-Token": "your_bitbucket_pat_or_app_password",
      "X-Atlassian-Bitbucket-Url": "https://your-bitbucket-instance.com",
      "X-Atlassian-Read-Only-Mode": "true",
      "X-Atlassian-Jira-Read-Only-Mode": "false"
    },
    "type": "http"
  }
}

[!TIP] Per-product headers override the global X-Atlassian-Read-Only-Mode header for that product. In the example above the global flag enables read-only for Confluence and Bitbucket, while Jira remains in read/write mode.

[!TIP] Multi-Cloud OAuth Support: If you’re building a multi-tenant application where users provide their own OAuth tokens, see the Multi-Cloud OAuth Support section for minimal configuration setup.

📦 2. Installation

MCP Atlassian is distributed as a Docker image. This is the recommended way to run the server, especially for IDE integration. Ensure you have Docker installed.

# Pull Pre-built Image
docker pull ghcr.io/SharkyND/mcp-atlassian:latest

🛠️ IDE Integration

MCP Atlassian is designed to be used with AI assistants through IDE integration.

[!TIP] For Claude Desktop: Locate and edit the configuration file directly:

• Windows: %APPDATA%\Claude\claude_desktop_config.json
• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json

For Cursor: Open Settings → MCP → + Add new global MCP server

⚙️ Configuration Methods

There are three main approaches to configure the Docker container:

1. Passing Variables Directly (shown in examples below)
2. Using an Environment File with --env-file flag (shown in collapsible sections)
3. Header-Based Authentication (no environment variables required - see Header-Based Authentication Configuration)

[!NOTE] Common environment variables include:

• CONFLUENCE_SPACES_FILTER: Filter by space keys (e.g., “DEV,TEAM,DOC”)
• JIRA_PROJECTS_FILTER: Filter by project keys (e.g., “PROJ,DEV,SUPPORT”)
• READ_ONLY_MODE: Set to true to disable write operations for all products
• JIRA_READ_ONLY_MODE: Set to true to disable write operations for Jira only
• CONFLUENCE_READ_ONLY_MODE: Set to true to disable write operations for Confluence only
• BITBUCKET_READ_ONLY_MODE: Set to true to disable write operations for Bitbucket only
• MCP_VERBOSE: Set to “true” for more detailed logging
• MCP_LOGGING_STDOUT: Set to “true” to log to stdout instead of stderr
• ENABLED_TOOLS: Comma-separated list of tool names to enable (e.g., “confluence_search,jira_get_issue”)

Header-Based Authentication (no environment variables needed):

• X-Atlassian-Jira-Personal-Token: Jira PAT/API token (passed as HTTP header), used for XRay as well
• X-Atlassian-Jira-Url: Jira instance URL (passed as HTTP header), used for XRay as well
• X-Atlassian-Confluence-Personal-Token: Confluence PAT/API token (passed as HTTP header)
• X-Atlassian-Confluence-Url: Confluence instance URL (passed as HTTP header)
• X-Atlassian-Bitbucket-Url: Bitbucket URL (passed as HTTP header)
• X-Atlassian-Bitbucket-Personal-Token: Bitbucket PAT token (passed as HTTP header)
• X-Atlassian-Read-Only-Mode: Global per-request read-only mode — applies to all products (passed as HTTP header)
• X-Atlassian-Jira-Read-Only-Mode: Per-request read-only mode for Jira only (passed as HTTP header)
• X-Atlassian-Confluence-Read-Only-Mode: Per-request read-only mode for Confluence only (passed as HTTP header)
• X-Atlassian-Bitbucket-Read-Only-Mode: Per-request read-only mode for Bitbucket only (passed as HTTP header)
• X-Atlassian-Enable-Xray: Enable/disable Xray for Jira tools (disabled by default)

See the .env.example file for all available options.

📝 Configuration Examples

Method 1 (Passing Variables Directly):

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "CONFLUENCE_URL",
        "-e", "CONFLUENCE_USERNAME",
        "-e", "CONFLUENCE_API_TOKEN",
        "-e", "JIRA_URL",
        "-e", "JIRA_USERNAME",
        "-e", "JIRA_API_TOKEN",
        "-e", "BITBUCKET_URL",
        "-e", "BITBUCKET_USERNAME",
        "-e", "BITBUCKET_APP_PASSWORD",
        "ghcr.io/SharkyND/mcp-atlassian:latest"
      ],
      "env": {
        "CONFLUENCE_URL": "https://your-company.atlassian.net/wiki",
        "CONFLUENCE_USERNAME": "[email protected]",
        "CONFLUENCE_API_TOKEN": "your_confluence_api_token",
        "JIRA_URL": "https://your-company.atlassian.net",
        "JIRA_USERNAME": "[email protected]",
        "JIRA_API_TOKEN": "your_jira_api_token",
        "BITBUCKET_URL": "https://bitbucket.org",
        "BITBUCKET_USERNAME": "[email protected]",
        "BITBUCKET_APP_PASSWORD": "your_bitbucket_app_password"
      }
    }
  }
}

👥 HTTP Transport Configuration

Instead of using stdio, you can run the server as a persistent HTTP service using either:

• sse (Server-Sent Events) transport at /sse endpoint
• streamable-http transport at /mcp endpoint

Both transport types support single-user and multi-user authentication:

Authentication Options:

• Single-User: Use server-level authentication configured via environment variables
• Multi-User: Each user provides their own authentication:
  • Cloud: OAuth 2.0 Bearer tokens
  • Server/Data Center: Personal Access Tokens (PATs)

Monitoring

Username Requirement

Enforce username headers in requests by setting REQUIRE_USERNAME=true only for monitoring purpose. When the enviroment variable is passed in as true, it will be enable prometheus client to caputre username from the header and avalible to scrape through the service monitor:

# Environment variable
REQUIRE_USERNAME=true

# Helm chart
env:
  REQUIRE_USERNAME: "true"

When enabled, requests must include at least one username header:

• X-Atlassian-Username

Returns 400 error if missing when enabled.

Monitoring & Metrics

Prometheus Metrics available at /metrics endpoint:

• Request counts, duration, errors by service
• User activity tracking (when username headers provided)
• Pod-specific metrics for Kubernetes deployments

Health Checks:

• /healthz - Basic health status
• /readyz - Kubernetes readiness probe

Kubernetes Integration:

• Helm chart with monitoring configuration
• Grafana dashboard provisioning via ConfigMaps
• ServiceMonitor for Prometheus Operator

Read-Only Mode

Read-only mode removes all tools tagged with write from tool discovery and blocks direct calls to write handlers. Unless configured, the server runs in read/write mode.

Read-only mode can be controlled globally (all products) or per-product (Jira, Confluence, Bitbucket independently). The effective state is recalculated on every request using this priority (highest first):

Truthy values: true, 1, yes, on. Falsy values: false, 0, no, off. A falsy value at a higher priority overrides a truthy value at a lower priority.

When enabled for a product, its write tools are hidden in tools/list, and the @check_write_access decorator raises ValueError if a client tries to invoke one directly.

CLI flags

# All products read-only
uv run mcp-atlassian --transport streamable-http --port 8889 --read-only

# Per-product: only Jira is read-only
uv run mcp-atlassian --transport streamable-http --port 8889 --jira-read-only

# Combined: Jira and Confluence read-only, Bitbucket stays read/write
uv run mcp-atlassian --transport streamable-http --port 8889 --jira-read-only --confluence-read-only

Environment variables

# Global — all products
set READ_ONLY_MODE=true               # Windows CMD
$Env:READ_ONLY_MODE = "true"          # PowerShell
export READ_ONLY_MODE=true            # macOS/Linux

# Per-product overrides
$Env:JIRA_READ_ONLY_MODE = "true"      # Jira only
$Env:CONFLUENCE_READ_ONLY_MODE = "true" # Confluence only
$Env:BITBUCKET_READ_ONLY_MODE = "true" # Bitbucket only

# Example: global read-only, but Jira stays read/write
$Env:READ_ONLY_MODE = "true"
$Env:JIRA_READ_ONLY_MODE = "false"

HTTP headers (per-request)

Headers let you override the server defaults on a per-request basis without restarting.

{
  "headers": {
    "X-Atlassian-Read-Only-Mode": "true",
    "X-Atlassian-Jira-Read-Only-Mode": "false",
    "X-Atlassian-Confluence-Read-Only-Mode": "true",
    "X-Atlassian-Bitbucket-Read-Only-Mode": "false"
  }
}

A per-product header always takes precedence over the global header for that product. In the example above, the global flag enables read-only for all products, but the Jira and Bitbucket headers override it back to read/write.

Tools

Key Tools

Jira Tools

• jira_get_issue: Get details of a specific issue
• jira_search: Search issues using JQL
• jira_create_issue: Create a new issue
• jira_update_issue: Update an existing issue
• jira_transition_issue: Transition an issue to a new status
• jira_add_comment: Add a comment to an issue
• jira_summarize_attachments: Extract readable text from PDF/Office/CSV/JSON attachments (via Microsoft MarkItDown)
• jira_get_attachment_images: Fetch image attachments as viewable image content so a vision-capable client model can describe them

Confluence Tools

• confluence_search: Search Confluence content using CQL
• confluence_get_page: Get content of a specific page
• confluence_create_page: Create a new page
• confluence_update_page: Update an existing page

Bitbucket Tools

• list_workspaces_or_projects: List all accessible workspaces/projects
• list_repositories: List repositories in a workspace or all accessible repositories
• get_repository_info: Get detailed information about a specific repository
• list_branches: List all branches in a repository
• get_default_branch: Get the default branch of a repository
• get_file_content: Get content of a specific file from a repository
• list_directory: List contents of a directory in a repository
• list_pull_requests: List pull requests for a repository
• pull_request_activities: Get activities/comments for a pull request
• get_pull_request: Get detailed information about a specific pull request
• get_commit_changes: Get changes made in a specific commit
• get_commits: Get commit history for a repository
• create_pull_request: Create a new pull request
• create_branch: Create a new branch in a repository
• add_pull_request_blocker_comment: Add a blocking comment to a pull request
• add_pull_request_comment: Add a regular comment to a pull request
• add_pull_request_inline_comment: Add an inline comment on a specific line of a file in a pull request

Xray Tools

• get_tests: Retrieve information about specific tests
• get_test_statuses: Get all available test statuses
• get_test_runs: Get test runs for a specific test
• get_test_runs_in_context: Get test runs from a Test Execution, optionally including selected Test issue custom fields
• get_test_run: Get an individual run with its execution metadata and steps
• get_test_executions: Get test executions for a test
• get_test_plans: Get test plans associated with a test
• create_test_step: Create a new test step for a test
• update_test_step: Update an existing test step
• update_test_run_status: Update the status of a test run
• update_test_run_defects: Associate defects with a test run

*Tool only available on Jira Cloud

Tool Filtering and Access Control

The server provides two ways to control tool access:

1. Tool Filtering: Use --enabled-tools flag or ENABLED_TOOLS environment variable to specify which tools should be available:

   # Via environment variable
   ENABLED_TOOLS="confluence_search,jira_get_issue,jira_search"
   
   # Or via command line flag
   docker run ... --enabled-tools "confluence_search,jira_get_issue,jira_search" ...
   

2. Read/Write Control: Tools are categorized as read or write operations. When READ_ONLY_MODE is enabled, only read operations are available regardless of ENABLED_TOOLS setting.

Troubleshooting & Debugging

Common Issues

• Authentication Failures:
  • For Cloud: Check your API tokens (not your account password)
  • For Server/Data Center: Verify your personal access token is valid and not expired
  • For older Confluence servers: Some older versions require basic authentication with CONFLUENCE_USERNAME and CONFLUENCE_API_TOKEN (where token is your password)
• SSL Certificate Issues: If using Server/Data Center and encounter SSL errors, set CONFLUENCE_SSL_VERIFY=false or JIRA_SSL_VERIFY=false
• Permission Errors: Ensure your Atlassian account has sufficient permissions to access the spaces/projects
• Custom Headers Issues: See the “Debugging Custom Headers” section below to analyze and resolve issues with custom headers

Debugging Custom Headers

To verify custom headers are being applied correctly:

1. Enable Debug Logging: Set MCP_VERY_VERBOSE=true to see detailed request logs

   # In your .env file or environment
   MCP_VERY_VERBOSE=true
   MCP_LOGGING_STDOUT=true
   

2. Check Header Parsing: Custom headers appear in logs with masked values for security:

   DEBUG Custom headers applied: {'X-Forwarded-User': '***', 'X-ALB-Token': '***'}
   

3. Verify Service-Specific Headers: Check logs to confirm the right headers are being used:

   DEBUG Jira request headers: service-specific headers applied
   DEBUG Confluence request headers: service-specific headers applied
   

4. Test Header Format: Ensure your header string format is correct:

   # Correct format
   JIRA_CUSTOM_HEADERS=X-Custom=value1,X-Other=value2
   CONFLUENCE_CUSTOM_HEADERS=X-Custom=value1,X-Other=value2
   
   # Incorrect formats (will be ignored)
   JIRA_CUSTOM_HEADERS="X-Custom=value1,X-Other=value2"  # Extra quotes
   JIRA_CUSTOM_HEADERS=X-Custom: value1,X-Other: value2  # Colon instead of equals
   JIRA_CUSTOM_HEADERS=X-Custom = value1               # Spaces around equals
   

Security Note: Header values containing sensitive information (tokens, passwords) are automatically masked in logs to prevent accidental exposure.

Debugging Tools

# Using MCP Inspector for testing
npx @modelcontextprotocol/inspector uvx mcp-atlassian ...

# For local development version
npx @modelcontextprotocol/inspector uv --directory /path/to/your/mcp-atlassian run mcp-atlassian ...

# View logs
# macOS
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log
# Windows
type %APPDATA%\Claude\logs\mcp*.log | more

Security

• Never share API tokens
• Keep .env files secure and private
• See SECURITY.md for best practices

Contributing

We welcome contributions to MCP Atlassian! If you’d like to contribute:

1. Check out our CONTRIBUTING.md guide for detailed development setup instructions.
2. Make changes and submit a pull request.

We use pre-commit hooks for code quality and follow semantic versioning for releases.

License

Licensed under MIT - see LICENSE file. This is not an official Atlassian product.