How to Use the Jira MCP Server in Cursor

To use Jira in Cursor, add the Atlassian Rovo MCP Server, Atlassian’s hosted server at https://mcp.atlassian.com/v2/mcp. The quickest way is the Atlassian plugin on the Cursor Marketplace: select Add to Cursor and sign in. The manual way is an entry in .cursor/mcp.json with that URL. Either way Cursor opens Atlassian’s consent screen in your browser, you approve, and Cursor’s agent can then search Jira with JQL, read work items and create, edit, transition and comment on them, with your own Jira permissions. Cursor asks before each MCP tool call by default; the useful work is deciding which ones may run without asking.

This guide is Cursor-specific. What the server’s Jira tools cover, and which groups are off by default, is in what the Jira MCP server can do; the same setup for the terminal is Jira MCP with Claude Code. The server works with Atlassian Cloud sites only.

Option 1: the Cursor Marketplace plugin

1. Open the Atlassian plugin page on the Cursor Marketplace, or open Customize in Cursor’s sidebar, choose MCPs and search for Atlassian.
2. Select Add to Cursor. Cursor installs the server and starts the OAuth sign-in.
3. Your browser opens on Atlassian. Sign in, check the site and the access requested on the consent screen, and approve.
4. Back in Cursor, the server shows as connected in Customize, with its tools listed.

This is the route Atlassian’s own getting-started guide↗ (opens in a new tab) gives for Cursor, and the one to take unless you want the configuration in a file your team can see.

Option 2: an entry in mcp.json

Cursor reads MCP servers↗ (opens in a new tab) from two files: .cursor/mcp.json in a project, and ~/.cursor/mcp.json in your home folder for every project. Give each server one name and keep it in one of the two files, so it is always clear which entry is in use. A remote server needs only a URL:

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

The key, here atlassian, is the server’s name inside Cursor, and it reappears in approval rules below, so choose it once. Save the file, open Customize, find the server under MCPs, switch it on and follow the sign-in prompt. A project file suits a team that shares one Atlassian site: commit it, and each person still signs in as themselves. Older guides use /v1/sse or an mcp-remote bridge; Atlassian’s current instructions use the /v2/mcp address directly.

When the sign-in is blocked

Atlassian admins decide which client apps may use OAuth against their organisation, by domain. Atlassian’s list of supported domains↗ (opens in a new tab) includes an entry for Cursor, written as the custom protocol cursor://cursor.mcp. If your organisation’s settings do not allow the client, the consent step fails with a message that your organisation admin must authorise access from this redirect URL.

• The fix is on the Atlassian side. An organisation admin opens Atlassian Administration, then Rovo, then Rovo MCP server, and adds the domain under Domain settings.
• Cursor’s own documentation says its desktop app uses http://localhost:8787/callback as its OAuth redirect. If your admin allows local tools by pattern, Atlassian’s knowledge base suggests a localhost pattern with a wildcard port.
• If the domain looks right and the error persists, Atlassian’s advice↗ (opens in a new tab) is to remove and re-add the same entry, then retry in a private browser window.
• For anything else, open the Output panel in Cursor and choose MCP Logs. Connection and authentication errors show there.

Check it works

In Agent chat, start with reads: “Which Atlassian sites can you see, and who am I signed in as?” The server answers from two tools that are always available, atlassianUserInfo and getAccessibleAtlassianResources. Then: “List the open bugs assigned to me in project PAY, and show me the JQL you used.” If an answer is empty, check the site first; a token is issued for particular sites, and a question about another one finds nothing.

Do not be surprised by a short tool list. The server lists a few primary tools up front, and the agent finds the rest through a discover tool and runs them through executeRead, executeWrite or executeDestructive, according to how risky the operation is.

Tool approval: what to let run

Cursor asks for approval before using an MCP tool by default, and you can expand each request to see its arguments. MCP tools follow the same Run Modes↗ (opens in a new tab) as terminal commands, set under Settings, Agents, Approvals & Execution:

• Auto-review: allowlisted calls run at once, and other calls go to a classifier that can let them through, ask the agent to try another way, or ask you. Cursor says plainly that the classifier is not a security boundary.
• Allowlist: only calls on your allowlist run without asking.
• Run Everything: every call runs without asking. Not a sensible setting for a connection that can change Jira.

To pin the allowlist in a file, use permissions.json, per user in ~/.cursor/permissions.json or per project in .cursor/permissions.json. MCP entries take the form server:tool, using the server name from mcp.json, and * works as a wildcard:

{
  "mcpAllowlist": [
    "atlassian:atlassianUserInfo",
    "atlassian:getAccessibleAtlassianResources",
    "atlassian:discover",
    "atlassian:getJiraIssue",
    "atlassian:searchJiraIssuesUsingJql"
  ]
}

That lets the agent look things up freely and keeps every write on ask. Two cautions. First, a list defined in permissions.json replaces the one in Cursor’s settings for that type, and the in-app editor becomes read-only, so keep everything in the file. Second, think before adding the execute tools. Allowing atlassian:executeRead lets any deferred read run without asking; never allow executeWrite or executeDestructive, and never use atlassian:*, because each would let changes through unchecked.

Machines without a browser

For automation, Atlassian supports token authentication instead of OAuth, but only if an organisation admin has enabled it. A personal API token goes in a Basic header as your email and token, base64-encoded; a service account key goes in a Bearer header. Cursor can read the value from an environment variable, which keeps it out of the file:

{
  "mcpServers": {
    "atlassian": {
      "url": "https://mcp.atlassian.com/v2/mcp",
      "headers": {
        "Authorization": "Basic ${env:ATLASSIAN_MCP_BASIC}"
      }
    }
  }
}

Set the variable in your shell profile and restart Cursor so it sees it. Atlassian lists the trade-offs↗ (opens in a new tab): some tools, such as code search and Teams, need OAuth; a token is not tied to one site, so the agent has to pass the site ID where a tool needs it; and token connections are governed by IP allowlists rather than domain settings. Never commit a token in a project mcp.json.

For teams and admins

• On the Cursor side, Enterprise admins can keep an MCP allowlist in the dashboard, approving remote servers by URL pattern and limiting which of a server’s tools may run automatically. Team admins can offer shared servers through a team marketplace.
• On the Atlassian side, the assistant works with each person’s own Jira rights, admins control which tool groups are switched on, and Atlassian’s guidance is to use least privilege, review high-impact changes before confirming them, and watch the audit log.
• Some calls, such as Rovo search and Teamwork Graph, use Rovo credits from the organisation’s shared pool, which your admin may be watching.

If the board is what you are after

Jira through MCP gives Cursor’s agent all of your Jira rights across every site you approve. If your team would rather give the agent a seat on one simpler board, fenbs connects to Cursor the same way, with one URL in mcp.json and a browser sign-in; the agent holds your role narrowed by the scopes you tick, and every change is signed with its name. See connecting Cursor to fenbs and fenbs vs Jira.