Dig MCP Server

mcp-server-dig

English | 日本語

MCP server for AI-powered code archaeology — explore git blame, file history, contributor patterns, and co-change analysis through the Model Context Protocol.

Tools

Workflow Integration

Composite Analysis

Data Retrieval

git_file_history

Get the commit history for a specific file with diff stats.

git_blame_context

Semantic blame that groups consecutive lines by the same commit into blocks.

git_related_changes

Find files that frequently change together with a given file (co-change analysis).

git_contributor_patterns

Analyze contributor patterns — who has expertise in what areas.

git_search_commits

Search commit messages by keyword. Useful for finding when a feature was introduced, a bug was fixed, or locating commits related to a ticket number.

git_commit_show

Show detailed information about a specific commit: full message, changed files, and optionally the diff. Useful for drilling into a commit found via git_search_commits.

git_diff_context

Show the diff between two commits, branches, or tags. Useful for understanding what changed between releases, branches, or any two points in history.

git_hotspots

Identify the most frequently changed files in the repository. Files with high change frequency often indicate areas of technical debt, active development, or bug-prone code.

git_pickaxe

Search for commits that introduced or removed a specific string or regex pattern in the codebase (git's pickaxe feature). Essential for finding when a function, variable, or pattern first appeared or was removed.

git_code_churn

Analyze code churn (lines added + deleted) per file. High churn files may indicate unstable code, frequent refactoring, or areas needing architectural attention. Complements git_hotspots by measuring change volume, not just frequency.

git_stale_files

Find files that have not been modified for a long time. Stale files may indicate dead code, forgotten configuration, or areas of technical debt that need review or removal.

git_merge_base

Find the common ancestor (merge base) of two branches or refs and show commits on each side since divergence. Useful for understanding branch relationships and reviewing what will be merged.

git_tag_list

List tags sorted by creation date with associated messages. Useful for understanding release history and versioning patterns.

git_knowledge_map

Show who owns knowledge of each directory, including bus factor analysis. Helps identify knowledge concentration risks and areas where team cross-training is needed.

git_dependency_map

Visualize implicit dependency networks between directories based on co-change patterns. Directories that frequently change together may have hidden coupling.

git_bisect_guide

Pre-bisect analysis for identifying bug-introducing commits. Shows commit count in range, estimated bisect steps, hotspots, and relevant commits. Does NOT run git bisect itself.

git_rename_history

Track the rename history of a file. Reconstructs the full rename chain showing how a file was renamed over time.

git_commit_graph

Analyze merge patterns and branch integration topology. Calculates merge ratio, merge frequency, merge sources, and classifies the integration style.

git_branch_activity

Analyze branch activity levels, classifying branches as active, stale, or abandoned based on recent commit activity.

git_author_timeline

Analyze author activity periods and team composition changes over time.

git_commit_frequency

Analyze commit frequency over time periods. Groups commits into daily, weekly, or monthly buckets to identify development patterns.

git_release_notes

Generate release notes between two refs by aggregating commits using Conventional Commits format. Groups by type/scope, detects breaking changes, and lists contributors.

git_contributor_network

Analyze contributor collaboration network. Shows which developers work on the same files, revealing team collaboration patterns and knowledge silos.

git_conflict_history

Detect files that frequently appear in merge commits. High-frequency merge files indicate conflict-prone areas that may need refactoring.

git_survival_analysis

Analyze code churn trends over time. Shows additions, deletions, net change, and churn rate per period. Useful for identifying refactoring phases and code instability.

git_code_age

Analyze the age distribution of code lines in a file using blame data. Groups lines into age brackets (< 1 month, 1-3 months, 3-6 months, 6-12 months, > 1 year) to visualize how old different parts of a file are.

git_commit_message_quality

Analyze commit message quality metrics including Conventional Commits compliance rate, average subject length, long subject violations (>72 chars), issue reference rate, and type distribution.

git_reflog_analysis

Analyze git reflog entries to understand HEAD movement history. Shows branch switches, resets, rebases, and other ref updates. Useful for recovering lost commits and understanding local workflow patterns.

git_cherry_pick_detect

Detect cherry-picked or equivalent commits between branches using git cherry. Shows which commits have already been applied to upstream and which are unique. Useful for identifying duplicate work across branches.

git_line_history

Track the evolution of specific lines or a function using git log -L. Shows how a code block changed across commits — unlike blame (snapshot) or file_history (file-level), this reveals line-level change history.

git_commit_cluster

Detect clusters of related commits by time proximity and shared files. Reveals logical changeset boundaries — groups of commits that form a coherent change.

git_merge_timeline

Analyze merge frequency over time. Shows merge counts, branch activity, and trend direction per period.

git_complexity_hotspots

Identify and rank maintenance complexity hotspots using 6-dimension risk assessment (change frequency, code churn, knowledge concentration, coupling, staleness, conflict frequency).

git_contributor_growth

Analyze contributor growth and retention over time. Tracks new/departed contributors per period (monthly or quarterly), computes retention rates, bus factor trends, and classifies overall trajectory as growing/stable/shrinking.

git_code_ownership_changes

Compare code ownership before and after a date boundary. Detects owner handoffs, bus factor changes, new/departed contributors, and knowledge transfer patterns.

git_impact_analysis

Analyze the blast radius of changes to a file or directory. Combines co-change networks, contributor overlap, and directory coupling to assess how far changes might ripple.

git_review_prep

Generate a PR review briefing by analyzing the diff between two refs. Combines diff stats, commit history, hotspot/churn analysis, contributor patterns, and co-change detection to surface risk flags, suggest reviewers, and warn about potentially missing files.

Example output:

PR Review Briefing: main...HEAD
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Commits (2):
  abc1234 feat: add new feature
  def5678 fix: handle edge case

Changed files (3, +35 -10):
  src/foo.ts | +25 -5
  src/bar.ts | +10 -5

Risk flags:
  src/foo.ts — HOTSPOT (15 changes), HIGH CHURN (450 lines)

Suggested reviewers:
  Alice <alice@example.com> — 12 commits to src/foo.ts

Potentially missing files:
  src/foo.test.ts — co-changes with src/foo.ts 85% of the time

git_why

Explain why code exists by combining blame, commit context, contributor patterns, and co-change analysis into a narrative. Answers the question "Why does this code look this way?" for a file or line range.

Example output:

Why does this code exist? — src/foo.ts L10-25
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Blame summary (3 commits, 2 authors):

[L10-15] abc1234 | 2024-06-15 | Alice
  Commit: feat: add validation logic
  Files in commit: src/foo.ts, src/foo.test.ts

[L16-25] def5678 | 2024-08-20 | Bob
  Commit: fix: handle null input (Fixes #42)
  Files in commit: src/foo.ts, src/bar.ts

File context:
  Contributors: Alice (80%), Bob (20%)
  Co-changed with: src/foo.test.ts (85%), src/types.ts (60%)

git_file_risk_profile

Comprehensive risk assessment for a single file combining change frequency, code churn, knowledge concentration, implicit coupling, and staleness into a multi-dimensional profile.

Example output:

Risk profile for: src/core/engine.ts
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Change frequency:  HIGH (47 changes, top 3%)
Code churn:        HIGH (1,230 lines churned)
Knowledge risk:    MEDIUM (2 contributors, top owns 78%)
Coupling:          HIGH (12 co-changed files)
Staleness:         LOW (last changed 3 days ago)

Overall: HIGH RISK
Concerns: frequently changing, high code churn, highly coupled

git_repo_health

Repository-wide health summary combining file count, commit activity, top hotspots, highest churn files, contributor distribution, and stale file count into a single overview.

git_repo_statistics

Analyze repository physical structure and size metrics — object counts, pack statistics, total commits, branch/tag counts, repository age, and largest tracked files.

git_commit_patterns

Analyze commit distribution by day-of-week and hour-of-day — heatmap-style patterns including peak activity windows, weekday/weekend ratios, and timezone distribution.

git_revert_analysis

Analyze revert patterns in the repository — detects commits created by git revert, links them to their original commits, calculates time-to-revert statistics, and identifies files that are frequently reverted (revert hotspots).

git_velocity_anomalies

Detect statistical anomalies (spikes and drops) in commit frequency using mean +/- N sigma threshold.

git_tag_analysis

Analyze tag-based release patterns — semver distribution, annotated vs lightweight tags, release interval statistics, frequency trend, and naming prefix distribution.

git_activity_drought

Detect files with prolonged periods of no development activity (droughts). Identifies stagnant code by finding consecutive time periods with zero commits.

git_stability_prediction

Predict file stability by combining 4 signals: revert ratio, churn trend, code age, and conflict frequency. Returns a stability score (0-100) for each file.

Prompts

MCP Prompts provide guided workflows that chain multiple tools together for common use cases.

Resources

Setup

Prerequisites

• Node.js >= 22
• Git

Install

npm install -g mcp-server-dig

Or build from source:

git clone https://github.com/nakishiyaman/mcp-server-dig.git
cd mcp-server-dig
npm install
npm run build

Configure

Add to your MCP client configuration (e.g. Claude Desktop claude_desktop_config.json):

{
  "mcpServers": {
    "dig": {
      "command": "mcp-server-dig"
    }
  }
}

Or if running from source:

{
  "mcpServers": {
    "dig": {
      "command": "node",
      "args": ["./build/index.js"]
    }
  }
}

Zed

Add to your Zed settings.json:

{
  "context_servers": {
    "dig": {
      "command": {
        "path": "mcp-server-dig",
        "args": []
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "dig": {
      "command": "mcp-server-dig"
    }
  }
}

Windsurf

Add to your Windsurf MCP configuration:

{
  "mcpServers": {
    "dig": {
      "command": "mcp-server-dig"
    }
  }
}

Configuration

Timeout

All 54 tools accept an optional timeout_ms parameter (default: 30000ms, max: 300000ms) for large repositories.

Output Format

All 54 tools accept an optional output_format parameter:

• "text" (default) — human-readable formatted output
• "json" — structured JSON for programmatic consumption

Tool Annotations

All 54 tools declare MCP Tool Annotations (readOnlyHint: true, openWorldHint: false), enabling clients to understand that dig tools are read-only git analysis operations.

Streamable HTTP Transport

By default, dig runs on stdio. To use Streamable HTTP transport:

# Via CLI flag
mcp-server-dig --http

# Via environment variable
DIG_TRANSPORT=http mcp-server-dig

HTTP mode listens on http://127.0.0.1:3000/mcp. Change the port with DIG_PORT:

{
  "mcpServers": {
    "dig": {
      "command": "mcp-server-dig",
      "args": ["--http"],
      "env": {
        "DIG_PORT": "8080"
      }
    }
  }
}

Auto-completion

Prompt arguments and resource URI paths support MCP completion protocol for interactive clients.

Structured Logging

Logging uses the MCP Logging Protocol when connected to a client, with stderr fallback.

Set DIG_LOG_LEVEL environment variable to control log verbosity:

Documentation truncated — see the full README on GitHub.