Jira/Confluence Team Lead MCP
Provides sprint and developer analytics from Jira, answering questions about sprint content, developer performance, and refinement readiness. Can publish reports to Confluence for easy sharing.
README
Jira / Confluence Team Lead
An MCP server and an Angular dashboard that answer the questions a team lead actually has, and can publish the answer to Confluence:
- What's in this sprint, and is it going to land?
- How did each developer do over the last few sprints? (real changelog-derived cycle/lead time, not a guess from current status)
- What's not ready for the next refinement session, and who should be in the room?
- Who has gone quiet? — active work with no comment for over a day.
Built and tested against a personal Atlassian Cloud site first; the target
corporate instance is a .env change, not a code change.
Layout
src/jira_confluence_mcp/ the report engine (metrics, rendering, Atlassian client)
server.py MCP server — stdio, for Claude
api.py HTTP API — for the dashboard
frontend/ Angular dashboard
scripts/demo_server.py run the dashboard on synthetic data, no Jira needed
The MCP tools and the dashboard call the same report builders, so a number shown in the UI and a number quoted in chat can't drift apart.
See it working without Jira
Two terminals, no credentials required:
.venv\Scripts\python.exe scripts\demo_server.py
cd frontend && npm start
Then open http://localhost:4200. The data is invented, but it flows through the real changelog parsing and metric code.
Setup
python -m venv .venv
.venv\Scripts\python.exe -m pip install -e ".[dev]"
Copy .env.example to .env and fill in the base URL, your Atlassian email,
and an API token from https://id.atlassian.com/manage-profile/security/api-tokens.
Then register the server (.mcp.json in this repo already does it for Claude
Code — adjust the absolute paths if you move the project):
claude mcp add jira-confluence -- "C:\DEV\Jira Confluence MCP\.venv\Scripts\python.exe" -m jira_confluence_mcp.server
First call should always be check_connection — it verifies both products,
prints the resolved defaults, and tells you which custom field it picked for
story points.
The dashboard
.venv\Scripts\python.exe -m jira_confluence_mcp.api
cd frontend && npm start
The dev server proxies /api to the backend on port 8000, so there's no CORS
to configure. Four screens:
- Overview — completion against time elapsed, points, at-risk count, a changelog-derived burndown, load per person, and a filterable issue table.
- Developers — the multi-sprint table, one row per developer per sprint. Sort any column, filter by developer or sprint, export to CSV. This is the thing Confluence's static tables can't do.
- Refinement — what's not ready, why, and a copyable attendee list.
- Quiet work — active issues with no recent comment, per person.
Every screen has a Publish to Confluence button that writes the same report as the MCP tool would. The browser sends the report kind, never markup — the server regenerates the storage format itself, so the API can't be used to inject arbitrary content into a Confluence page.
Reports are cached for 120 s so the dashboard doesn't hammer Jira; each page's Refresh button bypasses the cache.
Node version: the CLI is pinned to Angular 21 because Angular 22 needs Node ≥ 22.22.3 and this machine has 22.17.0. Upgrade Node first if you want to move to 22.
Tools
| Tool | What it does |
|---|---|
check_connection |
Auth check + resolved config. Run this first on a new instance. |
list_sprints |
Sprints on a board, so you can find sprint ids. Falls back to listing boards if none is configured. |
get_sprint_issues |
Issues in a sprint, filterable by status name or status category. Key, summary, assignee, story points, status. |
get_developer_sprint_history |
2–5 sprint rollup per developer: completed, carried over, avg time in progress, cycle time, lead time. |
get_refinement_readiness_report |
Stories missing an estimate or DOR/DOD labels, plus a suggested attendee list. |
get_sprint_health |
One-call sprint overview: totals, breakdowns, burndown. Powers the Overview screen. |
get_stale_issues |
Active work with no comment for over N days — who's gone quiet. |
publish_confluence_page |
Create or overwrite a page from storage-format XHTML. |
check_confluence_capabilities |
Cloud vs Data Center, and whether the Table Filter app is available. |
Every report tool returns rows (structured), markdown (for reading), and —
with include_confluence_storage=true — confluence (storage format). Pass
publish=true to write it straight to a page; re-running overwrites the same
page by title.
Metric definitions
These are the decisions baked into metrics.py. Worth agreeing with the team
before the numbers get used in a retro.
- Completed — the issue was in a Done-category status at sprint close
(
completeDate, elseendDate, else now for an active sprint). Judged at sprint close, so an issue finished the week after the sprint ended counts as carried over for that sprint. Never evaluated past now, so an active sprint is measured against today rather than its future end date. - Carried over — everything in the sprint that was not completed.
- Re-opened work — an issue that was Done and moved back out is not completed. Closed → re-opened → closed again reports the final close.
- Time in progress — calendar hours in In Progress-category statuses, summed across visits, capped at completion or sprint close.
- Cycle time — first entry into an In Progress-category status → completion.
- Lead time — issue created → completion.
- Grouping — by the issue's current assignee. Reassigned work is credited to whoever holds it now; the changelog has the data to split it by holder if that turns out to matter.
Status categories (new / indeterminate / done) are read from the
instance rather than hard-coded status names, so a workflow that calls it
"Development" instead of "In Progress" still works. Any status the instance
does not report is surfaced in the report's warnings.
Confluence tables
Storage-format tables are static — not sortable or filterable. Options, in the order worth trying on a target instance:
table_style="table-filter"— wraps the table in the Table Filter, Charts & Spreadsheet macro. Runcheck_confluence_capabilitiesfirst; reading the app inventory needs admin rights, so anullresult means "ask an admin", not "not installed".- Confluence Cloud's database content type — behaves like an embedded spreadsheet, but cannot be created through the REST content API this server uses. Manual setup only for now.
table_style="plain"(default) — static table. Re-run the report grouped or sorted differently when another view is needed. Good enough for MVP.
Switching to another instance
Only .env changes:
JIRA_BASE_URL/CONFLUENCE_BASE_URL— set both explicitly if Jira and Confluence are on different hosts (usual for Data Center).ATLASSIAN_DEPLOYMENT— leaveautounless the URL doesn't give it away. Data Center means/rest/api/2and offset-paged search; the client handles the switch, including falling back from the Cloud-only/search/jql.JIRA_STORY_POINTS_FIELD— auto-discovery looks for "Story Points" / "Story point estimate"; pin the custom field id if the instance renamed it.REFINEMENT_DOR_LABELS/REFINEMENT_DOD_LABELS— the team's actual labels.ATLASSIAN_CA_BUNDLE— corporate root CA, for an internal TLS chain. Prefer this over turningATLASSIAN_VERIFY_SSLoff.
Tests
.venv\Scripts\python.exe -m pytest -q
cd frontend && npm test
80 Python tests and 20 Angular tests, no Atlassian instance required — HTTP is
mocked with respx, and the metric logic is tested as pure functions over
changelog fixtures.
Not built yet
get_story_comment_summary— a full per-developer comment timeline within a story.get_stale_issuescovers the "who has gone quiet" half of it; decide whether the rest is worth having after a few sprints of real use.- Push alerting (Slack/Teams) for quiet stories. The detection exists; only the delivery channel is missing.
- Postgres sync. Today the dashboard reads Jira live behind a 120 s cache, which
is fine at team scale. The
rowspayloads are already shaped for a table-per-report load if history or cross-team rollups are wanted later. - Auth on the API. It binds to localhost and assumes whoever reaches it is you. Anything beyond your own machine needs real authentication in front of it.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.
E2B
Using MCP to run code via e2b.