standup-mcp

Generate your daily standup from what you actually did, across GitHub, Jira, Linear, and Slack.

Every standup, you stop and reconstruct yesterday from memory: which commits, which PR, which ticket you moved, that Slack thread where you said you were stuck. The work is already recorded across your tools. Re-typing it is the chore everyone hates, so updates come out vague ("worked on the thing") and real blockers go unsaid.

standup-mcp reads that activity back and writes the draft for you. You ask your AI assistant "what should I say at standup today?" and it answers from your real GitHub, Jira, Linear, and Slack activity: grouped by work item, in concrete deltas, with blockers it noticed on its own.

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 activity leaves your machine except the calls to those tools' own APIs, and it needs no AI API key of its own. The host client supplies the model.

See it in 30 seconds (no accounts needed)

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

npx -y standup-mcp --demo

That prints a full standup from a synthetic day across all four tools. Here is the headline tool:

# Standup: Jordan Lee
_since Tue Jun 16. Demo data, no credentials configured._

## Yesterday
- **PROJ-412 Biometric re-auth** · opened PR #128, 3 commits, latest "handle expired challenge edge case", moved to In Progress, posted an update
- **ENG-88 Rate-limit the export endpoint** · 2 commits, latest "tests for limiter window", moved to In Progress, posted an update
- **PROJ-407 Card dispute webhook** · merged PR #125, moved to In Review
- Reviewed PR #129: Tidy currency formatting helpers

## Today
- Continue **PROJ-412 Biometric re-auth**
- Continue **ENG-88 Rate-limit the export endpoint**
- Land PR #128: Add biometric re-auth (review pending)
- Review PR #130: Refactor request logging

## Blockers
- 🔴 **PROJ-412 Biometric re-auth** · flagged blocked: "Blocked on the vendor sandbox creds for PROJ-412. Waiting on infra to provision them before I can test the re-auth flow…"; awaiting review

Notice the GitHub commits, the GitHub PR, and the Jira move all collapsed under PROJ-412, and the blocker was lifted from a Slack message on its own. Nobody typed any of that.

(Running npx -y standup-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

Five tools. Every one defaults to the last working day, and Monday automatically reaches back across the weekend, so you rarely pass arguments.

Tool	What you get
standup_draft	Your standup: Yesterday / Today / Blockers, grouped by work item, in concrete deltas. The answer to "what should I say at standup?"
blocker_scan	Everything blocking you, ranked by severity, fused from explicit "blocked / waiting on" language, PRs awaiting review, stalled in-progress tickets, and help requests.
weekly_summary	A week of activity rolled into Shipped vs In progress, with reviews and totals. For 1:1s, weekly status, and self-reviews.
activity_digest	A chronological "what actually happened" across all tools, newest first, grouped by day.
list_sources	Which sources are wired, or that you are on demo data.

What you can ask

You talk to it in plain language through your AI client:

• "What should I say at standup today?"
• "Give me Monday's standup covering the weekend."
• "What is blocking me right now?"
• "Summarize what I shipped this week for my 1:1."
• "What did I actually do yesterday?"

Principles it follows

• Only observed activity. It reports commits, PRs, ticket moves, and messages that exist. It never invents progress to fill a quiet day; a quiet day is reported as one.
• Grouped by work item, not by tool. Reviewers think in tickets, so the commit, the PR, the Jira move, and the Slack thread for PROJ-412 become one line, not four.
• Blockers from signals, not self-report. People forget to say they are stuck, so it infers it.
• A draft, not an auto-post. You get editable markdown to paste wherever your team already does standup (Slack, Geekbot, a doc, a ticket). It does not post on your behalf.

<details> <summary><b>Example: blocker_scan</b></summary>

# Blockers
_since Tue Jun 16. Demo data._

**1 blocker**: 1 high, 0 medium, 0 low.

- 🔴 **PROJ-412 Biometric re-auth** (slack) · flagged blocked: "Blocked on the vendor sandbox creds for PROJ-412. Waiting on infra to provision them before I can test the re-auth flow…"; awaiting review

</details>

<details> <summary><b>Example: weekly_summary</b></summary>

# Weekly summary: Jordan Lee
_the last 7 days. Demo data._

## Shipped
- **PROJ-407 Card dispute webhook**

## In progress
- **PROJ-412 Biometric re-auth**
- **ENG-88 Rate-limit the export endpoint**

## Reviews and support
- Reviewed 1 PR for teammates

_3 work items touched, 1 PR merged, 5 commits._

</details>

Privacy

This is the part most tools gloss over. standup-mcp is built so that using it does not feel like installing surveillance on yourself:

• Local. It runs on your machine, inside your AI client. There is no standup-mcp server or account.
• Read-only. Every token it asks for is used only to read your activity. It never writes, posts, or moves anything.
• No AI key, no third party. It makes no LLM calls of its own. Your activity is sent only to the APIs of the tools you connect, and to your existing AI client's model. It is not sent to me or anyone else.
• It is yours, not your manager's. It generates your own update for you to review and edit, not a feed of your activity for someone else.

Connect your tools

Set any subset. Whatever you configure, it uses; with nothing set, it stays in demo mode. Restart the server after changing these.

Variable	Source	Notes
GITHUB_TOKEN	GitHub	Read-only PAT. Reads your commits, PRs, and reviews.
JIRA_BASE_URL JIRA_EMAIL JIRA_API_TOKEN	Jira	Cloud site, account email, and an API token. Reads your ticket moves.
LINEAR_API_KEY	Linear	A personal API key. Reads your issue state changes and comments.
SLACK_TOKEN	Slack	A user token (xoxp) with search:read scans your own messages for blocker language. With a bot token instead, also set SLACK_CHANNELS (comma-separated channel ids) since bots cannot search.
STANDUP_NAME	optional	Display name for the standup's owner. Without it, the GitHub handle is used.

Verify your connections before wiring it into a client:

GITHUB_TOKEN=ghp_xxx LINEAR_API_KEY=lin_xxx npx -y standup-mcp --check

It prints, per source, the authenticated identity or a clear error.

Connect your AI client

standup-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, and more. The server uses no AI API key of its own.

Claude Desktop

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

{
  "mcpServers": {
    "standup": {
      "command": "npx",
      "args": ["-y", "standup-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token",
        "JIRA_BASE_URL": "https://your-company.atlassian.net",
        "JIRA_EMAIL": "you@company.com",
        "JIRA_API_TOKEN": "your-jira-token",
        "LINEAR_API_KEY": "lin_api_your_key",
        "SLACK_TOKEN": "xoxp-your-token"
      }
    }
  }
}

Leave the env block out entirely to run in demo mode first. Include only the sources you use.

Claude Code

claude mcp add standup \
  -e GITHUB_TOKEN=ghp_your_token \
  -e LINEAR_API_KEY=lin_api_your_key \
  -- npx -y standup-mcp

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

These read the same mcpServers JSON as Claude Desktop, in the client's own MCP config. Use the block above. The server is identical; only the model driving the client differs.

How it works

The design goal is a clean seam between each tool and the standup logic.

• One activity model. GitHub commits, Jira moves, Linear state changes, and Slack messages all normalize to a single ActivityEvent. Nothing downstream knows which tool a fact came from, which is exactly what lets it group by work item across tools.
• One provider, many sources. Each source is an independent read-only client behind a common interface. The aggregator fans out to whichever are configured and tolerates any one failing, so a misconfigured Slack token never sinks your standup.
• Pure-function engine. Grouping, blocker detection, and the draft are pure functions over normalized events. They run identically on demo data and live data, and the tests run them directly.
• No model in the server. The server assembles a factual draft; your AI client phrases it. That is why it needs no AI key and why it can promise it never invents work.

src/
  index.ts            MCP server, stdio transport, --demo/--check/--help
  config.ts           per-source env resolution, demo-mode detection
  window.ts           the weekend-aware "since last standup" window
  provider.ts         aggregator that fans out to configured sources
  types.ts            ActivityEvent and the source/provider interfaces
  normalize.ts        work-item key extraction, signal and noise detection
  sources/            github, jira, linear, slack clients, plus the demo provider
  analytics/          grouping, blockers, draft, weekly, digest (pure functions)
  tools/              one MCP tool per file, thin wrappers over analytics

What has been verified

• All five tools run end to end over real MCP stdio (npm test).
• The parse heuristics (work-item keys, blocker language, noise filters) are unit tested (test/normalize.test.ts).
• The engine is unit tested, including the Monday-covers-the-weekend window, work-item grouping, blocker severity, and the assembled draft (test/draft.test.ts).
• The whole engine is exercised against the demo dataset and reconciles across tools (npm run smoke).

The demo dataset proves the engine. It does not prove each live client against every real account shape, which is why the parse layer is unit tested separately and each source is kept small and tolerant. Run --check to confirm your own connections, and if a response shape does not parse cleanly on your account, open an issue.

Roadmap

• A team_standup view that rolls up several people for the PM running the meeting
• Calendar sources (meetings as activity, so a meeting-heavy day reads honestly)
• GitLab and Bitbucket
• Cycle-time and "what changed since I last looked" digests
• OAuth flows in addition to tokens

Built by Sathvic Kollu

I run delivery for SaaS and fintech teams, and I build tools like this with Claude Code. If this saves you the daily standup chore, 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.