安装
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 仓库，不是零本地读取、也不是零隐私边界。没有客户端名单，也没有远程托管入口。