GitHub MCP Server

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

Running the Server

STDIO Mode (Default)

For local usage with LangChain or other MCP clients:

With Default Repository Path

Set REPO_PATH to avoid passing repo_path in every tool call:

Development/Debugging

Use the MCP inspector for testing:

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:

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: Author email

• timestamp: ISO timestamp

When to Use:

• To find a commit SHA for rollback

• To review what changes were made

• To compare two specific commits

5. rollback_to_commit

Purpose: Reset the repository to a previous commit.

Reset Modes Explained:

Returns: Message with new HEAD SHA

⚠️ WARNING: hard mode permanently deletes uncommitted changes!

When to Use:

• Agent generated bad code → rollback to last good commit

• Want to redo work differently → soft reset

• Experiment failed → hard reset to clean state

6. compare_commits

Purpose: Show detailed diff between any two commits.

Returns: JSON with:

• from_commit, to_commit: The compared SHAs

• files: Array of changed files, each with:

  • filename: Path to file

  • status: added, modified, deleted, or renamed

  • additions: Lines added

  • deletions: Lines removed

  • patch: Unified diff content

• total_additions, total_deletions: Summary counts

• summary: Human-readable summary

When to Use:

• Review what an agent changed in last iteration

• Debug regressions by comparing working vs broken states

• Understand evolution of code over time

7. create_branch

Purpose: Create a new git branch for isolated work.

Returns: Confirmation message with branch name

When to Use:

• Before experimental changes, create a feature branch

• Keep main branch stable while agent experiments

• Work on multiple features in parallel

Naming Conventions:

• feature/add-auth - New functionality

• fix/login-bug - Bug fixes

• experiment/new-algo - Experimental work

8. switch_branch

Purpose: Switch to a different branch.

Returns: Confirmation of current branch after switch

When to Use:

• Switch back to main after completing feature

• Move between different work streams

• Test code on different branches

9. list_branches

Purpose: Show all branches with current branch indicator.

Returns: Formatted list with * marking current branch:

10. generate_commit_message

Purpose: Auto-generate a commit message based on staged changes.

Returns: Suggested commit message with change summary

Styles:

• conventional: Uses prefixes like feat:, fix:, docs:

• simple: Plain descriptive message

Workflow Examples

Basic Agent Workflow

Safe Experimentation

Debugging Workflow

Dependencies

Architecture

Error Handling

All tools return clear error messages:

License

MIT