Jira MCP: How to Connect Jira to Your AI Coding Agent (2026)

You can connect Jira to your AI coding agent in about two minutes: point Claude Code, Cursor, or VS Code at Atlassian's official remote MCP server, approve the OAuth prompt, and your agent can search, read, and update Jira issues. The harder question is what it costs you in context tokens, and why access to the ticket still isn't understanding why the ticket exists.

This guide covers the part the rest of the search results skip. You get the real config for each client, current as of the June 2026 endpoint cutover. You get the official-versus-self-hosted decision spelled out. And you get the two things every other walkthrough leaves on the table: the per-turn token tax, and the gap between reading a ticket and understanding it. Let's start with what the server actually is.

What is a Jira MCP server, and what can your agent do with it?#

The Model Context Protocol now has more than 10,000 active public servers and over 97 million monthly SDK downloads (Anthropic, 2025). MCP is the open standard that lets an AI client call external tools (modelcontextprotocol.io, 2026). A Jira MCP server exposes Jira operations as those tools: search, read, comment, transition.

In practice, that means your agent can search issues with JQL, read a ticket's full body, post a comment, transition a status, or update fields, all through tool calls instead of you copy-pasting. The agent acts under your own permissions, so it can't touch anything you can't.

Why does this matter more than a plain API integration? Because the agent decides when to call which tool, in the middle of a task, without you scripting it. You ask it to start on a ticket, and it fetches the ticket, checks linked issues, and updates status as it works. The protocol is what makes that fluid instead of brittle.

Two servers matter for Jira. Atlassian ships an official remote one, and the community maintains a self-hosted one. Which you pick depends on whether you run Cloud or on-prem, so that's the next decision. If you want the bigger picture of how MCP fits into a larger context system, the server is only the access layer.

Which server should you use, official or community?#

There are two real options here, and the choice is close to binary. The official Atlassian Rovo MCP Server went GA on February 4, 2026 (Atlassian, 2026). It is remote, hosted by Atlassian, Cloud-only, and uses OAuth 2.1. The community alternative is self-hosted and covers on-prem.

The official server respects each user's permissions and reaches across Jira, Confluence, Compass, and Bitbucket Cloud. If your team lives in Atlassian Cloud, this is your answer.

The community sooperset/mcp-atlassian server runs roughly 5,400 GitHub stars and ships 72 tools across Jira and Confluence (GitHub, 2026). It is self-hosted in Docker and, unlike the official server, works on both Cloud and Jira Server or Data Center v8.14+. It is explicitly "not official."

The one-line rule: Cloud teams use the official server, Server or Data Center teams use the community one. There isn't much gray area here. The official server simply won't connect to an on-prem instance, and the community server gives you broader hosting control at the cost of running it yourself. The full comparison table is below.

How do you connect the server to Claude Code, Cursor, and VS Code?#

Setup with the official server takes about two minutes once your prerequisites are in place: Node 18+, npx, an Atlassian Cloud site, and a supported IDE. The first thing to know, though, is an endpoint change you cannot skip.

After June 30, 2026, the legacy https://mcp.atlassian.com/v1/sse endpoint is no longer supported (Atlassian, 2026). Every snippet below uses the current /v1/mcp/authv2 endpoint instead. If you copied config from an older guide, this is the line to change.

VS Code#

Add the server to your MCP config:

json{"servers":{"atlassian-mcp-server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2","type":"http"}}}

Cursor#

For a Cursor setup, add this to your Cursor MCP config:

json{"Atlassian-MCP-Server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2"}}

Claude Code and other local clients#

For a Claude Code connection, run the remote bridge locally:

bashnpx -y mcp-remote@latest https://mcp.atlassian.com/v1/mcp/authv2

The first connection triggers a browser-based OAuth 2.1 consent screen (Atlassian, 2026). After you approve, the agent acts under your own Jira and Confluence permissions. That permission inheritance is the part to flag for your security team: the agent can't read a project the human user can't, which keeps the blast radius tied to existing access controls rather than a separate service account.

Rate limits scale by plan, from 500 requests per hour on Free up to 10,000 per hour on Enterprise (Atlassian, 2026). For a single developer working a ticket, even the Free tier is rarely the bottleneck. Heavy multi-agent workflows are where the higher tiers start to matter.

Source: Atlassian remote MCP server page, 2026.

How do you self-host the connector for Server or Data Center?#

If you run Jira on-prem, the official server cannot help you, because it is Cloud-only (Atlassian, 2026). The community sooperset/mcp-atlassian server is the supported-by-the-community route, covering Cloud and Server or Data Center v8.14+.

The workflow: run the server in Docker, then authenticate. On Cloud you use an API token. On Server or Data Center you use a personal access token (PAT). OAuth is also supported. Once it's running, point your client at the local server URL the same way you'd point it at any MCP server.

The tradeoff is ownership. You host it, you patch it, and you get on-prem coverage plus Jira and Confluence in one server. What you give up is Atlassian support, since this is community-maintained and, in the project's own words, "not official."

If your team is regulated and can't send issue data to a hosted endpoint, that ownership is worth the work. You keep the traffic inside your own network and control exactly which tools the server exposes. The flip side is real operational work: container updates, credential rotation, and monitoring all land on your team. Weigh that against the two-minute official setup before you commit.

How do the official and community servers compare?#

For most Cloud teams, the official server is the obvious pick, but on-prem teams have exactly one good option. The table below lines up the two on the dimensions that actually decide the call, including the token cost both of them quietly impose.

The read-out is simple. Pick official for Cloud, community for on-prem. The row that surprises people is the last one: both servers make your agent pay for their full tool-definition schema on every single turn. That's the cost nobody on the search results page talks about, and it's worth deciding when a server actually earns its keep before you wire up five of them. Let's get into it.

Why does the integration cost more tokens than you think?#

Anthropic's engineering team reported that agents with thousands of tools can process "hundreds of thousands of tokens before reading a request," with one code-execution workload dropping from 150,000 to 2,000 tokens, a 98.7% reduction (Anthropic, 2025). Your agent pays for the tool definitions on every turn, before it even reads your request.

That tax is invisible because it never shows up as an error. It shows up as a smaller working budget. When Unblocked measured the official GitHub MCP server, its tool definitions came to roughly 42,000 tokens before the first prompt, about 21% of a 200,000-token window. A 72-tool Jira server is the same shape of cost.

The fix isn't to avoid the integration. It's to wire up fewer, leaner servers and prune tools you never call, so your context window funds the work instead of the schema. If you have GitHub, Jira, Slack, and three more servers all loaded at once, the schemas stack, and the math gets ugly fast. Most teams only call a handful of tools per task anyway, so the rest is pure overhead.

Think of it as a budget. Every token spent describing a tool you'll never invoke is a token your agent can't spend reading the actual ticket or reasoning about the fix. For a full accounting of the per-turn tax across a stack of servers, the math compounds fast.

Does the connector give your agent the context, or just the ticket?#

The server gives an agent the ticket fields but not the surrounding discussion: the Slack threads, pull-request debates, and decisions that explain why a ticket exists. It hands your agent the ticket: title, description, status, assignee, comments. What it does not hand over is the Slack thread where the requirement quietly changed, the pull request where two engineers argued the approach, or the decision that made the ticket necessary in the first place. An access protocol reads the row. It cannot reconstruct the why.

That gap is exactly what teams hit once the novelty wears off. The agent can fetch the ticket flawlessly and still propose the wrong thing, because reading a ticket is not the same as understanding it, and the reasoning behind the ticket never lived in Jira.

Picture a ticket that says "fix the export timeout." Clear enough. But the real story is that the timeout was a deliberate guardrail added after an incident, debated across a 40-message Slack thread, and the actual ask is to raise a config value, not rewrite the export. The server delivers the one-line ticket. It has no way to surface the thread that explains why the naive fix is wrong.

"The first instruction in every agent project file is: before making any changes, gather context. That pulls from Jira, Confluence, and Slack via Unblocked, because that's where most of our knowledge actually lives, in threaded discussions. I set it up the day it was announced and now I don't even think about it. I just get the relevant information."

— Andrei Antanovich, Software Engineer, Waste Logics

This is why an access protocol is not the whole story: a context layer that sits underneath MCP matters because it unifies PRs, Slack, Jira, Notion, and Confluence so the agent starts with the synthesized history behind the database row. That unifying layer for AI agents is what turns access into understanding.

Frequently asked questions about the Jira MCP server#

Is there an official Jira MCP server?#

Yes. The Atlassian Rovo MCP Server went GA on February 4, 2026 (Atlassian, 2026). It is Cloud-only, uses OAuth 2.1, and covers Jira, Confluence, Compass, and Bitbucket Cloud. For Server or Data Center, you need the community sooperset/mcp-atlassian server instead.

How do I set up Jira MCP in Cursor?#

Add the official endpoint to your Cursor MCP config: {"Atlassian-MCP-Server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2"}}. The first connection opens a browser OAuth 2.1 consent screen. Once approved, your agent works under your own Jira permissions. Use the authv2 endpoint, since /v1/sse stops working after June 30, 2026.

How do I connect Jira MCP to Claude Code?#

Run npx -y mcp-remote@latest https://mcp.atlassian.com/v1/mcp/authv2 and approve the browser OAuth 2.1 prompt that appears. That bridges Claude Code to the official remote server, and the agent then searches, reads, and updates issues under your own Atlassian permissions. You'll need Node 18+ installed first.

What does Jira MCP cost in tokens?#

Tool definitions are paid on every turn, before your request is read. Anthropic measured agents loading "hundreds of thousands of tokens before reading a request" (Anthropic, 2025). Unblocked's analysis put GitHub's MCP server at roughly 42,000 tokens before the first prompt; a 72-tool Jira server is the same shape.

What to Wire Up First#

If you're on Atlassian Cloud, wire up the official remote server today. The setup is about two minutes, and the payoff is real: your agent can search, read, and update issues under your own permissions. If you're on Server or Data Center, self-host sooperset/mcp-atlassian instead. Then prune your tool list so you aren't spending 42,000 tokens of schema on tools you never call.

But know the ceiling before you celebrate. The server gets your agent access to the ticket. The reasoning behind that ticket, the threads and pull requests where the work was actually decided, lives somewhere else entirely. A context layer that unifies those sources is what turns access into understanding, and that's the difference between an agent that fetches and an agent that gets it.