Jira MCP (sooperset’s mcp-atlassian fork) covers the full Atlassian surface — Jira Cloud, Jira Data Center, and Confluence. Issue search via JQL, ticket creation and updates, sprint management, comment threads, plus Confluence page reads. The right pick for teams who run their workflow on Atlassian and want an agent that participates.
What it produces: Jira tools (jql_search, create_issue, update_issue, add_comment, get_sprint_info) and Confluence tools (search_pages, read_page, create_page). JQL passthrough means any query you can write in Jira’s UI also works here.
Best for: engineering teams shipping in Jira at any scale. Particularly leveraged when JQL is the natural query language and you don’t want to translate it to a different tool’s filter UI.
Skip if: your team is on Linear (Linear MCP), GitHub Issues (GitHub MCP Server), or Notion. Don’t dual-host trackers. Skip also if your Jira instance is locked down to corporate VPN — you’ll fight network config more than you’ll ship workflows.
Setup gotchas: auth differs by deployment. Jira Cloud uses email + API token (from Atlassian account settings). Data Center uses personal access tokens with different scopes. Read the README for the exact auth strategy — wrong env vars are the #1 setup error. uvx install needs Python tooling (uv); npm-only setups need a workaround.
Real-world workflow: the standard “which P1 tickets in this sprint are stale?” query. Agent runs JQL: project = X AND priority = P1 AND updated < -3d AND sprint in openSprints(), returns the list with last-comment timestamp. Replaces a 10-minute manual scan, runs daily.
Compatible alternatives: Linear MCP for Linear-first teams, GitHub MCP Server for repo-based issue tracking.
JQL is the killer feature. If your team writes good JQL, this MCP earns its keep immediately.