Skip to main content
Glama
surajfale

Git Commit MCP Server

by surajfale
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Git Commit MCP Server

A small MCP (Model Context Protocol) server that automates conventional Git commits, changelog updates, and optional pushes. Use this repository when you want an AI assistant to create well-formed Conventional Commit messages and manage the CHANGELOG automatically.

See detailed documentation in the docs/ folder:

  • docs/architecture.md — high-level architecture, components, and data flows.

  • docs/usage.md — setup, configuration, and common workflows (PowerShell examples included).

Quick Start

Prerequisites

  • Python 3.10+

  • Git installed and configured

  • uv package manager (for development)

  • pipx (for global installation)

Installation

Option 1: Global Installation with pipx (Recommended)

Install globally so the server is available from any directory:

# Install pipx if you don't have it
uv tool install pipx

# Install from PyPI (production)
pipx install git-commit-mcp-server

# Or install from TestPyPI (testing)
pipx install git-commit-mcp-server --index-url https://test.pypi.org/simple/ --pip-args="--extra-index-url https://pypi.org/simple/"

Option 2: Run with uvx (No Installation)

Run directly without installing:

uvx git-commit-mcp-server

Option 3: Development Mode

For local development:

# Clone the repository
git clone https://github.com/surajfale/git-mcp-server.git
cd git-mcp-server

# Install with development dependencies
uv pip install -e ".[dev]"

# Run the server
python -m git_commit_mcp.__main__

Related MCP server: Git Workflow MCP Server

Configuration

MCP Client Setup

The server works with various MCP-compatible clients including:

  • Kiro IDE — .kiro/settings/mcp.json or ~/.kiro/settings/mcp.json

  • Cursor IDE — See Cursor Configuration below

  • Claude Desktop — claude_desktop_config.json

  • WARP — MCP configuration file

  • VSCode — With MCP extension

Example configuration (Kiro IDE):

{
  "mcpServers": {
    "git-commit": {
      "command": "git-commit-mcp",
      "args": [],
      "disabled": false,
      "env": {
        "OPENAI_API_KEY": "sk-your-key-here",
        "ENABLE_AI": "true",
        "AI_MODEL": "gpt-4o-mini",
        "FORCE_SSH_ONLY": "true"
      },
      "autoApprove": []
    }
  }
}

Environment Variables

Key environment variables:

  • OPENAI_API_KEY — Required when ENABLE_AI=true for AI-powered commit messages

  • ENABLE_AI — Set to true to use AI generation (default: true)

  • AI_MODEL — OpenAI model to use (default: gpt-4o-mini)

  • FORCE_SSH_ONLY — Require SSH for Git operations (default: true)

  • LOG_LEVEL — Logging level: DEBUG, INFO, WARNING, ERROR (default: INFO)

Set in PowerShell:

# Current session
$env:OPENAI_API_KEY = 'sk-your-key-here'

# Persistent (user-level)
setx OPENAI_API_KEY "sk-your-key-here"

Cursor IDE Configuration

Important: Cursor IDE has specific requirements. See the detailed Cursor setup guide in docs/usage.md.

Quick setup for Cursor:

  1. Configuration file location (Windows):

    %APPDATA%\Cursor\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

  2. Basic configuration:

    {
  "mcpServers": {
    "git-commit-mcp": {
      "command": "git-commit-mcp",
      "args": [],
      "env": {
        "OPENAI_API_KEY": "sk-your-key-here",
        "ENABLE_AI": "true"
      }
    }
  }
}

  3. For local development:

    {
  "mcpServers": {
    "git-commit-mcp": {
      "command": "python",
      "args": ["-m", "git_commit_mcp.__main__"],
      "cwd": "C:\\path\\to\\git_commit_message",
      "env": {
        "OPENAI_API_KEY": "sk-your-key-here"
      }
    }
  }
}

Troubleshooting: If you encounter issues in Cursor, see the Cursor-specific troubleshooting section in docs/usage.md.

Usage

Once configured, use natural language with your AI assistant:

User: "Commit my changes"
AI: [Analyzes your git diff and generates a conventional commit message]
AI: "Created commit abc1234: feat(auth): Add user authentication module"

User: "Commit and push"
AI: [Commits and pushes to remote]
AI: "Successfully pushed to origin/main"

The server provides two main tools:

  • generate_commit_message — Generate a commit message without committing

  • git_commit_and_push — Full workflow: analyze, commit, and optionally push

Features

  • AI-Powered Messages: Analyzes actual git diffs to generate accurate commit messages

  • Conventional Commits: Follows the Conventional Commits specification

  • Smart Type Detection: Automatically determines commit type (feat, fix, docs, etc.)

  • Changelog Management: Maintains CHANGELOG.md with commit history

  • Push Confirmation: Requires explicit approval before pushing

  • Multi-Repository: Works with any Git repository, local or remote

Testing

Run the test suite:

# Run all tests
pytest

# Run with coverage
pytest --cov=git_commit_mcp

# Run specific tests
pytest tests/test_integration.py -v

Updating

Update to the latest version:

# Update global installation
pipx upgrade git-commit-mcp-server

# Or from TestPyPI
pipx upgrade git-commit-mcp-server --index-url https://test.pypi.org/simple/ --pip-args="--extra-index-url https://pypi.org/simple/"

Documentation

  • docs/usage.md — Detailed setup, configuration, troubleshooting, and best practices

  • docs/architecture.md — System architecture, components, and design decisions

Contributing

Contributions are welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes with tests

  4. Submit a pull request

License

MIT License - see LICENSE file for details

Links

Available Tools

2 tools
generate_commit_messageA

Analyze changes and generate a Conventional Commit message using AI.

  • For remote repositories, only SSH URLs are allowed.

  • Uses OpenAI gpt-4o-mini (configurable) when ENABLE_AI=true.

  • Falls back to heuristic generator on failure or when AI is disabled.

Returns: { success, commit_message, files_changed, message, error? }

ParametersJSON Schema
NameRequiredDescriptionDefault
repository_pathNo.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: AI model (gpt-4o-mini), configurability via ENABLE_AI, fallback to heuristic, SSH-only constraint, and return format. It does not mention any destructive actions, which is appropriate. The behavioral coverage is good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (about 50 words), well-structured with bullet points, and front-loads the main action. Every sentence adds value, and the return format is clearly outlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no annotations, has output schema) and the described behaviors (AI fallback, SSH constraint), the description is nearly complete. It could explicitly mention the repository_path parameter, but the default '.'' and the context of analyzing changes mitigates this gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% parameter description coverage, and the tool description does not mention the 'repository_path' parameter at all. The agent must infer its purpose (the path to the git repository) from context, which is insufficient for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Analyze changes and generate') and the resource ('a Conventional Commit message'). It distinguishes itself from the sibling tool 'git_commit_and_push' by focusing solely on message generation, implying no commit/push action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to generate a commit message) but does not explicitly contrast with the sibling tool or state when not to use it. It does mention the SSH URL constraint for remote repos, which is helpful context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

git_commit_and_pushA

Track changes, generate commit message, commit, and optionally push.

This tool automates the Git commit workflow by:

  1. Detecting all changes in the repository

  2. Generating a conventional commit message

  3. Staging and committing the changes

  4. Optionally pushing to remote (if confirm_push is True)

  5. Updating the CHANGELOG.md file

Supports both local repositories and remote repository URLs. For remote repositories, the tool will clone them to a workspace and perform operations there.

Args: repository_path: Path to the Git repository or remote URL (default: current directory) Supports: - Local paths: ".", "/path/to/repo", "relative/path" - SSH URLs: "git@github.com:user/repo.git" - HTTPS URLs: "https://github.com/user/repo.git" confirm_push: Whether to push to remote after committing (default: False)

Returns: Dictionary containing commit result information: - success: Whether the operation completed successfully - commit_hash: The SHA hash of the created commit - commit_message: The full commit message used - files_changed: Number of files affected - pushed: Whether the commit was pushed to remote - changelog_updated: Whether CHANGELOG.md was updated - message: Human-readable status message - error: Error message if operation failed

ParametersJSON Schema
NameRequiredDescriptionDefault
confirm_pushNo
repository_pathNo.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and effectively discloses all key behaviors: automated workflow, commit message generation, staging, committing, optional pushing, CHANGELOG.md update, and error handling. No hidden behaviors are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise summary, numbered steps, clear Args and Returns sections, and no redundant information. Every sentence adds value and is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 parameters, output schema, no annotations), the description is complete: it explains the workflow, parameters, return values, and behavior. The output schema details are provided in the description, and the context of the sibling tool is implicitly covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides detailed parameter semantics beyond the schema, especially for 'repository_path' with examples and supported formats. 'confirm_push' is clearly explained with its default value. Since schema had 0% description coverage, the description fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool automates the Git commit workflow including tracking changes, generating commit message, committing, and optionally pushing. It distinguishes from the sibling tool 'generate_commit_message' by covering the full workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool's context and capabilities (local and remote repos, optional push) and implies when to use it, but does not explicitly state when not to use it or contrast with the sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one performs the full commit and push workflow, while the other only generates a commit message. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow the same snake_case convention and use a verb_noun pattern. 'git_commit_and_push' and 'generate_commit_message' are consistent in style.

Tool Count3/5

With only two tools, the server feels minimal but is scoped to git commit operations. It is borderline acceptable; more tools could be added for a richer experience.

Completeness3/5

The server covers commit and push, and commit message generation, but is missing other common git operations like staging/unstaging, viewing status, or undoing commits. Some gaps exist for a complete commit workflow.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Git Workflow MCP Server

    archis17
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI assistants to interact with local Git repositories for operations like status, commits, branching, and diffs, plus GitHub API integration for managing pull requests when authenticated.

  • AutomateHub

    Xesderte
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to automate GitHub repository management, issue tracking, and commits using natural language.
    10
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/surajfale/git-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server