Git MCP Server: Install, Tools and Safety

The Git MCP server is the official reference server for local Git work. It gives an agent 12 tools to read status and diffs, search history, stage, commit, branch and check out. It runs over stdio with uvx mcp-server-git, speaks no network protocol, and has no push or pull tool. Point it at one repo with --repository. We checked it on 31 October 2026.

Quick facts

A note on history. The old standalone Git server was copied into the archive repo servers-archived. The current server in modelcontextprotocol/servers is the maintained one, and the main README still lists Git among the seven live reference servers (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time). Use that one, not the archive copy.

What it does

Most of what a coding agent needs from git is already reachable through a shell tool. So why use a server? Two reasons. The tools are typed, so the agent gets structured arguments instead of composing shell strings. And the server can be fenced to one repository, which a bare shell cannot do.

A typical use is reading. You ask the agent "what changed on this branch since main?" and it calls git_diff with a target, then git_log, then git_show on a commit or a file at a revision. It never needs a shell to do it.

The 12 tools

Two details are worth knowing. git_log accepts relative dates such as "2 weeks ago" and "yesterday", which makes "what did we change last week?" a single call. And git_show can read a file at any revision, so an agent can compare an old version of a file with the current one without checking anything out.

What is missing

There is no push, pull, fetch, merge, rebase, stash, tag or remote tool in the README list. That is a deliberate narrowness, in our reading, though the README does not say so. It means the server alone cannot publish your work or change anything on a remote. It also means it cannot resolve a merge conflict flow. For pull requests and remotes, pair it with the GitHub MCP server.

There is also no history-rewriting tool. git_reset only unstages. That is gentler than a shell, where git reset --hard is one typo away.

Install it

The Git README documents Claude Desktop, VS Code and Docker. Lines for the other agents below are our adaptation from each agent's own MCP docs. First install uv so uvx exists. See MCP clients for how each agent names its fields.

Run it by hand once to confirm it starts. It will print little and seem to hang, because stdio servers wait for a client:

uvx mcp-server-git --repository /path/to/repo

Or with pip:

pip install mcp-server-git
python -m mcp_server_git --repository /path/to/repo

To try its tools without an agent, use the MCP Inspector:

npx @modelcontextprotocol/inspector uvx mcp-server-git

Install it in each agent

Claude Code

Our adaptation, from Claude Code's MCP docs:

claude mcp add git -- uvx mcp-server-git --repository "$(pwd)"

Run it from the repo you want to expose. Use --scope project if you want the entry shared through a checked-in .mcp.json; then use --repository . instead of an absolute path, since the README says the server walks up to the enclosing repository root.

Codex

Our adaptation, in ~/.codex/config.toml:

[mcp_servers.git]
command = "uvx"
args = ["mcp-server-git", "--repository", "/path/to/repo"]

Cursor

Our adaptation, in .cursor/mcp.json, using the same shape as the README's Claude Desktop entry:

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "/path/to/repo"]
    }
  }
}

Antigravity

Our adaptation. Add the same entry under mcpServers in ~/.gemini/config/mcp_config.json. Antigravity's serverUrl field is for Streamable HTTP, and the Git server speaks stdio only, so use command and args. Gemini CLI is now for Code Assist enterprise customers only, so we do not give a Gemini CLI line.

OpenCode

Our adaptation, in opencode.json:

{
  "mcp": {
    "git": {
      "type": "local",
      "command": ["uvx", "mcp-server-git", "--repository", "/path/to/repo"]
    }
  }
}

VS Code

The README documents .vscode/mcp.json or the user configuration (Command Palette, "MCP: Open User Configuration"), with one-click buttons for uv and Docker, and a manual entry using uvx.

Docker

The README's Docker entry mounts a folder into the container:

{
  "mcpServers": {
    "git": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "--mount",
               "type=bind,src=/Users/username,dst=/Users/username", "mcp/git"]
    }
  }
}

Mount only the repository, not your home directory. The README's example uses a home folder as a placeholder.

The repository guard

This is the part of the README to read twice. The server reads and writes any Git repository the process can reach, unless you start it with --repository. Each tool call names its own repo_path. That holds for the tools that change things too: git_add, git_commit, git_reset, git_create_branch and git_checkout.

With --repository set, the rules tighten:

• The flag accepts any path inside a working tree. At startup the server walks up to the repository root, like git rev-parse --show-toplevel.
• Every tool call's repo_path must be inside that repository.
• The directories Git uses for it must be inside too. A nested repository whose .git file, commondir or core.worktree points outside is refused.
• A linked worktree can still be the --repository.

Our advice is simple: never run it without the flag. An agent that can name any path can commit into any repo you own.

Protocol and errors

The server speaks both MCP eras over stdio with nothing to configure: the 2026-07-28 revision and the 2025-11-25 revision. It never asks a client for Roots, which the 2026-07-28 spec deprecates. Repository access comes from --repository or each call's repo_path.

When a tool fails, it returns a result flagged isError: true with text like Error executing tool <name>: <message>, so the model can read the error and retry. An unknown tool name is a protocol error (JSON-RPC -32602).

Three jobs it does well

These are our suggestions, built from the tool list. We did not run them.

Summarise a branch before review

Ask the agent to compare your branch with main. It would call git_branch to confirm the names, git_diff with main as the target, and git_log with a max_count to read the commit messages. Because every call is read-only, you can allow all three without a prompt.

Find what changed last week

git_log takes a start timestamp in relative form, so "commits since 2 weeks ago" is a single call. Follow it with git_show on the commits that look relevant. This is handy on a repo you have not touched for a while, or on a teammate's branch.

Stage and commit in small pieces

The agent can call git_diff_unstaged, pick files, stage them with git_add using an explicit file list, check git_diff_staged, and then call git_commit. Using a file list instead of ["."] keeps stray files out. If it stages the wrong thing, git_reset clears the whole index, though it cannot unstage one file at a time. That is a real limit: the tool unstages everything.

A good rule for any of these: have the agent show you the staged diff in the chat before it commits, and approve the commit tool call by hand.

Security notes

1. Guard the path. Use --repository every time. See the section above.
2. Commits are real. git_commit writes to history under your configured git identity. Review what the agent staged with git_diff_staged before it commits. Some agents let you set the tool to "ask each time".
3. `git_add` with `["."]` stages everything. That includes files you meant to keep out. A good .gitignore is your protection, and the server does not add a second one.
4. Output is untrusted text. A commit message, a branch name or a file at a revision can carry text written to steer an agent. Treat what comes back as data.
5. No credentials needed, none stored. The server has no auth, so it cannot use or leak a token. It also cannot push, which limits the damage a confused agent can do remotely.
6. Not hardened for production. The monorepo README says its servers are reference implementations meant as examples, and that you should assess your own threat model.

Limits and known issues

• Early development. The Git README says the functionality and tools are subject to change. Expect tool changes between releases, and pin a version if you build on it.
• Python 3 and uv. You need a Python runtime, which a Node-only machine may lack. The Node servers in the same repo need Node 24 or later, but Git does not.
• No remote operations. See above.
• Large diffs. The diff tools return the whole diff as text. A huge diff fills the agent's context. We found no truncation or paging of diff output in the server source.
• Licence in transition. GitHub shows no SPDX id because the LICENSE text now covers both MIT and Apache-2.0. Check it if your company has a licence review.

Alternatives

Our Claude Code MCP servers page ranks which of these to add first.

Which agents it suits

Our take

We did not run this server for this page. Everything here comes from the Git README, the monorepo README and the release data.

The honest question is whether you need it. A coding agent with a shell can already run git status and git diff. What the server adds is a fence and a narrower verb list: no push, no rewrite, one repository. If your worry is an agent doing damage with raw git, that narrowness is the value. If you simply want convenient history queries, a shell is fine.

The two things we like are --repository and the relative-date filter on git_log. The two we would watch are the early-development warning and the lack of any remote tool, which means you will usually run it next to something else.

A short setup checklist

1. Install uv.
2. Run uvx mcp-server-git --repository <repo> once to confirm it starts.
3. Add it to your agent with the path set.
4. Ask for git_status and git_log first, as read-only checks.
5. Require approval on git_commit and git_reset.
6. Keep a .gitignore that covers secrets before you let the agent stage files.

Frequently asked questions

What does the Git MCP server do?

It lets an agent run git operations on a local repository through 12 typed tools: status, diffs, log, show, branch, add, commit, reset, create branch and checkout.

Can it push or pull?

Not with the tools in the README. The list has no push, pull, fetch or merge tool. For remote work, use the GitHub MCP server or the git command itself.

How do I limit it to one repository?

Start it with --repository and a path. Without that flag the server can read and write any Git repository the process can reach.

Do I need Node?

No. The Git server is Python, run with uvx mcp-server-git. Node 24 is needed for the Node-based reference servers such as Memory.

Is it production ready?

The repo calls its servers reference implementations, not production solutions, and the Git README says the server is in early development.