mcp-server-git: A git MCP server

Overview

A Model Context Protocol server for Git repository interaction and automation. This server provides tools to read, search, and manipulate Git repositories via Large Language Models.

Source: https://github.com/modelcontextprotocol/servers/tree/main/src/git

Requires MCP Python SDK 2.x (mcp>=2.3,<3). The server is built on the SDK's high-level MCPServer: each tool is a typed Python function, and the SDK derives its input schema from the signature.

Please note that mcp-server-git is currently in early development. The functionality and available tools are subject to change and expansion as we continue to develop and improve the server.

Tools

1. git_status

   • Shows the working tree status
   • Input:
     • repo_path (string): Path to Git repository
   • Returns: Current status of working directory as text output

2. git_diff_unstaged

   • Shows changes in working directory not yet staged
   • Inputs:
     • repo_path (string): Path to Git repository
     • context_lines (number, optional): Number of context lines to show (default: 3)
   • Returns: Diff output of unstaged changes

3. git_diff_staged

   • Shows changes that are staged for commit
   • Inputs:
     • repo_path (string): Path to Git repository
     • context_lines (number, optional): Number of context lines to show (default: 3)
   • Returns: Diff output of staged changes

4. git_diff

   • Shows differences between branches or commits
   • Inputs:
     • repo_path (string): Path to Git repository
     • target (string): Target branch or commit to compare with
     • context_lines (number, optional): Number of context lines to show (default: 3)
   • Returns: Diff output comparing current state with target

5. git_commit

   • Records changes to the repository
   • Inputs:
     • repo_path (string): Path to Git repository
     • message (string): Commit message
   • Returns: Confirmation with new commit hash; an error if nothing is staged (as git commit without --allow-empty), except while a merge is in progress (MERGE_HEAD present), where git also allows an empty commit. While a merge is in progress the commit concludes it: its parents are HEAD and every MERGE_HEAD commit, and the merge state is cleared

6. git_add

   • Adds file contents to the staging area
   • Inputs:
     • repo_path (string): Path to Git repository
     • files (string[]): Non-empty array of file paths to stage; ["."] stages everything
   • Returns: Confirmation of staged files, or a message saying nothing was staged when the call left the index unchanged

7. git_reset

   • Unstages all staged changes
   • Input:
     • repo_path (string): Path to Git repository
   • Returns: Confirmation of reset operation

8. git_log

   • Shows the commit logs with optional date filtering
   • Inputs:
     • repo_path (string): Path to Git repository
     • max_count (number, optional): Maximum number of commits to show (default: 10)
     • start_timestamp (string, optional): Start timestamp for filtering commits. Accepts ISO 8601 format (e.g., '2024-01-15T14:30:25'), relative dates (e.g., '2 weeks ago', 'yesterday'), or absolute dates (e.g., '2024-01-15', 'Jan 15 2024')
     • end_timestamp (string, optional): End timestamp for filtering commits. Accepts ISO 8601 format (e.g., '2024-01-15T14:30:25'), relative dates (e.g., '2 weeks ago', 'yesterday'), or absolute dates (e.g., '2024-01-15', 'Jan 15 2024')
   • Returns: Array of commit entries with hash, author, date, and message

9. git_create_branch

   • Creates a new branch
   • Inputs:
     • repo_path (string): Path to Git repository
     • branch_name (string): Name of the new branch
     • base_branch (string, optional): Base branch to create from (defaults to current branch)
   • Returns: Confirmation of branch creation

10. git_checkout

• Switches branches
• Inputs:
  • repo_path (string): Path to Git repository
  • branch_name (string): Name of branch to checkout
• Returns: Confirmation of branch switch, or HEAD is now detached at <short sha> when branch_name is not a branch (a sha, tag or other revision)

11. git_show

• Shows the contents of a commit, or of a file or directory at a revision
• Inputs:
  • repo_path (string): Path to Git repository
  • revision (string): The revision (commit hash, branch name, tag) or object spec (HEAD:path/to/file) to show
• Returns: Contents of the specified commit, file content, or directory listing

12. git_branch

• List Git branches
• Inputs:
  • repo_path (string): Path to the Git repository.
  • branch_type (string): Whether to list local branches ('local'), remote branches ('remote') or all branches('all').
  • contains (string, optional): The commit sha that branch should contain. Do not pass anything to this param if no commit sha is specified
  • not_contains (string, optional): The commit sha that branch should NOT contain. Do not pass anything to this param if no commit sha is specified
• Returns: List of branches

Protocol versions

The server speaks both eras of the Model Context Protocol over stdio, with nothing to configure: a 2026-07-28 client (discovered with server/discover, no session) and a 2025-11-25 client (the initialize handshake). The client's first request decides which. Tools behave the same in both.

Roots is deprecated in 2026-07-28, and this server never asks a client for Roots in either era: repository access comes from --repository alone, or, with no --repository, from each tool call's repo_path. Methods the 2026-07-28 specification removes, such as ping, are answered only on a 2025-11-25 connection.

Errors

• A tool that fails returns a result with isError: true whose text is Error executing tool <name>: <message>, so the model can read it and correct the call. This covers git errors (an unknown revision, a failed command), a repo_path that is not a repository or is outside --repository, the flag-injection guards, and arguments that do not match the tool's input schema.
• An unknown tool name is a protocol error, JSON-RPC -32602 (Unknown tool: <name>), as the specification requires in both eras. Before 2.0.0 it was an isError result.

Installation

Using uv (recommended)

When using uv no specific installation is needed. We will use uvx to directly run mcp-server-git.

Using PIP

Alternatively you can install mcp-server-git via pip:

pip install mcp-server-git

After installation, you can run it as a script using:

python -m mcp_server_git

Configuration

--repository (-r) accepts any path inside a Git working tree. At startup the server walks up to the enclosing repository root, the way git rev-parse --show-toplevel does, so --repository . works when a shared config is launched from any subdirectory of the repository. A path inside the repository therefore allows tool calls anywhere in that repository, not only under the subdirectory given. A path that does not exist, or is not inside a Git repository, is logged as a one-line error at startup.

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

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

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

"mcpServers": {
  "git": {
    "command": "python",
    "args": ["-m", "mcp_server_git", "--repository", "path/to/git/repo"]
  }
}

Usage with VS Code

For quick installation, use one of the one-click install buttons below...

For manual installation, you can configure the MCP server using one of these methods:

Method 1: User Configuration (Recommended) Add the configuration to your user-level MCP configuration file. Open the Command Palette (Ctrl + Shift + P) and run MCP: Open User Configuration. This will open your user mcp.json file where you can add the server configuration.

Method 2: Workspace Configuration Alternatively, you can add the configuration to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.

For more details about MCP configuration in VS Code, see the official VS Code MCP documentation.

{
  "servers": {
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git"]
    }
  }
}

For Docker installation:

{
  "mcp": {
    "servers": {
      "git": {
        "command": "docker",
        "args": [
          "run",
          "--rm",
          "-i",
          "--mount", "type=bind,src=${workspaceFolder},dst=/workspace",
          "mcp/git"
        ]
      }
    }
  }
}

Usage with Zed

Add to your Zed settings.json:

"context_servers": [
  "mcp-server-git": {
    "command": {
      "path": "uvx",
      "args": ["mcp-server-git"]
    }
  }
],

"context_servers": {
  "mcp-server-git": {
    "command": {
      "path": "python",
      "args": ["-m", "mcp_server_git"]
    }
  }
},

Usage with Zencoder

1. Go to the Zencoder menu (...)
2. From the dropdown menu, select Agent Tools
3. Click on the Add Custom MCP
4. Add the name (i.e. git) and server configuration from below, and make sure to hit the Install button

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

Debugging

You can use the MCP inspector to debug the server. For uvx installations:

npx @modelcontextprotocol/inspector uvx mcp-server-git

Or if you've installed the package in a specific directory or are developing on it:

cd path/to/servers/src/git
npx @modelcontextprotocol/inspector uv run mcp-server-git

Running tail -n 20 -f ~/Library/Logs/Claude/mcp*.log will show the logs from the server and may help you debug any issues.

Development

Tests and coverage

The test suite drives serve() in-process through an MCP ClientSession (see tests/conftest.py), and tests/test_eras.py runs a Client against it as a 2026-07-28 and as a 2025-11-25 client. From src/git:

uv run --frozen pytest                 # the tests
uv run --frozen pytest --cov --cov-report=term-missing --cov-report=json

The second command adds branch coverage of src/mcp_server_git, printed per file and written to coverage.json (ignored by git). Every file must stay at or above 90% of its lines and 90% of its branches. Code that cannot be reached is marked # pragma: no cover # <reason> rather than lowering that bar.

Trying changes in a client

There are two ways to try your changes in a client:

1. Run the MCP inspector to test your changes. See Debugging for run instructions.

2. Test using the Claude desktop app. Add the following to your claude_desktop_config.json:

Docker

{
  "mcpServers": {
    "git": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--mount", "type=bind,src=/Users/username/Desktop,dst=/projects/Desktop",
        "--mount", "type=bind,src=/path/to/other/allowed/dir,dst=/projects/other/allowed/dir,ro",
        "--mount", "type=bind,src=/path/to/file.txt,dst=/projects/path/to/file.txt",
        "mcp/git"
      ]
    }
  }
}

UVX

{
"mcpServers": {
  "git": {
    "command": "uv",
    "args": [
      "--directory",
      "/<path to mcp-servers>/mcp-servers/src/git",
      "run",
      "mcp-server-git"
    ]
    }
  }
}

Build

Docker build:

cd src/git
docker build -t mcp/git .

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.