Atlassian Rovo MCP Server: connecting Jira and Confluence to Claude, Cursor and VS Code

The gap this server fills between an AI client and Atlassian Cloud

An AI coding assistant can read your repository but not your issue tracker. That split is the problem here. The assistant knows what the code does and nothing about why the ticket exists, who is blocked, or what the linked Confluence page decided three sprints ago. Atlassian's answer is a Model Context Protocol server that exposes Jira, Confluence, Jira Service Management, Bitbucket, Compass, Loom and platform data such as Projects, Goals, Teams and the Teamwork Graph to any MCP-compatible client.

The audience is narrower than the topic list suggests. This is for teams on Atlassian Cloud whose engineers already work inside Claude, ChatGPT, Cursor, VS Code or similar tools and want issue context to arrive without a browser tab switch. The README frames the value as summarizing and searching across those products, retrieving Loom recordings, and creating or updating work items. If your organization runs Jira Data Center or Server, this is not the integration for you, because the README describes the server as hosted on Atlassian Cloud.

A cloud-hosted bridge, not a process you run

The architecture is the part most readers get wrong. This is not a local stdio server that you start alongside your editor. The README calls it a cloud-based bridge between your Atlassian Cloud site and compatible external tools, and the badge line lists Hosting as Atlassian Cloud. Your AI client connects outward to Atlassian's endpoint; Atlassian's service holds the credentials and calls the product APIs on your behalf.

Authentication is OAuth 2.1 or API tokens, and the README states that every action respects the user's existing access controls. That sentence is doing real work: the server does not grant a new permission surface, it inherits the permissions of whoever authorized it. The consequence is that a read-only Jira user gets read-only tool results, and an admin who authorizes the connection gives the AI client admin-scoped reach. Scope is decided at authorization time, not by the server.

The repository itself is thin. Top-level entries include .claude-plugin/, .cursor-plugin/, .mcp.json, mcp.json, plugin.json, gemini-extension.json, server.json, skills/ and scripts/. The package.json declares the package private with no runtime dependencies, and its only scripts are test and validate, running node --test over scripts/*.test.mjs and scripts/validation/*.test.mjs. In other words, this repository distributes client manifests, skills and validation tooling for a service that runs elsewhere. There is no server source to audit here, and the README does not claim otherwise.

Installing the client plugin and making a first Jira query

Because the server is hosted, installation means registering it with your AI client. The repository ships per-client manifests (.claude-plugin/, .cursor-plugin/, .mcp.json, plugin.json, gemini-extension.json), and the README points to the Getting started page under support.atlassian.com for the current steps. The README does not print a raw endpoint URL or a copy-paste command, so treat the client's own plugin or extension flow as the install path rather than a shell command.

If your client reads an MCP configuration file, the shape is the usual one: a named server entry pointing at the remote endpoint. Do not invent the URL; take it from the Atlassian getting-started documentation for your site.

{
  "mcpServers": {
    "atlassian": {
      "url": "<endpoint from Atlassian getting-started docs>"
    }
  }
}

The repository's own validation script checks template consistency rather than your live connection, and it needs the yaml dev dependency:

npm install
npm run validate
npm test

After the client connects, the expected flow is an OAuth 2.1 consent screen against your Atlassian Cloud site, or an API token if your client cannot complete the browser flow. Once authorized, ask the assistant something specific, such as listing the open work items assigned to you in a named Jira project. If you get an authorization error rather than an empty list, the problem is consent or site policy, not the query. The README does not document a rollback or disconnect procedure, so check the client's server settings and your Atlassian site's connected-app controls for revoking the grant.

Where the hosted model bites: data center, air gaps and audit

The clearest limitation is the one the README states as a feature: the server is hosted on Atlassian Cloud. Any environment that cannot send issue content through a vendor-hosted service is out, regardless of how well the client integration works. That rules out Jira Data Center and Server deployments, and it rules out teams whose Confluence spaces hold material that cannot leave a controlled network.

The second limitation is observability. Because the server runs on Atlassian's side, you cannot read its logs, pin a version, or reproduce a tool call locally. When a tool returns something unexpected, your debugging surface is the client's transcript and Atlassian's support channels. The repository's test suite validates templates; it does not exercise the hosted service, so passing npm test tells you nothing about whether your site's tools work.

Third, the repository is not the product. If you arrived expecting an npm package you can run behind your firewall, the package.json will disappoint you: it is private, has no runtime dependencies, and defines only test and validate. The README also does not document rate limits, timeout behavior, or what happens when a client requests a tool your site has disabled. Plan for those as unknowns, not as documented guarantees.

How this differs from community Jira MCP servers

The alternative most engineers reach for is a community MCP server that talks to Jira's REST API with a personal token and runs as a local process. The difference is not cosmetic. A local community server gives you the source, a process you can restart, and logs you can read; you choose the token, and you can point it at a self-hosted instance. You also own the tool surface, the upgrade path and the security review.

Atlassian's server inverts every one of those. You get an officially maintained integration that covers more than Jira (Confluence, Jira Service Management, Bitbucket, Compass, Loom, and platform data through the Teamwork Graph), OAuth 2.1 as a first-class option alongside API tokens, and permission inheritance from the authorizing user. In exchange you give up self-hosting, source-level audit of the request path, and version pinning.

There is a practical middle ground: many teams run a local community server for a single product and this one for cross-product context. That is a reasonable split, but it doubles the number of places a token or grant lives, so decide deliberately rather than by default.

Maintenance, licence and what the repository actually commits you to

The repository is not archived, and its last push was on 2026-09-09, which is recent enough that the manifests and skills are being touched. Note what that does and does not tell you: the hosted service can change without any push to this repository, and a quiet repository does not mean a quiet service. The version you depend on is the one Atlassian deploys, not a tag you can read here.

Licensing is Apache-2.0, and the LICENSE file sits at the repository root. That covers the repository contents: the client manifests, the skills directory, the validation scripts. It does not, by itself, describe the terms of the hosted service, which is a separate question governed by your Atlassian agreement. If your legal review depends on the licence of the thing processing your issue data, the Apache-2.0 file is not the document you need. This is not legal advice; route the question to whoever handles your Atlassian contract.

Upgrade cost is low on your side and opaque on Atlassian's. Your client picks up manifest changes from the repository or the client's own plugin channel. Server-side changes arrive without a changelog you can subscribe to from here, and the README does not describe a deprecation policy for tools. If a tool your workflow depends on changes shape, you will find out from a failed call.

Editorial conclusion

Adopt it if your work already lives in Atlassian Cloud and you want an AI client to read and write Jira and Confluence items under the user's own permissions, since the README states every action respects existing access controls. Do not adopt it if you run Jira Data Center or Server, or if you need to inspect or patch the server process, because the README describes it as cloud-hosted on Atlassian Cloud and the repository holds plugins, skills and validation scripts rather than server source. Verify three things first: that your site's admin has enabled the Rovo MCP server, which of the supported tools your client actually exposes, and whether your client can complete the OAuth 2.1 flow or must fall back to an API token.

Frequently asked questions

Official sources

1. atlassian/atlassian-mcp-server on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README