repo-pulse

repo-pulse-mcp

Turn git history into answers your AI assistant can act on: what is risky in this branch, who should review it, which files keep breaking and what changed since the last release.

repo-pulse is a read-only [Model Context Protocol](https://modelcontextprotocol.io) server for local git repositories. It runs over stdio, needs nothing but Node.js and git, never modifies a repository and never touches the network. Ask your assistant things like:

• 🔍 _"I'm about to open a PR. What's risky, what did I forget, and who should review it?"_
• 🐛 _"Which files keep breaking? Where is the churn?"_
• 👥 _"Who knows the billing module best? Are we depending on a single person?"_
• 🔗 _"Which files always change together with this one?"_
• 🚀 _"What changed since the last release? Draft the release notes."_
• 🧹 _"Which branches are stale, and which are already merged?"_

It works with any local git repository, whether it was cloned from GitHub, GitLab, Bitbucket or anywhere else, or has no remote at all. Platform data such as pull requests, issues or CI status is out of scope.

_A real Claude Code session reviewing a branch of vitejs/vite with no shell, only repo-pulse. See how it was recorded._

Quick start

Requires Node.js 22.12+ and git. There is nothing to clone or build: the server runs from npm.

# Claude Code: run inside the repository you want to ask about

claude mcp add repo-pulse -- npx -y repo-pulse-mcp --repo "$PWD"

Then ask _"What changed since the last release?"_, or review your branch with the built-in prompt: /mcp__repo-pulse__review_branch main. For Claude Desktop and other MCP clients, see Installation.

Features

13 tools, grouped by the question they answer. 🆕 marks the newest ones.

🔍 Code review and risk

👥 Ownership and team

🚀 Releases and branches

🕒 History and activity

📦 Also included

All tools are annotated readOnlyHint: true, declare an outputSchema, and return both structuredContent and a JSON text block for older clients. Full inputs and outputs are in the Tool reference.

Example conversations

You: I'm about to open a PR for feature/search. Anything I should know?

Assistant _(calls review_context with base: "main", head: "feature/search")_: 4 commits

touching 6 files. `src/api.ts` is the risky one: it changed 14 times on main in the last six

months and 6 of those were bug fixes. You may have forgotten `test/api.test.ts`: it changed

together with src/api.ts in 9 of 10 commits but is not in this branch. **Suggested reviewer:

Alice**, who holds most of the recent knowledge of these files.

You: Who knows src/billing/ best? Are we depending on one person?

Assistant _(calls knowledge_map with path: "src/billing")_: The bus factor is 1. Carol

holds 72% of the recent knowledge and is the main owner of 11 of 14 files; 9 of them depend on

her alone. Bob is a distant second at 18%. Pairing Bob with Carol on the next billing change

would spread the knowledge…

You: Which parts of the code has nobody touched in a long time?

Assistant _(calls code_age with minAgeDays: 365)_: Half of the files haven't changed in

18 months. src/legacy/ is the oldest directory (median 3.2 years), and 41 of its files were

last changed by people who no longer commit here. That's where knowledge is being lost…

You: Where is the churn this quarter, and what keeps breaking?

Assistant _(calls file_hotspots with days: 90)_: src/core/insights.ts changed in 23

commits by 3 people, far more than anything else, and 9 of those commits were fixes. That's a

good candidate for splitting up or adding tests…

You: What changed since the last release?

Assistant _(calls release_notes_draft with defaults: latest tag → HEAD)_: Since v0.2.0

there are 14 commits. One breaking change: the config file moved to repo-pulse.json. New

features: an author filter for activity and branch merge detection. Three bug fixes, mostly

around empty repositories. Here's a Markdown draft you can paste into the GitHub release: …

You: Can we clean up some branches?

Assistant _(calls stale_branches with days: 30)_: 6 branches haven't seen a commit in 30+

days. 4 of them are already merged into main and are safe to delete: …

You: _(selects the weekly_engineering_update prompt)_

Assistant _(calls recent_activity, contributor_summary, file_hotspots, stale_branches)_:

Highlights — …

_The conversations are illustrative: names and numbers are made up._

And a real session on vite, asking about unreleased changes and stale branches:

Why repo-pulse?

There are already MCP servers for GitHub, GitLab and git itself, and coding agents with a shell can run git log directly. repo-pulse does not try to replace them. It does a different job: it turns local git history into answers and is safe to auto-approve.

What that means in practice:

• Fewer steps, correct numbers. Questions like "where is the churn?", "what goes into the release notes?" or "which branches are merged and stale?" otherwise take several shell commands and hand-written counting pipelines, which can be silently wrong. repo-pulse does the counting in tested code and returns deterministic JSON that says which filters it applied. Some tools go further than any single git command: review_context combines churn, fix history, change coupling and ownership for a branch in one call.
• Read-only you can verify. Every tool is annotated readOnlyHint and backed by a git subcommand allowlist (see Security model), so a client can run it without asking for approval each time. You would not give the same permission to a shell or to a git server that can commit and push.
• Useful where there is no shell. Chat clients such as Claude Desktop cannot run git. With repo-pulse, an engineering mana