インストール
uvx mcp-server-git向いている人
モデルにローカル Git リポジトリ上で対話と自動化をさせ、まずワークツリーの状態を読み、続けて検索や変更をするか決める人。すでに uv が入っており（そのため uvx で mcp-server-git を直接実行でき）、実在する repo_path を渡せる運用者向け。ローカルリポジトリがない人、またはドキュメントに書き込みツールがすべて列挙済みだと期待する人には向かない。公式ページ： https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git
3 分で最初の試行
公式の一本道だけを使う。uvx で mcp-server-git を直接実行する。先に pip を使わない。
前提：このマシンで uv / uvx が使えること。説明はこの場合 “no specific installation is needed” と書いている。加えてローカル Git リポジトリのパスを用意し、後の repo_path はそれを指す必要がある。uv の説明： https://docs.astral.sh/uv/ uvx の説明： https://docs.astral.sh/uv/guides/tools/
インストールと設定の場所：MCP クライアントでは起動コマンドを直接呼び出しとして書く。
uvx mcp-server-git
低リスクな操作：接続成功後、git_status だけを呼び、引数は repo_path（文字列、Git リポジトリパス）。ワークツリーの状態を表示し、現在の作業ディレクトリ状態のテキストを返す。最初から「manipulate」系の操作をしない。抜粋が保証しているのはサーバーが read / search / manipulate 能力を持つことだけで、git_status 以外のツール名は書いていない。
成功の合図：ワークツリー状態のテキストが返る（クリーンでも未コミットの変更があっても成功）。リポジトリが見つからない、コマンドが存在しない、ではないこと。失敗したら、先に uvx が使えることと、repo_path が既存の Git リポジトリを指していることを確認する。
ユースケース
ケース 1：ワークツリーを見る。ツール git_status に対応する。検索や変更の前に、現在のブランチがクリーンか、未追跡ファイルがあるかをモデルに読ませる。入力は repo_path のみ、戻りはテキスト状態。根拠にその状態テキストのフィールド構造はないので、構造化 diff を直接取れるとは仮定しない。
ケース 2：同じリポジトリで読み取り専用を超えた自動化。サーバーの位置づけは “Git repository interaction and automation” で、read、search、manipulate ができると書いてある。ただし現行の抜粋が展開しているのは git_status だけであり、プロジェクトは early development にあり、機能と利用可能なツールは変化し拡張するとある。したがって第二のケースはここまでしかできない：まず git_status でリポジトリに届くことを確認し、クライアントが実際に一覧した他のツールで操作する——クライアントが書き込みや検索ツールを出さなければ状態照会で止める。他の Git プラグインから commit / push コマンドを補わない。
利用の境界
早期開発中のサーバーであり、ツール一覧は増減しうる。今のクライアントで見た名前を長期安定 API だと思わない。
推奨インストールは uvx。pip で mcp-server-git を入れてから python -m mcp_server_git を実行するのは予備であり、uvx と並べて第一条の経路にしない。
根拠が詳しく述べているのは git_status だけ。read / search / manipulate は能力の概要であり、3 冊の公開ツール説明ではない。リポジトリへの manipulate には副作用がある。確認点は、ワークツリーまたはコミット履歴に想定どおりの変化が出たこと、かつ repo_path が誤ったディレクトリを指していないこと。
アクセスするのはローカル Git リポジトリであり、ローカル読み取りゼロでもプライバシー境界ゼロでもない。クライアント一覧も、リモートのホスト入口もない。