/ ディレクトリ / プレイグラウンド / Git
← 全サーバー ↗ GitHub
● 公式 modelcontextprotocol ⚡ 即起動

Git

作者 modelcontextprotocol · modelcontextprotocol/servers

エージェントをローカルリポジトリに向けるだけで、status、log、diff、blameを読み取れます。シェルアクセスは不要です。

公式 modelcontextprotocol git サーバーです。ローカル git の読み書きに対応しており、status、log、diff（ステージ済み／未ステージ／コミット範囲）、show、show 経由の簡易 blame に加え、書き込みワークフロー向けに commit/add/branch/checkout もサポートします。単一の --repository パスにスコープが限定されるため、エージェントに生のシェルを与えるより安全です。

▶ デモを見る 📦 インストール 💡 ユースケース

なぜ使うのか

主な機能

ライブデモ

実際の動作

git.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "git",
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "git": {
      "command": {
        "path": "uvx",
        "args": [
          "mcp-server-git",
          "--repository",
          "/repo"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add git -- uvx mcp-server-git --repository /repo

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： Git

コミット前にエージェントにステージ済みの変更をレビューさせる

👤 個人開発者、コードレビューなしでリリースしている方 ⏱ ~3 min beginner

使うタイミング： コミット直前に、明らかな問題を見つけるためのセカンドオピニオンが欲しいとき。

前提条件
  • ステージ済みの変更があるローカルリポジトリ — 通常どおり git add -p してから、エージェントに依頼してください
フロー
  1. ステージ済みの diff を読む
    Show me my staged changes. Flag anything that looks like: debug logs, commented code, hardcoded secrets, or changes unrelated to the stated commit goal '<GOAL>'.✓ コピーしました
    → ファイル名:行番号 の具体的な指摘
  2. コミットメッセージを提案させる
    Write a commit message following conventional commits. First line under 60 chars, body explains why not what.✓ コピーしました
    → そのままコピー＆ペーストできるメッセージ
  3. スコープを確認する
    Based on the diff, is this commit appropriately small? Suggest splits if it touches multiple concerns.✓ コピーしました
    → Go/No-go の判断と根拠

結果： 「やっちまった」修正コミットが減り、よりクリーンなコミットが作れます。

注意点
  • シークレットが明らかにシークレットらしい形式でない場合、エージェントが見逃す — シークレットスキャナーとして頼らないでください。本当の防御策としては pre-commit フックで gitleaks や trufflehog を実行してください
  • コミットメッセージを先に頼むと、エージェントが diff を承認する方向にバイアスされる — 必ずレビューを先に行い、その後でメッセージを依頼してください。順序が重要です
組み合わせ： github

特定の行がいつ・なぜ壊れたかを特定する

👤 リグレッションをデバッグしているエンジニア ⏱ ~15 min intermediate

使うタイミング： テストが失敗し始め、どのコミットがバグを導入したか突き止める必要があるとき。

フロー
  1. 対象ファイルの履歴を絞り込む
    Show git log for src/checkout/Cart.tsx limited to the last 20 commits. Include author and short message.✓ コピーしました
    → SHA 付きのコンパクトな履歴
  2. 疑わしいコミットの diff を確認する
    For the 3 commits that touched the calculateTotal function, show the diff. Focus on math/logic changes, ignore style.✓ コピーしました
    → コミットごとの diff スニペット
  3. リグレッション仮説を立てる
    Which commit most likely introduced an off-by-one or rounding bug? Point to the exact line and explain your reasoning.✓ コピーしました
    → 具体的な SHA と行番号、根拠の説明

結果： git revert ＋テスト再実行で確認できる、コミットレベルの正確な仮説が得られます。

注意点
  • リネームが多い履歴ではリネーム時点で追跡が途切れる — git log --follow の考え方で対処してください。エージェントにリネームしたコミットを含めさせ、リネーム前のパスも確認してください
組み合わせ： github

古くなったローカルブランチを一覧・分類する

👤 `git branch` の出力が何ページにもなってしまっている方 ⏱ ~10 min beginner

使うタイミング： 四半期ごとの整理時 — ブランチが多すぎて、どれを安全に削除できるかわからないとき。

フロー
  1. ローカルブランチをすべて一覧表示する
    List every local branch with its last commit date and message.✓ コピーしました
    → ブランチの一覧テーブル
  2. 各ブランチを分類する
    Classify: 'merged' (ancestor of main), 'stale' (no commit in 60+ days), 'active' (commit in last 30 days). Flag any that look like abandoned experiments.✓ コピーしました
    → カテゴリ分けされたリスト
  3. 削除を提案する
    Give me the git branch -d command for everything safe to delete. Flag anything that needs -D (force) and explain why.✓ コピーしました
    → そのままコピー＆ペーストできるクリーンアップコマンド

結果： 作業中のブランチを誤って消していないという確信を持って、ブランチリストを整理できます。

注意点
  • main にない独自コミットを持つブランチに対してエージェントが -D を提案する — 強制削除リストは必ず目視確認してください。git reflog で復旧は可能ですが、手間がかかります

組み合わせ

他のMCPと組み合わせて10倍の力を

git + github

プッシュ前にローカル git でレビューし、同じコンテキストで GitHub に PR を作成する

Review my staged changes. If they look good, commit with a descriptive message, push the branch, and open a PR on GitHub.✓ コピーしました
git + filesystem

コード変更と git 履歴を1つの推論ループで扱う

Read src/auth/login.ts and the last 5 commits that touched it. Explain why the retry logic was added.✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
git_status repo_path セッションの最初に呼び出す — ワーキングツリーの状態を把握する free
git_diff_unstaged repo_path, context_lines? git add 前に未ステージの変更を確認する free
git_diff_staged repo_path, context_lines? コミット対象の内容を確認する free
git_diff repo_path, target, context_lines? 現在のブランチをターゲット（例: main, HEAD~5）と比較する free
git_log repo_path, max_count?, start_timestamp?, end_timestamp? 履歴を閲覧する — トークン消費を抑えるため max_count と組み合わせる free
git_show repo_path, revision 特定のコミットを詳しく確認する free
git_commit repo_path, message ステージ済みの変更からコミットを作成する — 読み取り専用構成では無効にすること free
git_add repo_path, files: string[] 特定のファイルをステージする — エージェントの安全性のため git_add . より推奨 free
git_reset repo_path すべてのステージを解除する — 危険なため通常はスキップ free
git_create_branch repo_path, branch_name, base_branch? タスク用の新しいブランチを作成する free
git_checkout repo_path, branch_name ブランチを切り替える free
git_branch repo_path, branch_type, contains?, not_contains? ブランチを一覧表示し、特定のコミットを含むかでフィルタリングする free

コストと制限

運用コスト

APIクォータ
なし — すべてローカル処理
呼び出しあたりのトークン
diff のサイズに応じて1回あたり200〜5000トークン
金額
無料
ヒント
大きな diff はトークンコストを急増させます。エージェントに全体を読ませる前に、context_lines: 1 を使用するか、プロンプトでパスを絞り込んでください。

セキュリティ

権限、シークレット、影響範囲

認証情報の保管： なし — 認証情報は不要です
データ送信先： なし — サーバーは100%ローカルで動作し、ネットワーク通信は行いません

トラブルシューティング

よくあるエラーと対処法

fatal: not a git repository

--repository のパスが git リポジトリを指していません。ls <path>/.git で確認してください。このディレクトリが存在する必要があります。

確認： ls <repo_path>/.git/HEAD
コミットされていない変更があるにもかかわらず diff 出力が空

ステージ済みと未ステージを区別してください。git_diff_unstaged と git_diff_staged は別々のツールです。まず git_status で状態を確認してください。

git_commit が 'Please tell me who you are' で失敗する

リポジトリに git config を設定してください: git config user.email ... および git config user.name ...。MCP は既存の git config を使用します。

確認： git config --get user.email
巨大な diff がトークンを大量消費する

context_lines: 0 または 1 を指定するか、完全な diff を読む前にファイルごとの要約を先にエージェントに依頼してください。

代替案

Git 他との比較

代替案代わりに使う場面トレードオフ
GitHub MCPローカルだけでなくリモートの履歴（PR、レビューコメント、Actions）が必要なときPAT が必要でネットワーク通信が発生します。より高機能ですが、攻撃対象面も広くなります
filesystem MCP + shellgit 以外の操作（grep、find、ビルドコマンド）が必要なとき影響範囲がはるかに広くなります。git だけで済むなら git MCP に留めてください

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る