Find files that change most frequently. High change frequency correlates with defect density — the top 4% of files by change frequency typically contain 50%+ of bugs. Use this to identify files that need refactoring, better test coverage, or architectural attention. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Analyze code churn — how much code is being written and then rewritten. High churn indicates instability, unclear requirements, or code that is hard to get right. A file with 500 lines added and 400 deleted in a month is a red flag. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Find files that always change together (temporal coupling). These represent hidden dependencies not visible in imports or type signatures. If auth.ts and middleware.ts change together in 90% of commits, refactoring one without the other will likely break things. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Show who knows a file or directory best, weighted by recency, volume of changes, and commit frequency. Use this to find the right reviewer for a PR, identify knowledge silos, or plan for team transitions. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Track how a file's complexity has changed over time by sampling its state at regular intervals in git history. Identifies files growing out of control, complexity spikes from specific commits, and files that need splitting. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Assess the risk profile of uncommitted changes or a specific commit range. Combines multiple signals: file hotspot history, change size, number of files, author familiarity, and file type sensitivity. Returns a score 0-100 with per-file breakdown and actionable recommendations. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Generate structured release notes from commits between two git refs. Groups by conventional commit type, extracts breaking changes, and links PR/issue references. Supports grouping by type, scope, or author. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Comprehensive contributor analytics: who is active, what areas they work in, their commit patterns, and collaboration graph. Useful for understanding team dynamics, identifying knowledge silos, onboarding planning, and workload distribution. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Show the full commit history of a specific file — who changed it, when, how much, and why. Useful for understanding why a file looks the way it does, finding when a bug was introduced, or tracing the evolution of a module. Uses --follow to track renames. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Show the age of code in each file — when it was last modified. Identifies stale files that haven't been touched in months or years (potential dead code or abandoned features) vs actively maintained areas. Useful for cleanup planning, onboarding, and understanding which parts of the codebase are actively evolving. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Analyze when and how the team commits — day-of-week distribution, hour-of-day heatmap, commit size breakdown, and weekly velocity trends. Reveals work patterns like weekend deployments, late-night hotfixes, or declining commit velocity. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

Analyze all branches for staleness, divergence from the main branch, and merge risk. Identifies stale branches that should be cleaned up, branches that have diverged significantly and may cause merge conflicts, and branches with no recent activity. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.