安裝
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 儲存庫。
使用案例
案例一：查看工作區。對應工具 git_status。在開始任何檢索或改動前，先讓模型讀出目前分支是否乾淨、是否有未追蹤檔案。輸入只有 repo_path，回傳是文字狀態。證據沒有寫狀態文字的欄位結構，所以不要假設能直接拿到結構化 diff。
案例二：在同一儲存庫上做唯讀之外的自動化。伺服器定位是「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 是能力概述，不是三份已列出的工具說明書。對儲存庫的 manipulate 有副作用，確認點必須是工作區或提交歷史出現預期變化，且 repo_path 沒有指到錯誤目錄。
存取的是本機 Git 儲存庫，不是零本地讀取、也不是零隱私邊界。沒有用戶端名單，也沒有遠端託管入口。