mcp-atlassian: an MCP server that puts Jira and Confluence behind 98 tool calls

The gap this fills between an MCP client and an Atlassian instance

An MCP client such as Claude Desktop or Cursor has no native concept of a Jira issue or a Confluence page. Without a server in between, the assistant can only describe what it would do. mcp-atlassian is that server: it registers Jira and Confluence operations as MCP tools, so a natural-language request like "find issues assigned to me in PROJ project" resolves to a tool call against your instance rather than a hallucinated answer. The README frames the intended usage in exactly those terms, listing prompts such as searching Confluence for onboarding docs, creating a bug ticket, and transitioning PROJ-123 to Done. The audience is therefore narrow and identifiable: engineers and technical staff who already have an MCP client configured and who hold credentials for an Atlassian deployment. It is not a general Atlassian SDK, and it is not useful to anyone without an MCP host to connect it to. The project is MIT licensed and explicitly states it is not an official Atlassian product, which matters for anyone whose procurement process assumes vendor support.

What actually sits between the client and the Atlassian REST API

The architecture is a Python process that speaks MCP on one side and Atlassian's HTTP APIs on the other. In the default configuration the client launches it as a subprocess over stdio: the README's Claude Desktop and Cursor example uses command uvx with args ["mcp-atlassian"], and passes credentials through the env block. That means the server inherits the client's local environment and there is no listening socket, no port to firewall, and no shared state between users. The alternative documented path is HTTP transport, with the docs listing SSE and streamable-http modes plus a multi-user variant. That is a materially different deployment: the process becomes a service, and the credential question shifts from "whose laptop is this" to "how are per-user identities separated." The tool surface is the other half of the design. The README's key tools table pairs Jira operations (jira_search with JQL, jira_get_issue, jira_create_issue, jira_update_issue, jira_transition_issue) against Confluence equivalents (confluence_search with CQL, confluence_get_page, confluence_create_page, confluence_update_page, confluence_add_comment), and states there are 98 tools in total. That is a large surface for a model to choose from, and the README does not describe any tool-filtering or allowlist mechanism. If you want a read-only deployment, the material here does not show how to get one.

Getting it running: one command, six environment variables

The quick start has three steps. First, create an API token at id.atlassian.com under security/api-tokens; for Server/Data Center the README directs you to a Personal Access Token instead. Second, add a server entry to your client's MCP configuration. The documented JSON uses the mcpServers key with a single entry named mcp-atlassian, command uvx, args ["mcp-atlassian"], and an env object containing JIRA_URL, JIRA_USERNAME, JIRA_API_TOKEN, CONFLUENCE_URL, CONFLUENCE_USERNAME and CONFLUENCE_API_TOKEN. Note that CONFLUENCE_URL in the example ends in /wiki, which is the Cloud convention and a common source of 404s if copied to a Server instance with a different context path. For Server/Data Center the README says to replace JIRA_USERNAME plus JIRA_API_TOKEN with JIRA_PERSONAL_TOKEN. Third, start asking the assistant to do things. If you use Autohand Code, the README gives a one-liner: autohand mcp add mcp-atlassian env followed by the same variables and then uvx mcp-atlassian, with an optional --scope project flag to keep the configuration in the current project. The installation docs also list Docker, pip, and from-source paths, though the README does not reproduce those commands. Authentication docs additionally mention OAuth 2.0, which the quick start does not use.

Version floors, transport choices and the credential model are the real constraints

The compatibility table is the most concrete constraint in the material. Confluence Cloud and Jira Cloud are marked fully supported. Confluence Server/Data Center is supported from v6.0 and Jira Server/Data Center from v8.14. If you are on an older self-hosted Jira, this is simply the wrong tool, and the README offers no fallback or compatibility shim. The second constraint is credentials. The documented model is a single token per product, configured at the process level. In the stdio setup that token belongs to whoever launched the client, which is fine for a laptop and awkward for a shared workstation. The HTTP transport docs cover multi-user operation, but the README does not show how identity is propagated or scoped, so anyone planning a shared deployment needs to read that page before committing. Third, the write tools are genuinely write tools. jira_create_issue, jira_update_issue, jira_transition_issue, confluence_create_page, confluence_update_page and confluence_add_comment all mutate remote state, and the README does not describe a dry-run mode, a confirmation step, or a read-only flag. An assistant with a misread instruction can transition or create tickets. The security section is limited to the sentence that API tokens should never be shared and .env files kept secure, which is correct but not a control.

Where a scripted REST client or a narrower MCP server wins

The obvious alternative is calling the Atlassian REST APIs directly from a small script or an internal service, using the same API token or PAT. The difference is where the ambiguity lives. A script encodes one fixed operation with fixed parameters and produces the same result every run; mcp-atlassian hands the choice of tool and arguments to a language model at request time. That flexibility is the entire point, and it is also the source of the failure mode: 98 tools with overlapping names and JQL or CQL string arguments give a model a lot of room to pick the wrong call or build a malformed query. A narrower MCP server that exposes only, say, issue search and page retrieval would trade capability for predictability. The other alternative is to skip MCP entirely and use the Atlassian APIs from an existing automation platform your team already operates. That path avoids adding a local process to every developer machine and keeps credentials in one place, at the cost of not being reachable from a chat client. Neither alternative is strictly better; the choice depends on whether conversational access is the requirement or just a convenience.

Release cadence, upgrade exposure and what MIT does and does not cover

The release history shows a steady cadence: v0.22.1, v0.23.0 and v0.23.1 between July and August 2026, with the repository's last push in early September 2026. Three releases inside roughly two months on a 0.x version line means the surface is still moving, and the README does not document a deprecation policy for tool names or environment variables. If you pin the uvx invocation to a specific version you control the blast radius; if you run uvx mcp-atlassian unversioned, every client restart can pick up a new release. That is the practical upgrade cost, and it is worth deciding deliberately rather than by default. On licensing, the project is MIT, which is permissive and imposes few obligations beyond retaining the licence notice. It is not an official Atlassian product, so nothing here comes with vendor support or an Atlassian compatibility guarantee; the compatibility table is the project's own statement, not a vendor commitment. This is a description of the licence text, not legal advice, and anyone embedding it in a commercial product should read the LICENSE file directly.

Editorial conclusion

Adopt mcp-atlassian if your team already lives in Jira and Confluence and you want an MCP client to read and write those systems without a bespoke integration. Do not adopt it as a general-purpose Atlassian API wrapper, and do not point it at a production Jira instance with an admin-scoped token on day one. Before wiring it into a shared client, verify three things in the repository itself: which credential variables apply to your deployment (JIRA_USERNAME plus JIRA_API_TOKEN for Cloud, JIRA_PERSONAL_TOKEN for Server/Data Center), whether your Confluence Server version is at or above 6.0 and your Jira Server version at or above 8.14, and how the HTTP transport handles multiple users if you plan to run it as a shared service rather than a local stdio process.

Official sources

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