jira-worktrack-mcp

A zero-dependency MCP server that answers the questions people actually ask about work in Jira — what is on my plate, what did I do yesterday, where is the sprint bleeding, which tickets are not ready for development, what has been waiting too long — instead of returning raw issue JSON to sort through.

Jira is the single source of truth; nothing is stored locally except downloaded attachments. Everything is read-only apart from upload_attachments, which is the single tool that changes anything.

The installer offers to write the matching permission rules, so reading a ticket's screenshots does not prompt on every call while the one writing tool still does:

{
  "permissions": {
    "allow": ["mcp__jira-worktrack"],
    "ask": ["mcp__jira-worktrack__upload_attachments"]
  }
}

An ask rule outranks an allow rule, so the two hold together. Decline the question, or set JIRA_NO_PERMS=1, and nothing is written to ~/.claude/settings.json.

Install

curl -fsSL https://raw.githubusercontent.com/YusufKaracSimply/jira-worktrack-mcp/main/bootstrap.sh | bash -s -- acme

The argument is the Jira site, so the command your team shares already carries the company name: acme becomes https://acme.atlassian.net, and a full URL works too. Leave it out and the installer asks for it.

Credentials you already have on this machine — from Claude Code, Cursor or Claude Desktop — are found first and offered for reuse, so you may not be asked for anything else. Otherwise it asks for your Atlassian e-mail and an API token (create one at https://id.atlassian.com/manage-profile/security/api-tokens).

Related MCP server: Jira MCP Server

Tools

You normally do not need to name a tool. Ask the question in your own words — what did I do yesterday, what is in this ticket's attachment, why is CON-123 taking so long — and Claude picks the right one. This is most true of the attachment tools: mention an issue key and say you want to see the file, and it lists, downloads, renders or extracts as needed without being told which step to run.

For developers

For scrum masters

For BAs

Attachments

For everyone

How the numbers are worked out

• Status categories over status names. Workflows differ per project — this site alone has in progress, Code_Review, ready_for_test and Ready To Release. Anything structural keys off Jira's statusCategory (new / indeterminate / done); the name is only used for display and for spotting "waiting" states.

• Time in status is rebuilt from each issue's changelog, requested with expand: changelog on the search itself — one call for a hundred issues rather than a hundred calls.

• Cycle time starts at the first move into a status that is neither backlog nor done. A ticket taken straight from the backlog to closed never started, so it has no cycle time and is reported separately instead of being counted as zero.

• Duplicate scan compares normalised summary words (Jaccard). Pairs that share a parent, and story/test pairs, are skipped — those repeat a summary on purpose.

• Caps are reported, never silent: when a tool stops at its issue limit it says so.

Configuration

Custom field ids differ per site, so Story Points, Sprint and the customer field are looked up by name once per session and cached.

Contributing

MIT licensed, so fork it and change whatever you like — a tool that only fits your own way of working belongs in your own copy.

If the change would help everyone, open a pull request instead. main takes no direct pushes: branch off, push the branch, open the PR. Every file is code-owned, so the review request reaches the maintainer automatically, and the PR merges once it is approved.

Notes

• The API token is stored in ~/.claude.json in plain text, like every other MCP env var.

• Everything is scoped to what your own Jira account can see.

• Downloaded attachments are customer files sitting unencrypted in the cache directory. They are swept once per session: anything older than JIRA_CACHE_DAYS goes, along with the directories left empty. A cache directory you named yourself is never swept.

• This supersedes jira-attachments-mcp. Everything that server did is here: five tools keep their names, download_by_jql became download_attachments_by_jql and jira_whoami became whoami. Running both registers those five twice, so the installer offers to remove the old one, and the first run moves its download cache over.

• Uninstall with claude mcp remove jira-worktrack --scope user.