Analyzes Git repository history, commit patterns, and file churn to provide insights into code evolution, ownership, and fragile files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Repo TherapistWhich files in this repo are the most fragile and prone to bugs?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Repo Therapist šļø
Your codebase explains itself under pressure
Repo Therapist is an MCP (Model Context Protocol) server that turns any repository into queryable, explainable knowledge. Ask questions about your codebase through Cursor and get structured, insightful answers.
What it does
You ask Cursor things like:
"Why is this service structured like this?"
"What will break if I remove this?"
"Which parts of this repo scare you?"
Behind the scenes, Repo Therapist:
Reads your repo structure and files
Analyzes git history and commit patterns
Correlates code with change frequency
Identifies complexity hotspots and risks
Available Tools
Tool | Description |
| Analyze a repository - run this first |
| Get the static snapshot (ground truth) of the repo |
| Get git history analysis (the time dimension) |
| Explain why a specific file is the way it is |
| Ask any question about the analyzed repo |
| Get a high-level overview |
| Generate a risk assessment report |
Ground Truth: The Snapshot
When you run analyze_repo, Repo Therapist creates a static snapshot - the authoritative source of truth about your repository. This snapshot includes:
{
"files": [...], // Every file with path, language, line count
"languages": {...}, // Language breakdown with percentages
"entryPoints": [...], // Detected entry points with confidence levels
"configs": {...}, // Parsed package.json, tsconfig, Dockerfile, CI configs
"directories": [...] // Directory structure with inferred purposes
}Why this matters: LLMs must cite this snapshot data, not guess. When you ask "What languages does this repo use?", the answer comes from the snapshot - not from the LLM making assumptions.
Use get_snapshot to retrieve specific sections:
get_snapshot(section: "files")- All files with metadataget_snapshot(section: "languages")- Language statisticsget_snapshot(section: "entryPoints")- Detected entry pointsget_snapshot(section: "configs")- Parsed configuration filesget_snapshot(section: "directories")- Directory structureget_snapshot()- Summary of everything
Git Historian: The Time Dimension
The Git Historian analyzes commit history to explain WHY code is the way it is. This is where it stops being cute.
{
"fileChurn": { "auth.ts": { "totalCommits": 47, "churnScore": 85 } },
"authors": { "auth.ts": ["alice", "bob", "charlie"] },
"fragileFiles": [{ "path": "auth.ts", "reasons": ["high-churn", "many-authors"] }],
"hotPaths": [...],
"stableCore": [...]
}This lets you answer:
"Why is this weird?" ā "Because it's been rewritten 12 times in 6 months."
"Who owns this file?" ā "Disputed - 4 people have modified it, none with >30%."
"What should I be careful with?" ā "These 5 files are fragile and bug-prone."
Use get_history to retrieve specific aspects:
get_history(section: "churn")- File change frequency and volatilityget_history(section: "authors")- Contributor statisticsget_history(section: "fragile")- Files likely to cause problemsget_history(section: "hotPaths")- Hot paths vs stable coreget_history(section: "timeline")- Key events and commit patternsget_history(section: "ownership")- Who owns whatget_history()- Summary of everything
Use why_is_this_weird for specific file analysis:
Use why_is_this_weird on "src/auth/login.ts"Returns a detailed explanation with citations:
# Why is "src/auth/login.ts" the way it is?
## Change History
- Total commits: 47
- Authors: 5 (alice, bob, charlie, dave, eve)
- Churn score: 85 ā ļø HIGH
## š Why It's Unusual
**Heavily modified:** This file has been changed 47 times...
**Many hands:** 5 different people have modified this file...Setup
1. Install dependencies
cd repo-therapist
npm install2. Build the project
npm run build3. Add to Cursor
Open Cursor Settings ā MCP ā Add new MCP server:
{
"mcpServers": {
"repo-therapist": {
"command": "node",
"args": ["/FULL/PATH/TO/repo-therapist/dist/index.js"]
}
}
}Important: Replace /FULL/PATH/TO/ with the actual absolute path to your repo-therapist folder.
Example:
{
"mcpServers": {
"repo-therapist": {
"command": "node",
"args": ["/Users/saar/Projects/private/repo-therapist/dist/index.js"]
}
}
}4. Restart Cursor
After adding the MCP config, restart Cursor for changes to take effect.
FAQ
Do I need to run repo-therapist separately?
No. Cursor automatically starts and manages the MCP server for you. When you add the config to Cursor's MCP settings, Cursor will:
Start the
node dist/index.jsprocess when neededKeep it running in the background
Communicate with it via stdio (standard input/output)
You just need to build once (npm run build), add the config, and restart Cursor. That's it.
Where do I ask questions?
In the normal Cursor chat (Cmd+L or the chat panel). The difference is how you ask:
Without MCP: "What does this repo do?" ā Cursor uses its built-in tools
With Repo Therapist: "Use
analyze_repoon/path/to/repo" ā Cursor calls the MCP tool
You explicitly tell Cursor to use the repo-therapist tools. Cursor sees them as additional capabilities it can use.
What's the difference vs normal Cursor chat?
Normal Cursor Chat | With Repo Therapist |
Reads files on demand | Pre-analyzes entire repo structure |
No git history awareness | Analyzes commit patterns & churn |
Answers based on what it reads | Answers based on structured analysis |
No risk detection | Identifies complexity hotspots |
Generic code understanding | Domain-specific insights ("what scares you?") |
The key difference: Repo Therapist does structured analysis upfront and stores it, so questions like "which files change most often?" or "what are the risks?" can be answered from pre-computed data rather than Cursor having to figure it out each time.
Think of it as: Cursor is smart but reactive. Repo Therapist gives it a "briefing document" about your codebase that it can reference.
Usage
Once configured, you can use Repo Therapist in Cursor chat:
Step 1: Analyze a repo
First, analyze the repository you want to explore:
Use analyze_repo to analyze /path/to/some/repoStep 2: Ask questions
Now you can ask questions:
Use ask_repo to answer: "What does this repo do?"Use ask_repo to answer: "Which parts of this repo scare you?"Use ask_repo to answer: "What will break if I remove the auth module?"Step 3: Get reports
Get a summary:
Use repo_summary to show me an overviewGet a risk assessment:
Use risk_report to identify potential issuesExample Questions
"What does this repo do?"
"How is the code structured?"
"What tech stack is being used?"
"Show me the dependencies"
"Which files are the largest?"
"What files change most often?"
"Who are the contributors?"
"What are the recent commits?"
"Which parts scare you?"
"What will break if I change X?"
Development
Run in development mode
npm run devBuild for production
npm run buildRun tests
npm test # Run all tests
npm run test:watch # Run tests in watch mode
npm run test:coverage # Run tests with coverage reportTesting Guidelines
Note: Always add unit tests when implementing new features.
Tests are located in tests/ and use Vitest. The test structure mirrors the source:
tests/
āāā fixtures/ # Test utilities and mock repos
ā āāā setup.ts # Helper functions for creating test repos
āāā scanner/ # Scanner module tests
āāā historian/ # Historian module tests
āāā tools/ # Tool tests
āāā cache.test.ts # Cache testsWhen adding a new feature:
Create tests in the appropriate
tests/subdirectoryUse
createTestRepo()fromfixtures/setup.tsfor git-related testsClean up test repos with
cleanupTestRepo()inafterAllRun
npm testto verify all tests pass before committing
Project structure
repo-therapist/
āāā src/
ā āāā index.ts # MCP server entry point
ā āāā cache.ts # In-memory repo cache
ā āāā types.ts # TypeScript interfaces
ā āāā scanner/ # Static snapshot engine (Step 2)
ā ā āāā index.ts # Scanner exports
ā ā āāā types.ts # Snapshot type definitions
ā ā āāā scan-repo.ts # Repository scanner
ā āāā historian/ # Git history analyzer (Step 3)
ā ā āāā index.ts # Historian exports
ā ā āāā types.ts # History type definitions
ā ā āāā analyze-history.ts # Git history analysis
ā āāā tools/
ā āāā analyze-repo.ts # Repository analyzer (orchestrates all)
ā āāā get-snapshot.ts # Snapshot retrieval (ground truth)
ā āāā get-history.ts # History retrieval (time dimension)
ā āāā ask-repo.ts # Question answering
ā āāā repo-summary.ts # Summary generator
ā āāā risk-report.ts # Risk assessment
āāā tests/ # Unit tests
ā āāā fixtures/ # Test utilities
ā āāā scanner/ # Scanner tests
ā āāā historian/ # Historian tests
ā āāā tools/ # Tool tests
āāā package.json
āāā tsconfig.json
āāā vitest.config.ts # Test configuration
āāā README.mdTech Stack
TypeScript - Type-safe codebase
@modelcontextprotocol/sdk - MCP server implementation
simple-git - Git history analysis
ts-morph - TypeScript/JavaScript AST parsing (planned)
glob - File pattern matching
Roadmap
AST-based code analysis with ts-morph
Persist analysis to JSON/SQLite
Dependency graph visualization
Security vulnerability detection
Test coverage analysis
Custom question handlers
License
MIT
This server cannot be installed
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.