Jira MCP Server: Connect Claude Code, Cursor, and VS Code in 2 Minutes (2026)

You can connect a Jira MCP server to your AI coding agent in about two minutes: point Claude Code, Cursor, or VS Code at Atlassian's official remote 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 /v2/mcp endpoint Atlassian now recommends. 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.

Updated September 10, 2026 for Atlassian's /v2/mcp endpoint, native HTTP setup in Claude Code, per-plan rate limits and Rovo credit rules, and the community server's current 98-tool count.

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, Jira Service Management, Bitbucket Cloud, Compass, and Loom (GitHub, 2026). If your team lives in Atlassian Cloud, this is your answer.

The community sooperset/mcp-atlassian server has close to 5,900 GitHub stars and ships 98 tools across Jira and Confluence (GitHub, 2026). It is self-hosted through uvx or Docker and, unlike the official server, works on Cloud as well as Jira Server or Data Center v8.14+ and Confluence v6.0+. Its own README calls it "not an official Atlassian product."

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: an Atlassian Cloud site, a client that speaks Streamable HTTP, and an account that can complete the OAuth consent flow. You no longer need Node or the mcp-remote bridge for Claude Code. The first thing to know, though, is an endpoint change you cannot skip.

Atlassian now recommends https://mcp.atlassian.com/v2/mcp for every client. The older v1 endpoints (/v1/mcp/authv2 and /v1/mcp) remain supported, and existing v1 connections switch to the v2 tool set automatically on March 1, 2027 (Atlassian, 2026). The legacy /v1/sse transport was deprecated as of June 30, 2026 (Atlassian Community, 2026). It kept answering for a while afterward with a deprecation banner prepended to every tool call (GitHub, 2026), which is its own small token tax. Every snippet below uses /v2/mcp. If you copied config from an older guide, this is the line to change.

VS Code#

Add the server to .vscode/mcp.json, or search @mcp Atlassian in the Extensions view and install it (VS Code, 2026):

json{"servers":{"atlassian":{"type":"http","url":"https://mcp.atlassian.com/v2/mcp"}}}

Cursor#

For a Cursor setup, add this to ~/.cursor/mcp.json for every project or .cursor/mcp.json for one (Cursor, 2026):

json{"mcpServers":{"atlassian":{"url":"https://mcp.atlassian.com/v2/mcp"}}}

Claude Code and other local clients#

Claude Code speaks Streamable HTTP natively, so one command registers the server (Claude Code docs, 2026):

bashclaude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Then run /mcp inside a session to finish sign-in. Codex uses the same shape: codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp.

The first connection triggers a browser-based OAuth 2.1 consent screen (Atlassian, 2026). For headless use in CI or bots, Atlassian also supports API token auth, but only when an organization admin has enabled it. 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.

Connecting is free for every Atlassian Cloud customer, and rate limits scale with your plan: 500 calls per hour on Free, 1,000 on Standard, and 1,000 plus 20 per user, up to 10,000, on Premium and Enterprise (Atlassian, 2026). Standard Jira and Confluence reads and writes through the server consume no Rovo credits; the enriched Teamwork Graph search tools such as searchAtlassian and getTeamworkGraphContext draw 1 to 10 credits per call (Atlassian, 2026). Atlassian also notes the server does not currently meet FedRAMP or HIPAA requirements. For a single developer working a ticket, the hourly ceiling is rarely the bottleneck. Heavy multi-agent workflows are where you are more likely to hit it.

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 with uvx or 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 an official Atlassian product."

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. The community measurements collected in Unblocked's GitHub MCP autopsy put GitHub's full toolset at about 55,000 tokens across 93 tool definitions, roughly 27% of a 200,000-token window, against about 4,200 tokens for the 26-tool default set (dev.to, 2026). Individual tool definitions run anywhere from about 100 to over 1,000 tokens each (MCP spec issue #2808, 2026), so a 98-tool Jira and Confluence server lands in the same range. The budget you lose also degrades what remains: the NoLiMa benchmark found 11 of the models it tested fell below 50% of their short-context accuracy at 32K tokens (arXiv, 2025), and Anthropic's own guidance names "bloated tool sets" as one of the most common agent failure modes (Anthropic, 2025).

The fix is to wire up fewer, leaner servers and prune tools you never call, so your context window funds the work. 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. This is where Unblocked changes the arithmetic: one MCP connection covers Jira, Confluence, Slack, GitHub, Notion and more, replacing a stack of per-source servers with a single compact schema, and the context it returns is scored and compressed server-side, so the agent reads a ranked slice in place of raw ticket JSON. Charles Thompson, an engineering manager at Cloudbeds, measured it at about a third of the tokens of his previous setup for the same answer.

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 and leaves out 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. Missing are the pull request that closed the ticket, the Slack thread where the requirement quietly changed, and the Confluence page the ticket now contradicts. An access protocol reads the row and stops there.

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 a one-line config change. 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. Unblocked closes the gap by traversing the chain in one pass: ticket to linked PR to Slack thread to the code that changed, then handing the agent the synthesized history with source links so a human can check every claim. Permissions set in Jira carry through to the person and their agent, so the blast radius stays where your admins put it. That is what a context engine built for AI agents adds on top of access.

Raw Jira connectors vs a context engine: how do they compare?#

A raw Jira connector fetches a ticket reliably and has no way to tell your agent whether that ticket is still true. The table below scores the connectors against Unblocked on the dimensions that decide whether the agent acts on a stale row or on the current decision behind it.

When the ticket says one thing and a later Slack decision or a merged PR says another, a raw connector cannot tell your agent which is current. It returns the ticket and moves on. Unblocked resolves the contradiction automatically, weighting the newer source, the more authoritative one, and the one closest to the code in question, then serves one decision-grade answer with links back to the ticket, the thread, and the PR it drew on. The same pass covers the token side: the agent reads a scored, compressed slice in place of raw ticket JSON on every turn. For teams weighing the two approaches, that is the recommendation: keep a Jira connector for write actions if you want one, and route every context question through Unblocked.

The effect shows up before the agent ever runs, because the people writing the tickets get the same history.

Unblocked makes my Jira tickets not suck. Ticket quality has gone up and the cost has gone down at the same time, which is something you almost never see.

Chris Hovanessian — Group Product Manager, Cloudbeds

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 or admin-enabled API tokens, and covers Jira, Confluence, Jira Service Management, Bitbucket Cloud, Compass, and Loom. For Server or Data Center, you need the community sooperset/mcp-atlassian server instead.

How do I set up the Atlassian MCP server in Cursor?#

Add the official endpoint to ~/.cursor/mcp.json: {"mcpServers":{"atlassian":{"url":"https://mcp.atlassian.com/v2/mcp"}}}. The first connection opens a browser OAuth 2.1 consent screen. Once approved, your agent works under your own Jira permissions. Use /v2/mcp for new setups; the v1 endpoints still work, and /v1/sse has been deprecated since June 30, 2026.

How do I connect Jira to Claude Code over MCP?#

Run claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp, then type /mcp in a session and approve the browser OAuth 2.1 prompt. Claude Code connects to the official remote server directly, with no mcp-remote bridge or Node install required, and the agent then searches, reads, and updates issues under your own Atlassian permissions.

What does a Jira connector 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). Community measurements put GitHub's full MCP toolset at about 55,000 tokens across 93 tools before the first prompt; a 98-tool Jira and Confluence server is the same shape. Unblocked's single connection replaces that stack and compresses what it returns, which is why one Cloudbeds engineer got the same answer for about a third of the tokens.

Is a Jira connector enough, or do you need a context engine?#

A Jira connector covers reading and updating tickets under your own permissions. The trouble starts when the reasoning behind a ticket lives elsewhere, because the connector returns the ticket fields without the Slack threads or pull requests that explain them. Unblocked, which gives coding agents institutional context, follows the ticket to its linked PR, the Slack thread, and the code in one pass and hands the agent the decision behind the ticket along with its text and source links.

What's the best Jira MCP server for Claude Code?#

For pulling raw Jira tickets into Claude Code, Atlassian's official Rovo MCP server is the most direct choice, and self-hosted teams reach for a community server like sooperset/mcp-atlassian. The better answer depends on what you actually need: a connector gives Claude Code the ticket, while Unblocked gives it the ticket reconciled against your code, Confluence, and Slack, with contradictions settled by recency, authority, and proximity. If your agent keeps acting on stale or conflicting ticket context, the missing synthesis is the bottleneck, and Unblocked is the fix we recommend.

Do I still need a Jira connector if I already have a context engine?#

Usually not for context questions. Unblocked already reads your Jira alongside code, Confluence, Slack, GitHub, and Notion through one MCP connection and reconciles them, so your agent gets the requirement weighed against everything else rather than a raw ticket. You may still want a direct Jira connector for write actions, such as transitioning an issue or posting a comment, since those are operations on a single tool rather than questions that span several.

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. Weighing more than these two options? Our comparison of the best Confluence and Jira MCP servers ranks four of them side by side. Then prune your tool list so you aren't spending tens of thousands of schema tokens 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. That is the job Unblocked does. Your agents already know the code; Unblocked gives them the rest, Jira, Confluence, Slack, GitHub, and Notion through a single MCP connection, with the ticket's linked PR and Slack thread traversed in one pass, contradictions resolved before the agent reads, and permissions carried through from Jira. Wire up the connector for writes if you like, then connect Unblocked for the context. That's the difference between an agent that fetches and an agent that gets it.