Standup from your activity

io.github.sathvic-kolluPublished by GitHub account sathvic-kolluv0.1.0Updated Nov 3, 2026

Generate your daily standup from real GitHub, Jira, Linear, and Slack activity.

Overview

AI-generated overview

Local, read-only MCP server that drafts your daily standup from real GitHub, Jira, Linear and Slack activity, grouped by work item.

What you can do
  • Draft a standup (Yesterday / Today / Blockers) grouped by work item, defaulting to the last working day and reaching back over the weekend
  • Scan for blockers ranked by severity, fused from blocked/waiting language, PRs awaiting review, stalled tickets and help requests
  • Roll a week of activity into a Shipped vs In progress summary for 1:1s and status updates
  • Read a chronological activity digest across all connected tools, newest first
  • List which sources are wired up, or whether it is running on the built-in demo data
When to use it
Useful if you write a daily standup or weekly status and your work is already recorded in GitHub, Jira, Linear or Slack, and you want a factual draft to edit rather than retyping it from memory. Also handy for spotting blockers you forgot to mention.
Requirements
Runs locally over stdio, typically launched with npx from the npm package, so Node.js is needed. Optional credentials per source: GITHUB_TOKEN, JIRA_BASE_URL plus JIRA_EMAIL and JIRA_API_TOKEN, LINEAR_API_KEY, and SLACK_TOKEN (with SLACK_CHANNELS for bot tokens); STANDUP_NAME is optional. With no credentials it runs on demo data. Network access to those tools' APIs is required.
Before you install
It asks for read-scoped tokens for GitHub, Jira, Linear and Slack, which are secrets stored in your client config; use read-only scopes. Your activity is sent to those tools' APIs and to your AI client's model. It is described as read-only and does not post on your behalf, but the draft is generated from inferred signals, so review it before sharing.

Installation

In SourceWeft

  1. Open Standup from your activity in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

standup-mcp

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

[npm version] [license] [node] [MCP]

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:

bash
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.

ToolWhat you get
standup_draftYour standup: Yesterday / Today / Blockers, grouped by work item, in concrete deltas. The answer to "what should I say at standup?"
blocker_scanEverything blocking you, ranked by severity, fused from explicit "blocked / waiting on" language, PRs awaiting review, stalled in-progress tickets, and help requests.
weekly_summaryA week of activity rolled into Shipped vs In progress, with reviews and totals. For 1:1s, weekly status, and self-reviews.
activity_digestA chronological "what actually happened" across all tools, newest first, grouped by day.
list_sourcesWhich 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.
Example: blocker_scan
# 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
Example: weekly_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._

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.

VariableSourceNotes
GITHUB_TOKENGitHubRead-only PAT. Reads your commits, PRs, and reviews.
JIRA_BASE_URL JIRA_EMAIL JIRA_API_TOKENJiraCloud site, account email, and an API token. Reads your ticket moves.
LINEAR_API_KEYLinearA personal API key. Reads your issue state changes and comments.
SLACK_TOKENSlackA 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_NAMEoptionalDisplay name for the standup's owner. Without it, the GitHub handle is used.

Verify your connections before wiring it into a client:

bash
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:

json
{  "mcpServers": {    "standup": {      "command": "npx",      "args": ["-y", "standup-mcp"],      "env": {        "GITHUB_TOKEN": "ghp_your_token",        "JIRA_BASE_URL": "https://your-company.atlassian.net",        "JIRA_EMAIL": "[email protected]",        "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

bash
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.

Issues and pull requests are welcome.

License

MIT. See LICENSE.

Source: README.md at commit 8e30b8d

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.0LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts