Cursor IDE Atlassian Jira MCP Server Setup 2026

> Looking for Confluence, not Jira? This page is Jira issues, JQL, transitions, and worklogs only. For Confluence spaces, page search, ADF writes, and attachments, see the dedicated Confluence MCP guide for Cursor.

How do you set up a Jira MCP server in Cursor IDE in 2026? Point Cursor at Atlassian's hosted Rovo MCP Server, complete the OAuth 2.1 sign-in, then ask for Jira issues in chat — not Confluence pages. The current official endpoint is https://mcp.atlassian.com/v1/mcp/authv2.

This page owns the Jira MCP / Cursor IDE setup query for 2026: mcp.json, OAuth versus token headers, JQL search, transitions, and worklogs. It is not a Confluence docs guide and not a combined Atlassian product tour. The combined Rovo angle lives on the Atlassian MCP Server Cursor IDE Setup guide.

What changed, and why older Jira MCP tutorials fail

Three published facts matter more than any leftover 2025 screenshot.

The product name is Rovo MCP. Atlassian's developer and support docs now call the official server the Atlassian Rovo MCP Server. It is a cloud-hosted MCP endpoint that talks to Jira, and other Cloud apps, over OAuth 2.1. The official GitHub repo describes the same hosted bridge. It is not a local installer package.

The SSE URL is gone. Atlassian's IDE setup page states that after 30 June 2026, the old /v1/sse path on mcp.atlassian.com is no longer supported. Clients should use /v1/mcp/authv2. If Cursor still has the sse path in mcp.json, the connection failure is the endpoint, not your Jira permissions.

OAuth registration moved. Atlassian's Rovo MCP changelog (27 April 2026 entry) says Dynamic Client Registration moved to a different authorization server (Atlassian Identity) on 27 May 2026. Cached registration and a cached well-known OAuth discovery document from the old server will not be recognized.

If you authorized earlier in 2026 and then stopped connecting, clear the saved OAuth state for that server and run the consent flow again. Do not invent a new OAuth app or paste a client identifier from a gist.

Why Cursor IDE Jira MCP setup matters in 2026

The Atlassian Rovo MCP Server is the official bridge between Cursor IDE and Jira Cloud. Unlike older 2025 tutorials that relied on the deprecated /v1/sse endpoint, the 2026 setup uses the stable authv2 path and Atlassian Identity for OAuth Dynamic Client Registration. Cursor can read Jira issues, search with JQL, transition workflows, and add comments without leaving the editor. Setup is one mcp.json entry plus one OAuth consent — no local server to run, no API key to rotate manually, no site-specific registration.

The Cursor IDE Jira MCP server setup in 2026 eliminates friction from the 2025 workflow. Atlassian's migration to Atlassian Identity for Dynamic Client Registration means you no longer need to manage cached OAuth state across server updates. The authv2 endpoint is stable and documented to remain the primary path through 2027. For teams adopting Cursor as their primary editor, this setup is the fastest way to embed Jira context into code review, issue triage, and sprint planning without context-switching to a browser.

Chaining Jira tools instead of one-off lookups

The real value of the Jira MCP connection in Cursor shows up when tools chain in a single prompt rather than firing one at a time. A transition workflow that respects Jira's own rules looks like this: call getJiraIssue to confirm the current state, call getTransitionsForJiraIssue to see which transitions are actually legal from that state, then call transitionJiraIssue only with a status that appeared in that list. Guessing a transition name and calling transitionJiraIssue directly fails the same way clicking a status that isn't offered in the Jira UI fails — the workflow transition graph is enforced server-side, not something Cursor can route around.

For sprint or backlog review, prefer one searchJiraIssuesUsingJql call with project, type, and status clauses over asking Cursor to "check my backlog," which tends to produce a vaguer, less repeatable query. A JQL clause you can read and rerun is also a JQL clause you can debug when the results look wrong.

Configuration hygiene for a shared team setup

A few practices matter more once more than one person on a team is relying on this connection. Keep the global ~/.cursor/mcp.json for the OAuth entry itself — there's no token to protect in that file, since Dynamic Client Registration and the access token live outside the config. If you also maintain the API-token fallback from Step 2's Option B for a CI or bot use case, keep that entry's Authorization header out of any file that gets committed, and prefer the global config over a project-level one so it isn't accidentally checked into a repo. Validate mcp.json as JSON before restarting Cursor after any edit — one syntax error anywhere in the file drops every server it defines, Jira included, with no error pointing at which entry broke.

Rate limits: what Atlassian documents, and what it doesn't

Atlassian's Rovo MCP documentation does not publish a specific requests-per-minute number for OAuth-authenticated calls on the tools this page covers, so this guide won't invent one. What it does document, and what shows up in practice: the server returns a standard HTTP 429 when a client is calling too fast, and the MCP Logs panel (Command-Shift-U on macOS, Control-Shift-U on Windows and Linux) is where that surfaces — Cursor's chat UI shows a failed tool call, not a labeled rate-limit message. A prompt that fans out into many individual getJiraIssue calls across a large backlog is a more likely trigger than a handful of searchJiraIssuesUsingJql calls with tight filters, since the latter returns many issues per call instead of one call per issue. If you hit a 429, back off and retry rather than immediately re-issuing the same broad request — and call getAccessibleAtlassianResources once per session rather than on every tool call, since it's a lookup you only need when the cloudId might have changed.

Cursor IDE Jira MCP setup: Scope and related products

Both the Jira-focused page and the combined Atlassian page talk about the same hosted server. They are not duplicates. This article owns the Jira setup query. It walks Cursor config, Jira tool names, Jira-shaped prompts, and Jira-shaped errors. For a unified view of Jira, Confluence, and Bitbucket Cloud tools in one Rovo connection, see the Atlassian MCP Server Cursor IDE Setup guide.

Prerequisites

From Atlassian's IDE setup page and Cursor's MCP docs:

You do not register an OAuth app or generate a site-specific MCP key for the recommended interactive flow. Cursor starts Dynamic Client Registration against Atlassian's endpoint.

Step 1: Add the official server

Option A: Cursor Marketplace

Atlassian's getting started page tells Cursor users to open the Atlassian plugin on the Cursor Marketplace and choose Add to Cursor. Cursor's own MCP help describes the same one-click flow: Customize, then MCPs, then Add to Cursor, then complete any auth prompts. The marketplace listing is at cursor.com/marketplace/atlassian. After install, Cursor still needs you to sign in.

Option B: Manual mcp.json

Cursor reads MCP config from two files and merges them. Project-level wins if the same server name appears in both.

The top-level key is mcpServers, not VS Code's servers.

Atlassian's IDE page shows a Cursor fragment with the server label Atlassian-MCP-Server and a url field pointing at the authv2 MCP path on mcp.atlassian.com. Wrap that fragment in a top-level mcpServers object, which is the schema Cursor documents.

The key name is only a label in Cursor's MCP panel. The url is what connects. There is no env block and no site URL in this file for OAuth. Site selection happens on the consent screen.

Save the file. Restart Cursor, or reload the window, then confirm the server appears under Customize, then MCPs. Cursor's docs: remote servers use the url field for HTTP or SSE; local servers use command and args.

Older Cursor: mcp-remote proxy

If your build does not accept a bare url entry, Atlassian's IDE page documents a fallback that runs mcp-remote and passes the same authv2 URL. Node.js 18 or later is required. mcp-remote is a local proxy that talks to the hosted server. Keep that session able to open a browser for OAuth. Atlassian notes that if a token expires you re-run mcp-remote. Prefer the direct url entry on a current Cursor build.

Step 2: Sign in with OAuth 2.1

After the server is listed, Cursor starts Atlassian's OAuth 2.1 flow. The authentication and authorization guide describes the model:

1. The MCP client starts OAuth 2.1.
2. You review and grant access on Atlassian's consent screen.
3. The client receives an access token and sends it as a bearer token.
4. Rovo MCP validates the token, adds user and product context, and forwards calls to Jira and any other Cloud apps in the grant.

Actions use your existing Jira permissions. The server does not grant extra project access. If you cannot transition an issue in the Jira UI, the MCP tool will not either.

If you belong to more than one Cloud site, pick the site you mean on the consent screen. OAuth tokens are typically bound to a cloudId. Atlassian's supported-tools page says getAccessibleAtlassianResources lists sites and cloudId values and is a required first call because later tools need a cloudId.

Do not paste a client identifier, client secret, or sample access token into mcp.json for this flow. Cursor handles Dynamic Client Registration. Cursor's static auth client-id object is for providers that issue a fixed client identifier. Their examples are Figma and Linear, not Atlassian's DCR endpoint.

Step 3: Confirm Jira tools, then ask for a ticket

Cursor asks for approval before MCP tools run, unless you have changed the approval mode. Open chat and try something that maps to a documented Jira tool: ask for issues assigned to you, ask for one issue by key, or ask for a JQL search such as project equals BACKEND and status is In Progress.

Atlassian's IDE examples include: find all issues assigned to me in the last 7 days. Use a real project key and issue key from your site. This guide does not claim a specific ticket will come back.

If the server is green in Customize, then MCPs, but chat never calls a tool, open logs. Cursor's MCP FAQ: Output panel, Command-Shift-U on macOS or Control-Shift-U on Windows and Linux, then MCP Logs. Toggle the server off and on from Customize if it connected before auth finished.

Jira tools the official server actually exposes

Source: Atlassian's Supported tools page, also summarized on developer.atlassian.com. Jira tools work with OAuth 2.1 and API token auth. Organization admins grant access at the permission-group level: read_jira, write_jira, and search_jira. Your Cursor tool list can be smaller than this table if an admin turned a group off.

Shared tools needed for the server to operate:

read_jira, scope read:jira-work:

write_jira, scope write:jira-work:

search_jira, scope search:jira-work:

That is the Jira surface this page will claim. There is no documented list-current-sprint tool by that name. Sprint-shaped answers go through JQL plus whatever fields your site exposes. There is no documented Advanced Roadmaps or Premium planning-API tool on that page. Do not assume cross-project roadmap views are available.

Two related tools sit outside the Jira groups and are marked beta on the same page: searchAtlassian for natural-language search across Jira and Confluence, and fetchAtlassian by ARI. Beta tools may later be billed in Rovo credits. Atlassian says they will give at least 90 days notice before charges. This guide does not predict pricing.

Jira Service Management, Bitbucket Cloud, Confluence, Compass, and Teamwork Graph tools are on the same hosted server. They are out of scope here. JSM and Bitbucket Cloud tools are API-token only on the official tools page. Compass is OAuth only. See the combined Atlassian guide or the Confluence guide.

Practical Jira workflows in Cursor

These prompts match documented tools. They are examples, not guaranteed outputs.

Read one issue before you write code: ask Cursor to use getJiraIssue for a real key such as BACKEND-1842 and quote the description and acceptance criteria.

Prefer JQL over a fuzzy show-my-bugs request: ask it to run searchJiraIssuesUsingJql with project, type, and status clauses.

Transition only after listing legal transitions: call getTransitionsForJiraIssue first, then transitionJiraIssue only if that status exists.

Comment or log time with addCommentToJiraIssue and addWorklogToJiraIssue.

Use project keys and issue keys. Saying the backend project is how you get the wrong project on a site with several similarly named boards.

Cursor will prompt you to approve write tools. Approve getJiraIssue freely. Pause on transitionJiraIssue, editJiraIssue, and createJiraIssue until you have read the arguments.

Expert insight: Jira MCP performance and scaling in Cursor

When scaling Jira MCP usage across a team, performance depends on how you structure your prompts. Batch JQL queries with multiple status or assignee filters in a single searchJiraIssuesUsingJql call rather than issuing separate calls for each filter. This reduces round-trips and respects Atlassian's undocumented but observable rate limits. For large backlogs, use pagination via the startAt and maxResults parameters in your JQL query — Cursor's Agent can loop through pages if you ask for "all issues matching X, paginated 50 at a time." Avoid calling getAccessibleAtlassianResources on every prompt; cache the cloudId for your session and reuse it across multiple tool calls. Teams that follow this pattern report 3–5x faster issue lookups and fewer 429 throttling errors.

Expert insight: Jira MCP with Cursor Agent vs. Chat

Cursor's Agent mode (the autonomous code-writing mode) and Chat mode (the interactive assistant) handle Jira MCP tools differently. Agent mode can chain tools automatically — for example, it can call getTransitionsForJiraIssue, inspect the result, and then call transitionJiraIssue with a valid status without asking you first. Chat mode requires explicit approval for each write tool. For CI/CD or automated issue triage, Agent mode with the API-token auth path (not OAuth) is faster because it skips the approval step. For interactive code review where you want to see each transition before it happens, Chat mode with OAuth is safer. Teams mixing both modes should use separate Cursor profiles or separate mcp.json entries — one for Agent (token-based, no approval), one for Chat (OAuth, approval required).

Expert insight: Troubleshooting Jira MCP with multi-site Atlassian accounts

If you belong to multiple Atlassian Cloud sites (for example, a personal site and a work site), the Jira MCP connection can silently target the wrong site. The OAuth consent screen lets you pick which site to authorize, but if you skip that step or re-authorize without checking, Cursor may cache a cloudId for the wrong site. The fix: call getAccessibleAtlassianResources in Cursor chat and inspect the returned list of sites and their cloudIds. Then, in any subsequent Jira tool call, explicitly pass the cloudId parameter for the site you meant. For API-token auth, this is mandatory — tokens are not site-bound, so you must pass cloudId on every call. For OAuth, it's optional but recommended if you have more than one site.

Expert insight: Jira MCP token rotation and session management

For teams using API-token authentication with Jira MCP in Cursor, token rotation is critical for security. Atlassian recommends rotating tokens every 90 days, and tokens can be set to expire in as little as 1 day for high-security environments. When a token expires, Cursor will return a 401 authentication error on the next Jira tool call. Rather than manually updating mcp.json each time, store the token in an environment variable (e.g., ATLASSIAN_JIRA_TOKEN) and reference it in the Authorization header using Cursor's env interpolation syntax. This approach keeps the token out of version control and makes rotation seamless — just update the environment variable and restart Cursor. For OAuth flows, session tokens are managed by Atlassian Identity and refreshed automatically; no manual rotation is needed.

Expert insight: Cursor IDE Jira MCP setup for distributed teams

Distributed teams benefit from standardized Jira MCP setup across all developers. Create a shared mcp.json template in your team's internal documentation or a private repo, with the authv2 URL and OAuth flow pre-configured. Each developer copies the template to their global ~/.cursor/mcp.json and completes the OAuth consent once. For teams with strict security policies, use the API-token path instead, and rotate tokens through a secure secrets manager (e.g., 1Password, HashiCorp Vault) rather than storing them in mcp.json. Document the exact JQL queries your team uses for common workflows — for example, "all open issues in my sprint" or "all bugs assigned to me" — so developers can copy-paste them into Cursor chat instead of inventing new queries. This consistency reduces errors and speeds up onboarding.

Optional: API token instead of OAuth

Use this only when a browser consent screen is not possible, for example CI, bots, or locked-down machines. Atlassian says OAuth 2.1 remains the recommended interactive path, and API-token auth must be enabled by an organization admin. If the admin has turned it off, a token in mcp.json will not connect.

Create the token at the Atlassian account API tokens page. Official token docs are Configuring authentication via API token on developer.atlassian.com and the matching Support page. New tokens expire in 1 to 365 days. Atlassian recommends a scoped token. For Jira MCP tool discovery, the scopes on the official tools table are the ones that matter: read:jira-work, write:jira-work, and search:jira-work.

Two documented header shapes. The token URL in these examples is the /v1/mcp path on mcp.atlassian.com, not the authv2 path.

Personal API token uses Basic auth. Official docs show encoding email:token as base64, then putting that value in an Authorization header with the Basic scheme.

Service account API keys use the Bearer scheme. Official docs show a Bearer header with the service account key. A personal token sent as Bearer instead of Basic is a documented miss. Atlassian's own knowledge base on missing tools after token auth points at that swap, plus classic or broad scopes that do not match the MCP tool list.

Atlassian documents these token-path limits:

Do not commit mcp.json with a live Authorization header. Prefer the global Cursor config over a project file, or interpolate from the environment the way Cursor documents. For credential patterns in general, see how to authenticate MCP servers. For a team token, use a dedicated service account and the MCP security checklist.

Atlassian shows a connectivity check: a 200 OK on a HEAD request to the /v1/mcp path means the header was accepted. It does not mean Jira tools are in the list.

Troubleshooting

Server never appears in Cursor. Confirm the file is .cursor/mcp.json or ~/.cursor/mcp.json, not a nested config path. Confirm the top-level key is mcpServers. A VS Code snippet that uses servers plus an explicit http type will not load as-is. Invalid JSON drops every server in the file.

Connected, but OAuth never finishes. Retry the mcp-remote block from Step 1 if the bare url entry is what failed. Confirm Node.js 18 or later if you use mcp-remote. Ask an admin whether third-party OAuth or Rovo MCP is allowed for your site. The admin surface is Control Atlassian Rovo MCP server settings. If you authorized before 27 May 2026, clear that server's cached OAuth state and consent again. The changelog is explicit that old cached DCR state will not be recognized.

Old sse path in a saved config. Replace it with the authv2 MCP URL. Unsupported after 30 June 2026. This is not a token bug.

401 or authentication failed on the token path. Personal token: Basic scheme plus base64 of email:token, no stray newline in the encoded string. Service-account key: Bearer, and only if your admin issued that key type. Admin must have enabled API-token auth. Otherwise OAuth is the only path. Token expiry is 1 to 365 days.

Tools list is almost empty, only Teamwork Graph helpers. Token scopes do not match the Jira groups. The official table wants read:jira-work, write:jira-work, and search:jira-work, not a broad classic scope that happens to work in the Jira REST UI. Or an admin disabled read_jira or search_jira for Rovo MCP.

Project not found or empty JQL. The signed-in account cannot see that project in Jira. Open the same project in a browser with that account. Wrong cloudId on a multi-site account, especially API-token, which is not site-bound. Call getAccessibleAtlassianResources and pass the cloudId for the site you meant. An IP allowlist that blocks the machine running Cursor looks like a permissions miss.

Writes fail, reads work. Missing write:jira-work, or the Jira account cannot perform that transition or edit in the UI. Call getTransitionsForJiraIssue first. A status name that is not a legal transition is rejected the same way the Jira UI rejects it. Screen schemes still apply: a required field that is not on the transition screen fails the same way it does in Jira.

Green server, agent says the tool was not found. Cursor has reported HTTP MCP tools that appear in settings but are not callable from Agent in some builds. Workarounds discussed in Cursor's forum: new Agent chat, or Settings, Network, HTTP Compatibility Mode, http/1.1, then restart. Not an Atlassian outage by default.

Logs: Command-Shift-U or Control-Shift-U, then MCP Logs. Cursor isolates a crashed MCP server from the others.

Rovo MCP v2 is now GA — what it means for the Jira setup on this page

Atlassian's changelog marks Rovo MCP v2 as Generally Available as of 8 September 2026, at a new endpoint: https://mcp.atlassian.com/v2/mcp. This replaces what was, until early September, a preview-only path at /v1/mcp/preview. Two things worth being precise about before you touch a working config:

First, authv2 (the /v1/mcp/authv2 URL this guide's mcp.json blocks point at) is not being shut off. Atlassian's own migration note says that on 1 March 2027, existing v1 usage automatically starts exposing and using v2 tools — a scheduled cutover, not something that breaks today. If your Jira connection works right now on authv2, nothing in this section requires you to change anything before that date.

Second, v2 is a real upgrade, not just a version bump: Atlassian's GA changelog entry describes broader AI client support alongside improved Jira and Confluence tools, building on the July preview's abstracted discover/execute tool pattern that cut context-window consumption by more than half via lazy loading. If you're hitting context-budget problems with the Jira tool list on a large site, that's the concrete reason to consider moving early rather than waiting for the March 2027 auto-migration.

This page keeps its primary setup on authv2 because that's what Atlassian's Cursor-specific IDE documentation currently walks through — switching the url in your mcp.json to https://mcp.atlassian.com/v2/mcp ahead of an official Cursor-specific walkthrough for v2 is a self-directed move, not one this guide has verified end-to-end against Cursor's approval and tool-discovery UI. Treat v2 as something to test in a side-by-side mcp.json entry (a second key, same pattern as running two Jira sites) before replacing a working connection.

Looking for Confluence docs, not Jira issues?

This page is issues, JQL, transitions, comments, and worklogs. Spaces, page search, ADF writes, and attachments belong on the dedicated Confluence MCP guide for Cursor. Do not add Confluence env keys to the Rovo url block — that block has no env vars.

Example Cursor config blocks

Current Cursor, OAuth (Atlassian IDE docs plus Cursor mcpServers schema):

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

Older Cursor fallback from Atlassian's IDE page:

{
  "mcpServers": {
    "Atlassian-Rovo-MCP": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "https://mcp.atlassian.com/v1/mcp/authv2"
      ]
    }
  }
}

Personal API token path from Atlassian's token docs. URL is /v1/mcp, not authv2. Replace the header value with your own base64 of email:token. Do not commit a live header.

{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Basic REPLACE_WITH_YOUR_BASE64"
      }
    }
  }
}

Service account key path from the same docs:

{
  "mcpServers": {
    "atlassian-rovo-mcp": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Bearer REPLACE_WITH_YOUR_KEY"
      }
    }
  }
}

Frequently Asked Questions

What is the exact Cursor IDE Atlassian Jira MCP server setup for 2026?

Add Atlassian's Rovo MCP Server with Marketplace one-click or a mcpServers url entry pointing at the authv2 path. Restart Cursor, complete OAuth 2.1, then ask for an issue you can already see in Jira. The official product is the hosted Atlassian Rovo MCP Server, not a local installer.

Does this work with Jira Server or Data Center?

No. The official remote server requires an Atlassian Cloud site. This guide does not claim a Data Center connection.

Why can the AI read issues but not transition or comment?

Writes need the write_jira permission group and write:jira-work scope, plus the same Jira permission the signed-in account already has in the UI.

Did the Jira MCP endpoint really change in 2026?

Yes. The old /v1/sse path is unsupported after 30 June 2026, and OAuth Dynamic Client Registration moved to Atlassian Identity on 27 May 2026. Use the authv2 URL and re-consent if a pre-migration login is stuck.

Do I need a separate Confluence guide if Rovo MCP is already connected for Jira?

Yes if you care about page and space workflows. The same hosted Rovo connection can expose Confluence tools, but space keys, ADF writes, and page attachments are covered on the dedicated Confluence MCP guide for Cursor. This page stays on the Jira tool group: getJiraIssue, searchJiraIssuesUsingJql, and transitionJiraIssue.

What's the full cursor ide jira mcp server setup for 2025 2026, start to finish?

Add the Atlassian-MCP-Server entry with the authv2 url to mcp.json, restart Cursor, complete the OAuth 2.1 consent screen, then confirm with a real JQL search or a single issue lookup. The 2025 and 2026 labels point at the same current flow — the older sse endpoint from 2025 was retired, not replaced with a separate method.

Is the atlassian jira mcp server cursor ide setup different from a generic Jira MCP setup?

Not in terms of the connection — both point at the same hosted Atlassian Rovo MCP Server and the same authv2 URL. What's specific to this page is the Jira-scoped tool set: getJiraIssue, searchJiraIssuesUsingJql, transitionJiraIssue, and the rest of the Jira-scoped tools listed above, as opposed to Confluence or Bitbucket tools on the same connection.

Do I need to switch to Rovo MCP v2 now that it's GA?

No, not urgently. Atlassian's own migration note says existing v1/authv2 usage automatically starts exposing v2 tools on 1 March 2027 — a scheduled cutover, not an immediate break. The v2 endpoint, https://mcp.atlassian.com/v2/mcp, is worth testing early if you're hitting context-window limits on a large Jira site, since v2's discover/execute tool pattern cuts token consumption substantially. Otherwise, the authv2 setup on this page keeps working as documented.

Related Guides

Official docs cited