repo-pulse-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REPO_PULSE_REPOS | Yes | The repository allowlist: absolute paths to the local git repositories to serve, separated by ':' on macOS/Linux or ';' on Windows (e.g. ~/code/my-app:~/code/my-lib). This is equivalent to passing repeated --repo CLI arguments. Only repositories listed here are served, and the server refuses to start if no repository is configured. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| recent_activityA | List commits on HEAD from the last N days, newest first. Optionally filter by author (case-sensitive substring of the author name) and/or a repository-relative path. |
| commit_searchA | Search commit messages (subject and body) on HEAD for a literal, case-insensitive text, newest first. Useful for finding when and why something changed, e.g. a ticket id, a feature name or "revert". Optionally limited to a time window, author and/or path. |
| file_historyA | List the commits on HEAD that changed a single file, newest first, following the file across renames. Each commit includes the path it had then and lines added/removed. Useful for "how did this file evolve?" and "who reworked it, and when?". |
| file_hotspotsA | Rank files by how many commits changed them in the last N days (merge commits excluded), with how many of those commits were fixes. Pass types: ["fix"] to rank by bug fixes only and find the files that keep breaking. Useful for spotting churn, risky areas and refactoring candidates. |
| change_couplingA | Find pairs of files that are often changed in the same commits in the last N days (merge commits excluded), most shared commits first. Reveals hidden dependencies that imports do not show, e.g. code and the config or test it always drags along. Pass "file" to see what usually changes together with one file. |
| list_tagsA | List tags (releases) newest first with their date and tagged commit, plus the latest tag reachable from HEAD and how many commits were made since it (unreleased work). Use it to find tag names for release_notes_draft or compare_refs. |
| release_notes_draftA | Group commits between two refs by conventional-commit type (breaking changes, features, fixes, ...) as a Markdown draft, or as structured sections. "from" defaults to the latest tag before "to"; without any tag, all commits up to "to" are used. To draft notes for an existing release, pass its tag as "to" (see list_tags). |
| compare_refsA | Compare two refs (branches, tags or commits): how many commits "head" is ahead of and behind "base", and which commits those are, newest first. Useful for "how far behind main is my branch?" or "what is on this branch that is not released yet?". |
| stale_branchesA | List branches whose latest commit is at least N days old, oldest first, and whether each is already merged into HEAD. |
| knowledge_mapA | Who knows a file or directory: each author's share of the knowledge, from the commits they made in the last N days (merge commits excluded), with recent commits weighted more. Also returns the bus factor and how many files depend on a single person. Useful for "who should review this?" and "who knows the auth module best?". |
| review_contextA | Review briefing for the changes in base..head (e.g. a branch or pull request): the changed files ranked by how often they changed and broke on base, files that usually change together with them but were left out (a forgotten test, config or caller), and who knows the changed files best as suggested reviewers. Merge commits are excluded. |
| code_ageA | How long ago each file on HEAD last changed, oldest first, with its last author and whether that author still commits to the repository. Also returns an age histogram, the median age per directory and how many files were last touched by someone who has left. Useful for "which parts of the code nobody touches any more?" and "where are we losing knowledge?". |
| contributor_summaryB | Count commits per author on HEAD in the last N days, most active first. Optionally restricted to a path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| weekly_engineering_update | Draft a weekly engineering update for stakeholders from recent repository activity. |
| review_branch | Review briefing for a branch or pull request: risky files, files that may have been forgotten, suggested reviewers and a checklist, from the git history of the base branch. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| app overview | Current branch, last commit, latest tag and commit/branch/tag counts. |
TDQS
Scored across 13 tools
Each tool targets a distinct git-analytics question: activity, commit search, file history, hotspots, coupling, ownership, releases, branch staleness, review context, code age, and contributor counts. The only mild overlap is commit-listing tools like recent_activity and commit_search, but their descriptions clearly distinguish time-based listing from literal message search.
All names use snake_case and are descriptive, giving a predictable style overall. However, the set mixes noun-phrase names (recent_activity, file_history, code_age) with two verb-first names (list_tags, compare_refs), so it is not a single consistent verb_noun pattern.
13 tools fit the repo-analytics scope well; each covers a different analysis and there is no obvious redundancy. The count is within the ideal 3-15 range and earns its place.
The surface covers commit history, file churn, ownership, releases, branch staleness, and review context, which is strong for a read-only analytics server. Minor gaps remain: no general branch listing or single-commit diff inspection, which could force agents to work around missing operations.