mcp-server-git: start with uvx, check the working tree first

Who it's for

People who need a model to interact with and automate a local Git repository—read the working-tree status first, then decide whether to search or change anything. It fits operators who already have uv installed (so they can run mcp-server-git directly with uvx) and can supply a real repo_path. It is not a fit if you have no local repository, or if you expect the documentation to already list every write tool. Official page: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git

First try in 3 minutes

Follow one official path only: run mcp-server-git directly with uvx. Do not start with pip.

Prerequisites: uv / uvx is available on this machine. The notes say that in this case “no specific installation is needed”. Also prepare a local Git repository path; later repo_path must point to it. uv notes: https://docs.astral.sh/uv/ uvx notes: https://docs.astral.sh/uv/guides/tools/

Install and configure location: in the MCP client, write the launch command as a direct call:

uvx mcp-server-git

Low-risk action: after a successful connection, call only git_status, with repo_path (string, Git repository path) as the parameter. It shows working-tree status and returns text for the current working directory. Do not jump into “manipulate” operations on the first try: the excerpt only guarantees that the server has read / search / manipulate capabilities; it does not name tools other than git_status.

Success signal: a stretch of working-tree status text comes back (clean or with uncommitted changes both count), not a missing-repository or command-not-found error. If it fails, first confirm uvx is available and that repo_path points at an existing Git repository.

Use cases

Case 1: Inspect the working tree. This maps to the tool git_status. Before any search or change, have the model read whether the current branch is clean and whether there are untracked files. The only input is repo_path; the return is text status. The evidence does not describe a field structure for that status text, so do not assume you can take a structured diff directly.

Case 2: Automate beyond read-only on the same repository. The server is positioned as “Git repository interaction and automation” and states it can read, search, and manipulate. But the current excerpt only expands git_status; it also says the project is in early development, and features and available tools will change and expand. So the second case can only go this far: first use git_status to confirm the repository is reachable, then operate on other tools the client actually lists—if the client lists no write or search tools, stop at status queries. Do not fill in commit / push commands from other Git plugins.

Boundaries

This is a server in early development. The tool list may grow or shrink; do not treat names you see in the current client as a long-term stable API.

The recommended install is uvx; installing mcp-server-git with pip and then running python -m mcp_server_git is only a fallback. Do not put it beside uvx as the first path.

The evidence describes only git_status in detail. read / search / manipulate is a capability overview, not three published tool manuals. manipulate on a repository has side effects; confirmation must be that the working tree or commit history shows the expected change, and that repo_path did not point at the wrong directory.

What is accessed is a local Git repository. This is not zero local reads and not a zero privacy boundary. There is no client list and no remote hosted entry point.