retro-mcp

A sprint retrospective grounded in what actually happened, not what people remember.

Retros run on memory, so they run on bias. The loudest voice and the last few days win, the same complaints come back every sprint, and the action items quietly never happen. Meanwhile the actual record of the sprint, the reopened ticket, the PR that sat two days in review, the Slack thread where someone said they were blocked, is sitting right there in your tools, unused.

retro-mcp reads that record and hands you a retro built from it. You ask your AI assistant for the retro and it answers with what went well, what didn't, and action items, every line backed by a specific metric, ticket, PR, or thread. It frames everything around the process, never individuals, and it flags the problems that keep recurring across sprints.

It is a standard Model Context Protocol server, so it works in any MCP client (Claude, Cursor, Cline, and more) on any model. It is local and read-only: nothing about your sprint leaves your machine except the calls to your own tools' APIs, and it needs no AI API key. That is also the answer to the obvious worry: it is a retro aid, not a surveillance tool.

See it in 30 seconds (no accounts needed)

It ships with a realistic closed sprint and runs against it automatically when no credentials are set:

npx -y retro-mcp --demo

Here is the headline tool on that demo sprint:

# Sprint Retrospective: MBANK Sprint 23
_May 27 to Jun 10. Demo data, no credentials configured._
_Grounded in 8 issues, 5 merged PRs, and 4 flagged threads. System-level and blameless: this is about the process, not people._

## What went well
- **Work moved through faster than last sprint.** avg cycle time 4.6d, down from 5.6d.

## What did not go well
- **The sprint fell short of its commitment.** only 23 of 34 pts done (68%).  ⟳ recurring across recent sprints
- **Scope grew mid-sprint.** +5 pts across 2 issues pulled in after the sprint started.  ⟳ recurring across recent sprints
- **Work carried over into the next sprint.** 3 issues (16 pts) not finished.  ⟳ recurring across recent sprints
- **Some work was called done before it was.** MBANK-203 · reopened 1 time: Statement PDF export.
- **Code review was a bottleneck.** PRs waited 20.3h on average for a first review; PR #503 · sat 52h: statement PDF export.
- **Changes had to be reverted or hotfixed.** PR #504 · revert: OTP delivery change; 1 hotfix merged.
- **The team hit repeated blockers and interruptions.** 2 threads mentioned being blocked; 1 thread mentioned an incident.

## Action items
- [ ] (recurring) Adopt a scope-change rule: anything pulled in mid-sprint bumps something out, decided at standup, not silently.
- [ ] (recurring) Pull less or split large items so they finish inside the sprint.
- [ ] Tighten the definition of done: an explicit QA check before anything moves to Done.
- [ ] Add a pre-merge guard on risky changes: a second approval or a smoke test before merge.

## Discussion prompts
- MBANK-203 was reopened once. What made it hard to call done the first time?
- +5 pts came in after the sprint started. What drove the mid-sprint adds?
- PR #504 had to be reverted. What would have surfaced the problem before it merged?

Every line points at something real. Nobody typed it from memory, and the three recurring problems are flagged as patterns, not fresh complaints.

What it does

Six tools. Everything defaults to the most recently closed sprint.

... View full README on GitHub