Jira MCP for Data Center and Self-Hosted Jira

Atlassian’s own MCP server does not reach Jira Data Center or Jira Server. Atlassian documents the Rovo MCP Server as a cloud-hosted service for Atlassian Cloud apps, and its prerequisites ask for an Atlassian Cloud site; there is no self-hosted edition. If your Jira runs on your own servers, the working route today is an MCP server you run yourself, which calls your instance’s REST API with a personal access token. That choice is less about which project to install and more about where the server runs, whose token it holds, and what it is allowed to change.

This piece is only about self-hosted Jira. If you are on Atlassian Cloud, the setup guides are Jira MCP with Claude Code, in Cursor and with GitHub Copilot; what the cloud server’s tools cover is in what the Jira MCP server can do.

What Atlassian’s documentation says today

Atlassian’s developer documentation↗ (opens in a new tab) describes the Atlassian Rovo MCP Server as a cloud-hosted MCP server that connects AI clients to your Atlassian Cloud apps. It lives at one Atlassian address, signs you in with OAuth or an Atlassian Cloud API token, and applies the permissions of your cloud account. None of that has a counterpart on a server inside your own network, and the documentation describes no Data Center or Server version of it.

The longer-term picture matters when you decide how much to invest. Atlassian has announced that Data Center reaches end of life↗ (opens in a new tab) on 28 March 2029: subscriptions expire on that date and the products become read-only, and new customers could no longer buy Data Center from 30 March 2026. If your organisation plans to move to Cloud before then, the official server becomes available when you do. If not, what you build now needs to last until the move or the end date.

The one official bridge, and what it is not

Atlassian does offer a way to bring Data Center content into its cloud AI. An organisation admin can connect Jira Data Center to Teamwork Graph↗ (opens in a new tab), which indexes projects, issues and comments from up to three Data Center instances so that Rovo can find them. It needs an Atlassian Cloud organisation, a recent Jira Data Center release (11.0, or 10.3.10 LTS and later), and it respects Jira permissions.

That is a search connector, not an MCP server for your instance. The documentation describes bringing Data Center content in so it can be found; it does not describe an assistant creating, editing or transitioning issues on your Data Center site through it. If you already have a cloud organisation and want answers across both, ask your admin about it. If you want an assistant to do work in self-hosted Jira, read on.

The practical route: a server you run

An MCP server is a small program that turns tool calls into something else, here REST calls to your Jira base URL. The MCP specification↗ (opens in a new tab) defines two standard transports: stdio, where your assistant starts the server as a local process and talks to it over standard input and output, and streamable HTTP, where the server runs as a service at an address. For self-hosted Jira that gives you three decisions:

• Where the server runs: on each person’s machine, launched by their assistant, or once as a shared service inside your network.
• Which credential it holds: a personal access token belonging to a real person, or a token for a dedicated account with narrower permissions.
• Which tools it exposes: everything the project offers, or a read-only subset you chose on purpose.

The most widely used open-source option is mcp-atlassian↗ (opens in a new tab). Its README says it supports both Cloud and Server/Data Center, lists Jira 8.14 and later and Confluence 6.0 and later for self-hosted instances, is MIT-licensed, and is not an official Atlassian product. It runs with uvx, pip or Docker, over stdio or streamable HTTP. A minimal local set-up for Data Center looks like this in a client’s MCP configuration:

{
  "mcpServers": {
    "jira": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://jira.your-company.com",
        "JIRA_PERSONAL_TOKEN": "<your personal access token>",
        "READ_ONLY_MODE": "true"
      }
    }
  }
}

Its documentation lists more settings worth knowing before you roll it out: ENABLED_TOOLS to expose only named tools, JIRA_PROJECTS_FILTER to limit it to certain projects, proxy variables for a corporate proxy, client-certificate (mTLS) authentication for instances that require it, and a multi-user HTTP mode in which each request carries its own token. Treat any community server as code you are choosing to trust: pin a version, read what the tools do, and upgrade on purpose rather than by default.

Personal access tokens: what they carry

On Data Center and Server, the credential for this kind of integration is a personal access token. Atlassian’s documentation on personal access tokens↗ (opens in a new tab) covers Jira 8.14 and later: you create one from your profile, name it, optionally set an expiry, and copy it once. It is sent as Authorization: Bearer <token>. Four things follow from how they work:

• A token has your permission level. There are no scopes, so there is no read-only token; whatever you can change in Jira, the token can change.
• Read-only therefore has to come from somewhere else: the MCP server’s own setting, such as READ_ONLY_MODE, or an account whose Jira permissions are narrow to begin with.
• Expiry is optional for the person creating it, but admins can cap it; the default maximum is 365 days, and admins can also limit how many tokens each person holds.
• Revoking a token stops it without touching your password or your other integrations, which is the main reason to give every tool its own.

Check the token before you wire it into an assistant. One call to the REST API tells you who it authenticates as:

curl -H "Authorization: Bearer $JIRA_PAT" https://jira.your-company.com/rest/api/2/myself

If you want the assistant’s changes to be distinguishable from yours in Jira’s history, the only way on a self-hosted instance is a separate Jira account for it, with its own token and only the project permissions it needs. That account may count against your user licence, so agree it with your Jira admin first.

Network: where the server should run

• On your own machine, over stdio. The server reaches Jira the same way your browser does, through the office network or VPN, and nothing new is exposed. This suits desktop and terminal assistants such as Claude Code, Cursor and VS Code, which can start local servers.
• As a shared service inside the network. One place to patch and configure, but it is now a service that accepts connections and handles tokens. Put it behind TLS and your own access control, keep it off the public internet, and prefer the mode where each person sends their own token over one shared credential.
• Reachable from the internet. Assistants that run in a vendor’s cloud connect to remote MCP servers from that cloud, so the server would need a public address with a path into Jira. For most teams that self-host Jira precisely to keep it private, that defeats the point. Use a desktop or terminal client instead.
• Internal certificates. If Jira uses a certificate from your own authority, add that authority to the operating system’s trust store. Switching off SSL verification, which some servers allow, should be a last resort for a test instance only.

There is one more boundary to check with whoever owns your data rules. Whatever the server returns, issue text, comments, attachments, is sent to the assistant’s model provider. Many organisations self-host Jira for data-residency or compliance reasons, and those reasons apply to what leaves the network through an assistant too.

What you give up compared with the cloud server

• No consent screen. The cloud server shows what an app is asking for before you approve; a pasted token asks nothing.
• No central admin switch. Atlassian’s cloud admins can decide which clients may connect and filter the audit log for MCP actions. On Data Center, control is the token list, your network and the server’s configuration.
• No curated tool groups. Which tools exist, and which are off by default, is whatever the community project decided. Read its tool list before you allow writes.
• Untrusted text is still untrusted. An issue description can contain instructions aimed at an assistant. The risks are the same as for any connection; see MCP security risks.

If the board is what you are after

fenbs is a hosted board, so it is not a way to keep Jira data on your own servers. Where it can help is the part of the work that does not need to live in Jira: a smaller board where each assistant signs in with OAuth, holds your role narrowed by the scopes you tick, and has every change recorded with its name. Scripts that cannot sign in use a token issued under Settings with a name, scopes and an optional expiry, and revoking it there ends it. See fenbs vs Jira and the MCP docs.