mcp-atlassian: A Jira and Confluence MCP Server You Run Yourself

What mcp-atlassian Bridges, and Who Feels the Pain

Jira and Confluence hold the context an assistant needs to answer real questions: which issues are open, what a page says, why a ticket moved to Done. None of that is reachable from a chat client by default. mcp-atlassian is an MCP server that sits between the two, translating assistant requests into Jira and Confluence API calls and returning the results in a shape the model can read.

The project description in pyproject.toml frames it as an open-source implementation that follows Anthropic's MCP specification. The README lists Jira and Confluence side by side, with 98 tools total. The split matters: Jira tools cover search with JQL, issue retrieval, creation, updates and status transitions; Confluence tools cover search with CQL, page retrieval, page creation and updates, and comments.

The audience is narrow and specific. It is for engineers and technical program managers who already use an MCP-capable client (Claude Desktop and Cursor appear in the README's configuration example) and who have Jira or Confluence credentials they are willing to hand to a local process. It is not a reporting tool, not a dashboard, and not a replacement for the Atlassian web UI. If you never type JQL, this server adds little.

How the Server Talks to Jira and Confluence

The architecture is a Python process, not a service mesh. pyproject.toml declares a console script, mcp-atlassian, mapped to the package entry point, and the dependency list shows what does the work: atlassian-python-api for the product APIs, fastmcp and mcp for the protocol layer, markdownify and markdown-to-confluence for converting between Markdown and Confluence's storage format, and pydantic for the tool schemas.

The data flow is request-shaped. An MCP client asks the server for its tool list, the model picks a tool such as jira_search or confluence_get_page, and the server calls the corresponding Atlassian endpoint with the credentials from the environment. Responses come back as text the model can reason over. Nothing is cached in a database you have to operate; the dependency list includes fakeredis and cachetools, which points to in-process caching rather than an external store.

Authentication is auto-detected, and the .env.example spells out the precedence order: OAuth standard first if a client ID and secret are set, then OAuth BYOT if an access token is present, then username plus API token (basic auth, described as recommended for Cloud), then a personal access token when the URL is Server or Data Center, then ATLASSIAN_OAUTH_ENABLE=true for a minimal per-request token flow. That ordering is convenient and also a source of confusion: a stray environment variable can change which method the server picks, and the README points to the authentication docs rather than explaining the failure modes.

Installing mcp-atlassian and Wiring It Into Claude Desktop

The README's quick start does not ask you to install anything into a project. It uses uvx, which runs the published package in an ephemeral environment, so the configuration is the whole install.

First create an API token at the Atlassian token management page linked in the README. For Server or Data Center, the README says to use a personal access token instead.

Then add a server block to your Claude Desktop or Cursor MCP configuration. The README gives this exact shape:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://your-company.atlassian.net",
        "JIRA_USERNAME": "[email protected]",
        "JIRA_API_TOKEN": "your_api_token",
        "CONFLUENCE_URL": "https://your-company.atlassian.net/wiki",
        "CONFLUENCE_USERNAME": "[email protected]",
        "CONFLUENCE_API_TOKEN": "your_api_token"
      }
    }
  }
}

After restarting the client, the server should appear in its MCP server list, and the model should be able to call tools such as jira_search. If you prefer a CLI-managed configuration, the README also shows an autohand variant that registers the same uvx server with credentials passed as environment assignments:

autohand mcp add mcp-atlassian env \
  JIRA_URL=https://your-company.atlassian.net \
  [email protected] \
  JIRA_API_TOKEN=your_api_token \
  CONFLUENCE_URL=https://your-company.atlassian.net/wiki \
  [email protected] \
  CONFLUENCE_API_TOKEN=your_api_token \
  uvx mcp-atlassian

The README notes that adding --scope project after add keeps the configuration in the current project. A first real use is to ask the assistant to find issues assigned to you in a project, which exercises jira_search with JQL. The README's own example prompts are "Find issues assigned to me in PROJ project", "Search Confluence for onboarding docs", "Create a bug ticket for the login issue" and "Update the status of PROJ-123 to Done". Note that the last two write to your instance.

For deployments that are not one person on one laptop, the Dockerfile builds a Python 3.13 Alpine image with a non-root app user, and the repository also ships a helm directory. The README's installation docs cover uvx, Docker, pip and building from source; the README itself only shows uvx.

Where mcp-atlassian Gets Awkward

The most concrete limitation is the credential model. The server authenticates as whoever owns the token, so every tool it exposes acts with that identity's permissions. There is no per-request user identity in the stdio setup shown in the README. If you point it at a token belonging to an admin, an assistant can call jira_transition_issue or confluence_update_page with admin reach. The README's security section says to never share API tokens and to keep .env files secure, which is true but thin for a tool that can mutate tickets and pages.

The second issue is deployment compatibility. The compatibility table states Confluence Server/Data Center is supported from v6.0+ and Jira Server/Data Center from v8.14+. Older instances are outside the supported range, and the README does not describe a fallback.

The third is authentication ambiguity. Because the server auto-detects the method from whichever variables are present, a half-configured environment can silently select a different path than you intended. The .env.example documents the precedence order, but the README defers the details to the authentication docs page, and neither the README nor .env.example explains what happens when two methods are both partially configured.

Finally, this is the wrong tool if you want a hosted integration with a vendor SLA. It is a self-run process. Uptime, upgrades and secret storage are yours.

mcp-atlassian Against the Atlassian Remote MCP Server

The obvious alternative is Atlassian's own remote MCP server, which the README does not discuss; the comparison here rests only on what this repository documents about itself. The difference in approach is deployment and control. A remote server is operated by the vendor, authenticates through Atlassian's own OAuth flow, and requires no local process or Docker image. mcp-atlassian is a local process you configure with environment variables, and it supports Server and Data Center deployments that a cloud-hosted option would not reach.

That cuts both ways. Running it yourself means the credentials sit in your configuration file and the process runs on your machine, which some teams prefer for data-residency reasons and others consider a liability. The README's project description claims the design keeps data private, and the architecture supports that reading, since calls go from your machine to Atlassian directly.

The tool surface also differs in kind. This project exposes 98 tools across both products, including write operations such as jira_create_issue and confluence_add_comment. A narrower integration that only reads would be a safer starting point for a pilot, and mcp-atlassian does not offer a documented read-only mode in the README.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-05. Recent releases are v0.23.1 on 2026-08-19, v0.23.0 on 2026-07-18 and v0.22.1 on 2026-07-11, so the release cadence over that window is roughly monthly. That is a useful signal for planning upgrades: expect to move versions more than once a quarter.

Upgrade cost depends on how you installed it. With uvx, the client fetches the latest published package each time it starts, so upgrades happen without your intervention and without a pin unless you add one. With Docker, you rebuild or pull a new image; the Dockerfile accepts a VERSION build argument so the image reports the correct version even without a .git directory, which suggests versioned images are the intended path. From source, you track uv.lock.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive, so internal use and modification carry few obligations beyond preserving the notice. The README also states plainly that this is not an official Atlassian product, which matters if your procurement process assumes vendor support. None of this is legal advice; check how your organisation treats permissively licensed tools that touch production systems.

One dependency worth watching: mcp is pinned to >=1.27.0,<2.0.0 and fastmcp to >=3.4.4,<4.0.0. A major version bump in either will require a project release before you can move.

Editorial conclusion

Adopt mcp-atlassian if your team already lives in Jira or Confluence and wants an MCP client to read and write that data without a hosted middleman; the MIT licence and the uvx one-liner make the trial cheap. Skip it if you need fine-grained per-user permission mapping that mirrors Jira's own scheme, or if you cannot accept that the server holds credentials for everything its tools can reach. Before rolling it out, verify which authentication method your deployment actually needs (Cloud API token versus Server/Data Center personal token), and confirm that the write tools you intend to expose are the ones you want an assistant calling.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sooperset/mcp-atlassian on GitHub