GitHub MCP Server

VersionControlHelperMCP

A Model Context Protocol (MCP) server providing version control operations as tools for AI coding agents. Built specifically for integration with LangChain deepagents and other MCP-compatible LLM workflows.

What is This?

This MCP server exposes Git version control operations as structured tools that Large Language Models (LLMs) and AI agents can invoke programmatically. Instead of executing raw git commands, an AI coding agent can call typed, validated tools like commit_all_changes, rollback_to_commit, or compare_commits through the standardized MCP protocol.

Why Use This?

Installation

Prerequisites

• Python 3.11+
• uv package manager
• Git installed on system

Setup

# Clone the repository
git clone https://github.com/your-repo/VersionControlHelperMCP.git
cd VersionControlHelperMCP

# Install dependencies with uv
uv sync

Running the Server

STDIO Mode (Default)

For local usage with LangChain or other MCP clients:

uv run version-control-helper-mcp

With Default Repository Path

Set REPO_PATH to avoid passing repo_path in every tool call:

REPO_PATH=/path/to/your/project uv run version-control-helper-mcp

Development/Debugging

Use the MCP inspector for testing:

uv run mcp dev src/version_control_helper_mcp/server.py

Available Tools

This server provides 10 tools for complete version control workflows.

1. `initialize_repo`

Purpose: Initialize a new git repository or verify an existing one.

Returns: Status message (e.g., "Initialized repository with initial commit: abc1234")

When to Use:

• Starting a new project from scratch
• Before any other git operations on a fresh directory
• Safe to call on already-initialized repos (will return "Already initialized")

Example:

{
  "tool": "initialize_repo",
  "arguments": {
    "repo_path": "/Users/dev/my-project",
    "initial_commit": true
  }
}

2. `get_repo_status`

Purpose: Check the current state of the repository.

Returns: JSON object with:

• is_initialized: Whether git is set up
• current_branch: Active branch name
• has_changes: Whether there are uncommitted changes
• staged_files: Files ready to commit
• modified_files: Changed but unstaged files
• untracked_files: New files not yet tracked

When to Use:

• Before committing, to see what will be included
• After making changes, to verify modifications
• To check which branch you're on

3. `commit_all_changes`

Purpose: Stage ALL changes and create a commit in one action.

Returns: Commit SHA (40-character hash) or "No changes to commit"

Behavior:

• Automatically runs git add -A (stages everything)
• Creates commit with provided message
• Lazy initialization: If repo isn't initialized, initializes it first

When to Use:

• After generating/modifying code, to save a checkpoint
• Before risky operations, to have a rollback point
• At logical milestones during development

Best Practices for Commit Messages:

• Use conventional format: feat:, fix:, docs:, refactor:, test:
• Be descriptive: "feat: add user authentication with JWT tokens"
• Reference the change: "fix: resolve null pointer in login handler"

4. `list_commits`

Purpose: Retrieve commit history with details.

Returns: JSON with array of commits, each containing:

• sha: Full 40-char commit hash
• short_sha: 7-char abbreviated hash
• message: Commit message
• author: Author name
• `author_email