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.

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
   • Input:
     • repo_path (string): Path to Git repository
   • Returns: Diff output of unstaged changes

3. git_diff_staged

   • Shows changes that are staged for commit
   • Input:
     • repo_path (string): Path to Git repository
   • 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
   • 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

6. git_add

   • Adds file contents to the staging area with support for batch operations
   • Inputs:
     • repo_path (string): Path to Git repository
     • files (string[], optional): Array of file paths to stage (use ["."] to stage everything)
     • update_only (boolean, optional): Stage only tracked file updates and deletions (git add -u)
     • patterns (string[], optional): Array of glob patterns to match files (e.g., [".py", "src/**/.js"])
   • Returns: Confirmation of staged files
   • Note: Only one of files, update_only, or patterns should be specified

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 advanced filtering and formatting
   • Inputs:
     • repo_path (string): Path to Git repository
     • max_count (number, optional): Maximum number of commits to show (default: 10)
     • oneline (boolean, optional): Compact format showing hash and message only (default: false)
     • graph (boolean, optional): Show merge graph structure (default: false)
     • format (string, optional): Custom format string (e.g., "%h - %s (%an)")
     • since (string, optional): Show commits after date (e.g., "2024-01-01", "1 week ago")
     • until (string, optional): Show commits before date (e.g., "yesterday", "2024-12-31")
     • author (string, optional): Filter by author name or email
     • grep (string, optional): Search commit messages with regex pattern
     • files (string[], optional): Show only commits affecting these files
     • branch (string, optional): Show log for specific branch (default: current)
     • reverse (boolean, optional): Show commits in reverse chronological order (default: false)
     • merges (boolean, optional): Filter merge commits (null=all, true=only merges, false=no merges)
   • Returns: Formatted commit log matching specified criteria
   • Examples:
     • Find recent fix commits: {repo_path: ".", max_count: 20, grep: "fix:", oneline: true}
     • Changes by author: {repo_path: ".", author: "john@example.com", since: "1 month ago"}
     • File history: {repo_path: ".", files: ["src/main.py"], max_count: 50}

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): Starting point for the new 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

11. git_show

• Shows the contents of a commit
• Inputs:
  • repo_path (string): Path to Git repository
  • revision (string): The revision (commit hash, branch name, tag) to show
• Returns: Contents of the specified commit

12. git_init

• Initializes a Git repository
• Inputs:
  • repo_path (string): Path to directory to initialize git repo
• Returns: Confirmation of repository initialization

Azure DevOps Integration

The server provides Azure DevOps integration for monitoring and analyzing Azure Pipelines builds:

1. azure_get_build_status

   • Get status of an Azure DevOps build/pipeline run
   • Inputs:
     • project (string): The project name or ID
     • build_id (integer): The build ID
   • Returns: Formatted build status information including definition, status, result, branch, and timing

2. azure_get_build_logs

   • Get logs from an Azure DevOps build
   • Inputs:
     • project (string): The project name or ID
     • build_id (integer): The build ID
     • log_id (integer, optional): Specific log ID to retrieve. If omitted, lists all logs
   • Returns: Log content or list of available logs

3. azure_get_failing_jobs

   • Get detailed information about failing jobs in an Azure DevOps build
   • Inputs:
     • project (string): The project name or ID
     • build_id (integer): The build ID
     • include_logs (boolean, optional): Whether to include log excerpts (default: true)
   • Returns: Detailed failure information including error messages and log excerpts

Configuration: Azure DevOps integration requires setting AZURE_DEVOPS_TOKEN and AZURE_DEVOPS_ORG environment variables. See the Environment Variables section for details.

Lean MCP Interface (Context-Optimized)

The server provides an alternative lean interface that reduces context consumption by ~97% (from ~30k tokens to ~900 tokens). Instead of exposing all 64 tools upfront, it uses a 3-meta-tool pattern:

Meta-Tool	Purpose
discover_tools(pattern)	List available tools with optional filtering
get_tool_spec(tool_name)	Get full schema for a specific tool on-demand
execute_tool(tool_name, params)	Execute any tool dynamically

Tool Coverage: All 64 tools remain accessible (27 git, 34 GitHub, 3 Azure DevOps).

Usage Example:

# 1. Discover available tools (optional filtering)
discover_tools("pr")  # Returns 11 PR-related tools

# 2. Get schema when needed
get_tool_spec("github_create_pr")  # Returns full parameter schema

# 3. Execute the tool
execute_tool("github_create_pr", {
    "repo_owner": "owner",
    "repo_name": "repo",
    "title": "feat: new feature",
    "head": "feature-branch",
    "base": "main"
})

Configuration: Use the mcp-git-lean entry point:

"mcpServers": {
  "git-lean": {
    "command": "pixi",
    "args": ["run", "-m", "mcp-git-lean", "--repository", "path/to/repo"]
  }
}

Important: Repository Path Resolution

The repo_path parameter in all git tools supports the following behaviors:

• Absolute paths: Always used directly (e.g., /home/user/my-repo)
• "." (current directory): Resolves to the bound repository when the server is started with the --repository parameter. If no repository is bound, the operation will fail with a clear error message.
• Relative paths: Converted to absolute paths relative to the current working directory. For best reliability, use absolute paths or bind a repository with --repository.

Recommended Usage:

• When starting the server, use the --repository parameter to bind to a specific repository
• In tool calls, use repo_path: "." to reference the bound repository
• For operations on different repositories, provide absolute paths

Example:

# Start server bound to a repository
mcp-server-git --repository /path/to/my-repo

# Then use "." in tool calls to reference the bound repository
# This prevents cross-repository contamination

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

Note: For development, use pixi install instead of pip for proper dependency management.

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

python -m mcp_server_git

Configuration

Environment Variables

The server supports loading environment variables from .env files with the following precedence order:

1. Project-specific .env file - .env file in the current working directory
2. Repository-specific .env file - .env file in the repository directory (when using --repository argument)
3. ClaudeCode working directory .env file - .env file in ClaudeCode workspace root (automatically detected)
4. System environment variables - Standard environment variables

Example .env file

Create a .env file in your project directory or ClaudeCode workspace:

# GitHub API Token for GitHub integration features
# Get your token from: https://github.com/settings/tokens
GITHUB_TOKEN=your_github_token_here

# Optional: Custom GitHub API base URL (for GitHub Enterprise)
# GITHUB_API_BASE_URL=https://api.github.com

# Azure DevOps Configuration
# Get your Personal Access Token from: https://dev.azure.com/{organization}/_usersSettings/tokens
# The token should have 'Build (Read)' scope at minimum
AZURE_DEVOPS_TOKEN=your_azure_devops_pat_token_here
AZURE_DEVOPS_ORG=your_organization_name

# Optional: Log level for debugging
# LOG_LEVEL=INFO

Note: The .env file is loaded automatically when the server starts. The server intelligently detects ClaudeCode workspace directories by traversing up from both the current working directory and the repository path (if provided via --repository argument). If no .env files are found, the server will use system environment variables.

For ClaudeCode users: If you have your .env file in your ClaudeCode workspace root (e.g., /home/memento/ClaudeCode/.env), it will be automatically detected and loaded when running the MCP server from any subdirectory within that workspace.

Per-repo GitHub identities

Lets selected repos push, commit and call the GitHub API as a different identity (for example a bot). Every repo not listed behaves exactly as before.

Map file: $MCP_GIT_IDENTITIES, default ~/.config/mcp-git/identities.toml:

[identities.roth-bot]
env_file = "~/.config/gh/roth-bot.env"
repos = ["MementoRC/roth_planner"]   # Owner/repo, case-insensitive
owners = ["roth-org"]                # optional: owner logins for owner-level resources

owners (optional, case-insensitive exact match) is the only way an identity is used for owner-level resources such as github_project_* tools. A repos entry is never promoted to owner level: an owner not listed in any owners uses the default GITHUB_TOKEN. Listing the same owner under two identities, or a non-list owners, makes the map invalid (fail closed).

Env file (read only, never loaded into the server's environment; chmod 600). GITHUB_TOKEN, GPG_SIGNING_KEY, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL are required; the committer keys are optional and default to the author:

GITHUB_TOKEN=...
GPG_SIGNING_KEY=...
GIT_AUTHOR_NAME=...
GIT_AUTHOR_EMAIL=...
GIT_COMMITTER_NAME=...
GIT_COMMITTER_EMAIL=...

Adding an identity: edit the TOML (or add an env file). The map reloads when the file's mtime changes; no restart needed. A missing map file means no identities (default behaviour).

Fail closed: a mapped repo never silently runs as the owner. A missing or unreadable env file, an env file without GITHUB_TOKEN, or (for commits) a missing signing key or author name/email produces a tool error. An invalid map file (bad TOML, env_file not a string, repos not a list of strings) makes every identity lookup, and so every push, commit and repo-scoped API call, return a tool error until the file is fixed, because the server cannot tell which repos were meant to be mapped. Error messages name the problem, never secret values.

Which identity served a call: git_commit and authenticated git_push results contain an identity: <name> line, and every identity use is logged at info level (names only, never tokens).

Precedence

• Push token: identity token, then repo .env, GITHUB_TOKEN, gh auth token. The identity follows the push URL, not origin: a push to a fork or second remote uses the identity mapped to that URL's repo, or none.
• Commit signing key: explicit gpg_key_id, then identity key, then GPG_SIGNING_KEY, then user.signingkey. Author/committer come from the identity unless author is passed. While an identity is active the server does not write any key or user name/email into the repo config.
• GitHub API tools: when repo_owner/repo_name match a mapped repo, the identity token is used instead of GITHUB_TOKEN.

Limits: tag, merge, cherry-pick and rebase commits still use the default identity. A GitHub App is a possible future alternative.

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

Using uvx

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

Using docker

• Note: replace '/Users/username' with the a path that you want to be accessible by this tool

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

Using pip installation

"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, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open Settings (JSON).

Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.

Note that the mcp key is not needed in the .vscode/mcp.json file.

{
  "mcp": {
    "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:

Using uvx

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

Using pip installation

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

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

If you are doing local development, there are two ways to test your changes:

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.