jira-pm-mcp

A Jira MCP server built for project managers, not developers.

Most Jira integrations expose the raw API: read an issue, search JQL, move a ticket. That is built for developers. As a PM I do not want raw issues. I want the read I would do myself every morning: is this sprint going to land, what is actually blocked, who is stuck, and what do I tell stakeholders on Friday.

jira-pm-mcp is that interpretation layer. You ask your AI assistant "how is the sprint doing?" and it answers like a delivery lead, not like a database.

It is a standard Model Context Protocol server, so it works with any MCP client (Claude, Cursor, Cline, Continue, and more) no matter which model is behind it, and it needs no AI API key of its own. The only credential it uses is a Jira API token.

You: How is the current sprint tracking?

Your AI assistant (via jira-pm-mcp):
Sprint Health: MBANK Sprint 24
Verdict: At risk. 32% of points done with 36% of the time used,
projected to land around 88% of committed work.
2 blocked items, 1 stale, 1 unassigned. Scope grew +8 points mid-sprint.

See it in 30 seconds (no Jira account needed)

The server ships with a realistic demo dataset and runs against it automatically when no credentials are set, so you see real output before connecting anything.

From source, render every tool's output to your terminal:

git clone https://github.com/sathvic-kollu/jira-pm-mcp
cd jira-pm-mcp
npm install
npm run smoke

Or run the published package directly, no clone needed:

npx -y jira-pm-mcp --demo

(Running npx -y jira-pm-mcp with no flag starts the MCP server on stdio, which is what an MCP client launches. Use --demo to see output in a plain terminal.)

What it does

Seven PM tools and two discovery helpers. Every one of them defaults to the active sprint, so you rarely pass arguments.

| Tool | What you get | | --- | --- | | sprint_health_summary | Completion vs time elapsed, a plain verdict (on track / at risk / behind), scope added mid-sprint, and the specific items dragging the sprint down. | | burndown_analysis | Remaining work per day vs the ideal line, burn rate vs the rate needed to finish, and a projected completion date. Reconstructed from the changelog. | | velocity_trends | Committed vs completed across recent sprints, average velocity, commitment accuracy, predictability, and a recommended commitment for next sprint. | | standup_generator | A daily standup grouped by person: done, in progress, blocked. Pasteable into Slack. | | blocker_report | Everything in the way, ranked by severity. Flags, blocked-by links, hard statuses, stale tickets, and natural-language cues in comments. | | weekly_status_note | A stakeholder-ready note with a single RAG status, what shipped, the top risks, velocity context, and next week's focus. | | jira_list_boards / jira_list_sprints | Discovery helpers for ids when you need them. |

What you can ask

You talk to it in plain language through your AI client. It maps your request to the right tool and reads the answer back to you. For example:

• "How is the current sprint tracking? Are we going to make it?"
• "What is blocked right now, and who owns each blocker?"
• "Write today's standup." or "Give me Monday's standup covering the weekend."
• "Show me the burndown and tell me if we are behind."
• "What is our velocity, and how much should we commit next sprint?"
• "Draft this week's status note for stakeholders."
• "Did scope change mid-sprint?"
• "Which tickets have gone stale or have no owner?"
• "List the boards." or "List the open sprints on board 3."

You do not need to know JQL, custom field ids, or which tool to call. Ask the question a PM would ask. Everything defaults to the active sprint, so most questions need no extra detail.

## Blockers: MBANK Sprint 24

**3 blockers**: 2 high, 1 medium, 0 low.

### 🔴 High
**MBANK-107** Integrate vendor fraud-scoring API · Arjun Rao
- flagged as impediment
- status is "Blocked"
- blocked by MBANK-201 (In Progress)
- comment mentions a blocker
  > Blocked on vendor API credentials. Waiting on the infra team to provision the sandbox before I can test.

**MBANK-111** Push notification for dispute resolution · Daniel Kim
- flagged as impediment
- comment mentions a blocker
  > Stuck. Dependency on MBANK-205 (notification service upgrade) is not merged yet.

### 🟡 Medium
**MBANK-105** Transaction history pagination · Daniel Kim
- no update in 4 days

The blocker report does not just list the "Blocked" column. It fuses the impediment flag, open "is blocked by" links, hard blocked statuses, staleness, and language cues in comments ("waiting on", "stuck", "dependency") into one ranked view. The comment scanning is why the server flattens Atlassian Document Format.

## Burndown: MBANK Sprint 24
_Reconstructed from the changelog. Treat as a close approximation._

**🟡 Behind the ideal burn**

Remaining points: ████▇▇
             Jun 11 Jun 16

Committed at start: 48 points
Completed so far: 18 points
Remaining: 39 points

Day 5 of 14. Burning 3.6 points/day, need 4.3 points/day to finish on time.
Projected completion: Jun 27 (about 2 days past the end date).

Notice "committed at start" is 48, not the current 57. The replay knows one ticket was re-estimated mid-sprint and another was pulled in three days late. That late add is the small bump in the sparkline.

# Weekly Status: MBANK Sprint 24

**Overall: 🟡 Amber: needs attention**

The sprint is 32% complete by points with 9 days left (36% of the time used).
At the current rate it lands around 88% of committed work. 2 high-severity
blockers and 1 medium need attention.

## Progress
- Completed this week: 18 points across 4 issues
- In progress: 24 points
- Scope added mid-sprint: +8 points

## Risks and blockers
- MBANK-107 Integrate vendor fraud-scoring API (Arjun Rao): flagged as impediment
- MBANK-111 Push notification for dispute resolution (Daniel Kim): flagged as impediment

## Velocity context
Team averages 46.8 points/sprint (high predictability, trend steady).

## Focus next week
- Clear 2 high-severity blockers (MBANK-107, MBANK-111).
- Drive the 24 points in progress to done.
- Assign 1 unowned item.

Connect it to your Jira

The server reads Jira Cloud over the REST and Agile APIs with an API token. Set three environment variables and it switches from demo data to your real site:

| Variable | Required | Notes | | --- | --- | --- | | JIRA_BASE_URL | yes | e.g. https://your-company.atlassian.net | | JIRA_EMAIL | yes | the Atlassian account the token belongs to | | JIRA_API_TOKEN | yes | create one at id.atlassian.com | | JIRA_STORY_POINTS_FIELD | no | e.g. customfield_10016. Auto-detected if omitted. | | JIRA_DEMO_MODE | no | set to true to force the demo dataset |

If your team does not estimate in story points, every tool falls back to issue counts automatically. The story-points field is auto-detected from your site's field list, so you usually do not need to set it.

Verify the connection in one command before wiring it into a client:

JIRA_BASE_URL=https://your-company.atlassian.net \
[email protected] \
JIRA_API_TOKEN=your-token \
npx -y jira-pm-mcp --check

It prints the boards it can see, the detected story-points field, and the target sprint, or a clear error if something is misconfigured.

Connect your AI client

jira-pm-mcp speaks the Model Context Protocol, so any MCP-capable client can use it, whichever model is behind it: Claude Desktop, Claude Code, Cursor, Cline, Continue, Zed, Windsurf, LibreChat, and MCP-based agent frameworks. The server uses no AI API key of its own. The setup is the same everywhere: run the npx jira-pm-mcp command and pass your Jira details as environment variables.

Claude Desktop

Add this to claude_desktop_config.json (Settings, Developer, Edit Config), then restart Claude Desktop:

{
  "mcpServers": {
    "jira-pm": {
      "command": "npx",
      "args": ["-y", "jira-pm-mcp"],
      "env": {
        "JIRA_BASE_URL": "https://your-company.atlassian.net",
        "JIRA_EMAIL": "[email protected]",
        "JIRA_API_TOKEN": "your-token"
      }
    }
  }
}

Leave the env block out entirely to run in demo mode first.

Claude Code

claude mcp add jira-pm \
  -e JIRA_BASE_URL=https://your-company.atlassian.net \
  -e [email protected] \
  -e JIRA_API_TOKEN=your-token \
  -- npx -y jira-pm-mcp

Cursor, Cline, Continue, Zed, Windsurf, and others

These read the same mcpServers JSON as Claude Desktop, in the client's own MCP config file (often mcp.json or the client settings UI). Use the exact block shown for Claude Desktop. The server is identical; only the model driving the client differs.

Running from source (for development)

{
  "mcpServers": {
    "jira-pm": {
      "command": "node",
      "args": ["/absolute/path/to/jira-pm-mcp/dist/index.js"]
    }
  }
}

How it works

The design goal is a clean seam between Jira and interpretation.

• One data provider interface. The live Jira client and the demo provider implement the same interface, so no analytics code knows where the data came from. That is what makes zero-credential demo mode possible and what makes the logic testable.
• A thin, tolerant parse layer. Everything risky about real Jira responses (custom field ids, ADF comment bodies, paginated changelogs, link direction) lives in one file. The rest of the system speaks normalized types.
• Pure-function analytics. Sprint health, burndown, velocity, blockers, standup, and the weekly note are pure functions over normalized issues. The smoke test runs them directly.
• Changelog replay for burndown. Remaining work per day is reconstructed by replaying status, estimate, and sprint-membership history per issue. This is a documented approximation, not a copy of Jira's own chart, and the tool says so.

src/
  index.ts            MCP server, stdio transport
  config.ts           env resolution, demo-mode detection
  provider.ts         provider factory, sprint and board resolution
  types.ts            normalized domain types and the data provider interface
  normalize.ts        raw Jira to normalized, plus the ADF flattener
  jira/client.ts      live Jira Cloud client
  jira/mock.ts        demo dataset
  analytics/          sprintHealth, burndown, velocity, blockers, standup, scope, weeklyStatus
  tools/              one MCP tool per file, thin wrappers over analytics

What has been verified

• All eight tools run end to end over real MCP stdio (npm test).
• The parse layer is unit tested against a documented Jira Cloud payload, including ADF, custom fields, and link direction (test/normalize.test.ts).
• The sprint-health verdict logic, including the early-sprint projection gate that keeps the tool from crying "at risk" on day two, is unit tested (test/health.test.ts).
• The analytics are exercised against the demo dataset (npm run smoke), and the numbers reconcile across tools (the burndown remaining, the health remaining, and the to-do plus in-progress totals agree).

The demo dataset proves the math. It does not prove the parse layer against every real Jira configuration, which is why that layer is unit tested separately and kept deliberately small. If you hit a field or response shape that does not parse cleanly on your site, open an issue.

Roadmap

• Jira Server and Data Center base paths and auth
• OAuth in addition to API tokens
• Streamable HTTP transport for hosted deployments
• Cumulative flow and cycle-time tools
• A "sprint retro prep" tool that summarizes what changed and why

Built by Sathvic Kollu

I run delivery for SaaS and fintech teams, and I build tools like this one with Claude Code. If this is useful to you, I would like to hear how you use it.

• Website: sathvickollu.com
• LinkedIn: linkedin.com/in/sathvic-kollu

Issues and pull requests are welcome.

License

MIT. See LICENSE.