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.
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。