Skip to main content
Glama
theoklitosBam7

MCP Git Commit Generator

MCP Git Commit Generator

PyPI GitHub Release Publish Python ๐Ÿ package to PyPI Create and Publish Docker ๐Ÿณ image License

Generate conventional commit messages from your staged git changes using Model Context Protocol (MCP).

โœจ Features

  • ๐Ÿค– Automatic commit message generation based on staged git diffs

  • ๐Ÿ“ Conventional Commits support with auto-detection of type and scope

  • ๐Ÿ”„ Multiple transport options - stdio (default) and SSE for different use cases

  • ๐Ÿ” Inspector UI for interactive testing and debugging

  • ๐Ÿณ Docker support with pre-built images for easy deployment

  • โšก Cross-platform - works on macOS, Linux, and Windows

Related MCP server: git-auto-commit

๐Ÿ“ฆ Requirements

  • For Docker usage: Docker (for running the server in a container)

  • For PyPI/uvx usage: Python >= 3.13.5 and uv (recommended) or pip

  • Git (for version control)

  • An MCP-compatible client (VS Code with MCP extension, Claude Desktop, Cursor, Windsurf, etc.)

๐Ÿš€ Installation

You can install and use the MCP Git Commit Generator in multiple ways:

The easiest way to use the package is with uvx, which automatically manages the virtual environment:

uvx mcp-git-commit-generator

Option 2: Install from PyPI

pip install mcp-git-commit-generator

Or with uv:

uv pip install mcp-git-commit-generator

Option 3: Using Docker

Use the pre-built Docker image from GitHub Container Registry (no installation required):

docker run -i --rm --mount type=bind,src=${HOME},dst=${HOME} ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest

๐Ÿ› ๏ธ Available Tools

This MCP server provides the following tools to help you generate conventional commit messages:

generate_commit_message

Generates a conventional commit message based on your staged git changes.

Parameters:

  • repo_path (string, optional): Path to the git repository. If omitted, uses the current directory.

  • commit_type (string, optional): Conventional commit type (e.g., feat, fix, docs, style, refactor, perf, build, ci, test, chore, revert). If omitted, the type will be auto-detected.

  • scope (string, optional): Scope of the change (e.g., file or module name). If omitted, the scope will be auto-detected based on changed files.

Usage:

  1. Stage your changes: git add <files>

  2. Use the tool through your MCP client to generate a commit message

  3. The tool will analyze your staged changes and generate an appropriate conventional commit message

check_git_status

Checks the current git repository status, including staged, unstaged, and untracked files.

Parameters:

  • repo_path (string, optional): Path to the git repository. If omitted, uses the current directory.

Usage:

Use this tool to get an overview of your current git repository state before generating commit messages.

๐Ÿงฉ MCP Client Configuration

Configure the MCP Git Commit Generator in your favorite MCP client. You have multiple options:

  1. Using uvx (recommended - automatically manages dependencies)

  2. Using Docker (no local Python installation required)

  3. Using local Python installation (for development)

VS Code

Add one of the following configurations to your VS Code mcp.json file (usually located at .vscode/mcp.json in your workspace):

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

Using Docker

{
  "servers": {
    "mcp-git-commit-generator": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--mount",
        "type=bind,src=${userHome},dst=${userHome}",
        "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest"
      ]
    }
  }
}

If you want to put the configuration in your user settings.json file, you can do so by adding:

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

Cursor

Add one of the following to your Cursor MCP configuration file (usually located at ~/.cursor/mcp.json):

{
  "mcpServers": {
    "mcp-git-commit-generator": {
      "command": "uvx",
      "args": ["mcp-git-commit-generator"]
    }
  }
}

Cursor with Docker

{
  "mcpServers": {
    "mcp-git-commit-generator": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--mount",
        "type=bind,src=${userHome},dst=${userHome}",
        "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest"
      ]
    }
  }
}

Windsurf

Configure Windsurf with one of the following MCP server settings (usually located at ~/.codeium/windsurf/mcp_config.json):

{
    "mcpServers": {
      "mcp-git-commit-generator": {
        "command": "uvx",
        "args": ["mcp-git-commit-generator"]
      }
    }
}

Windsurf with Docker

{
    "mcpServers": {
      "mcp-git-commit-generator": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "--mount",
          "type=bind,src=${userHome},dst=${userHome}",
          "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest"
        ]
      }
    }
}

Claude Desktop

Add one of the following to your Claude Desktop configuration file (usually located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "mcp-git-commit-generator": {
      "command": "uvx",
      "args": ["mcp-git-commit-generator"]
    }
  }
}

Claude Desktop with Docker

{
  "mcpServers": {
    "mcp-git-commit-generator": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--mount",
        "type=bind,src=${userHome},dst=${userHome}",
        "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest"
      ]
    }
  }
}

Note: The --mount option in Docker configurations allows the Docker container to access your home directory, enabling it to work with git repositories located anywhere in your file system. When using uvx or pip installations, this mounting is not needed as the tool runs directly on your system. Adjust the mount path if your repositories are located elsewhere when using Docker.

๐Ÿš€ Quick Start Guide

  1. Install the package using one of the methods above:

    • Recommended: uvx mcp-git-commit-generator (or configure in your MCP client)

    • Alternative: pip install mcp-git-commit-generator

    • Docker: Use the configurations above with Docker

  2. Configure your MCP client using one of the configurations above

  3. Stage some changes in a git repository:

    git add <files>
  4. Use the tools through your MCP client:

    • Use check_git_status to see your current repository state

    • Use generate_commit_message to create a conventional commit message

  5. Commit your changes with the generated message


๐Ÿ‘จโ€๐Ÿ’ป Developer Guidelines

The following sections are intended for developers who want to contribute to or modify the MCP Git Commit Generator.

Local Development Setup ๐Ÿ› ๏ธ

If you prefer not to use Docker for development, you can run the server locally:

Requirements:

Note: The MCP CLI dependency is automatically installed via uv.lock when using uv sync.

Installation:

  1. Clone the repository:

    git clone https://github.com/theoklitosBam7/mcp-git-commit-generator.git
    cd mcp-git-commit-generator
  2. Prepare environment:

    There are two approaches to set up the environment for this project. You can choose either one based on your preference.

    Note: Reload VSCode or terminal to ensure the virtual environment python is used after creating the virtual environment.

    Approach

    Steps

    Using uv (Recommended)

    1. Create virtual environment and install dependencies: uv sync --group dev 2. Run VSCode Command "Python: Select Interpreter" and select the python from .venv directory 3. The project is installed in editable mode automatically by uv sync.

    Using pip

    1. Create virtual environment: python -m venv .venv 2. Run VSCode Command "Python: Select Interpreter" and select the python from created virtual environment 3. Install dependencies: pip install -e .. 4. Install pip dev dependencies: pip install -r requirements-dev.txt.

  3. (Optional) Install Inspector dependencies:

    cd inspector
    npm install

๐Ÿ“ฆ Publishing to PyPI

The project includes an automated PyPI publishing workflow (.github/workflows/pypi-publish.yml) that:

  • Triggers on: Tag pushes matching v*.*.* pattern, manual workflow dispatch, or pull requests to main

  • Builds: Python package distributions using the build package

  • Publishes: Automatically publishes to PyPI using trusted publishing (OIDC) when tags are pushed

To publish a new version:

  1. Update the version in pyproject.toml

  2. Create and push a git tag: git tag vX.Y.Z && git push origin vX.Y.Z

  3. The workflow will automatically build and publish to PyPI

๐Ÿณ Building and Running with Docker

You can build and run the MCP Git Commit Generator using Docker. The provided Dockerfile uses a multi-stage build with uv for dependency management and runs the server as a non-root user for security.

Build the Docker image

docker build -t mcp-git-commit-generator .

Run the server in a container (default: stdio transport)

You can run the published image directly from GitHub Container Registry.

docker run -d \
  --name mcp-git-commit-generator \
  ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest

By default, the container runs:

mcp-git-commit-generator --transport stdio

If you want to use SSE transport (for Inspector UI or remote access), override the entrypoint or run manually:

docker run -d \
  --name mcp-git-commit-generator \
  -p 3001:3001 \
  --entrypoint mcp-git-commit-generator \
  ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest --transport sse --host 0.0.0.0 --port 3001

The server will be available at http://localhost:3001 when using SSE.

๐Ÿ–ฅ๏ธ Running the Server Locally

To run locally (without Docker):

  1. Set up your uv or Python environment as described in the Local Development Setup section.

  2. From the project root, run:

# Run with uv (uses uv.lock for consistent dependencies)
uv run mcp-git-commit-generator

# Or with SSE transport
uv run mcp-git-commit-generator --transport sse
uv run -m mcp_git_commit_generator --transport sse
# Default stdio transport
mcp-git-commit-generator

# With SSE transport
mcp-git-commit-generator --transport sse
python -m mcp_git_commit_generator --transport sse

You can specify other options, for example:

python -m mcp_git_commit_generator --transport sse --host 0.0.0.0 --port 3001 -v

The server listens on 0.0.0.0:3001 by default when using SSE, or as specified by the options above.

Note:

  • If you want to use the CLI entrypoint, ensure the package is installed and your environment is activated.

  • Do not use positional arguments (e.g., python -m mcp_git_commit_generator sse); always use options like --transport sse.

  • Available arguments with their values are:

    • --transport: Transport type (e.g., stdio (default), sse).

    • --host: Host to bind the server (default: 0.0.0.0).

    • --port: Port to bind the server (default: 3001).

    • -v, --verbose: Verbosity level (e.g., -v, -vv).

๐Ÿ”Ž Start the Inspector UI

From the inspector directory:

npm run dev:inspector

The Inspector UI will be available at http://localhost:5173.

๐Ÿงช Running Tests

The project includes comprehensive unit tests to ensure reliability:

# Run all tests (recommended when using uv)
uv run pytest

# Or using pytest directly
pytest

# Run tests with verbose output
uv run pytest -v

# Run tests with coverage
uv run pytest --cov=src/mcp_git_commit_generator

# Run specific test file
uv run pytest tests/test_server.py

Test Coverage:

  • โœ… Tool validation with invalid repository paths

  • โœ… Staged and unstaged change detection

  • โœ… Git status reporting

  • โœ… Commit message generation workflows

  • โœ… Error handling for git command failures

๐Ÿ—‚๏ธ Project Structure

.
โ”œโ”€โ”€ .github/                # GitHub workflows and issue templates
โ”œโ”€โ”€ .gitignore
โ”œโ”€โ”€ .markdownlint.jsonc
โ”œโ”€โ”€ .python-version
โ”œโ”€โ”€ .vscode/                # VSCode configuration
โ”œโ”€โ”€ LICENSE
โ”œโ”€โ”€ README.md
โ”œโ”€โ”€ pyproject.toml          # Python project configuration
โ”œโ”€โ”€ requirements-dev.txt    # Development dependencies (for pip users)
โ”œโ”€โ”€ uv.lock                 # Dependency lock file for reproducible builds (used by uv sync)
โ”œโ”€โ”€ Dockerfile              # Docker build file
โ”œโ”€โ”€ build/                  # Build artifacts
โ”œโ”€โ”€ src/                    # Python source code
โ”‚   โ””โ”€โ”€ mcp_git_commit_generator/
โ”‚       โ”œโ”€โ”€ __init__.py     # Main entry point
โ”‚       โ”œโ”€โ”€ __main__.py     # CLI entry point
โ”‚       โ””โ”€โ”€ server.py       # Main server implementation
โ””โ”€โ”€ inspector/              # Inspector related files
    โ”œโ”€โ”€ package.json        # Node.js dependencies
    โ””โ”€โ”€ package-lock.json

โš™๏ธ Advanced MCP Server Configuration for Development

The .vscode/mcp.json file configures how VS Code and related tools connect to your MCP Git Commit Generator server. This file defines available server transports and their connection details, making it easy to switch between different modes (stdio is default, SSE is optional) for development and debugging.

Example Development mcp.json

{
  "servers": {
    "mcp-git-commit-generator": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--mount",
        "type=bind,src=${userHome},dst=${userHome}",
        "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest"
      ]
    },
    "sse-mcp-git-commit-generator": {
      "type": "sse",
      "url": "http://localhost:3001/sse"
    },
    "stdio-mcp-git-commit-generator": {
      "type": "stdio",
      "command": "${command:python.interpreterPath}",
      "args": ["-m", "mcp_git_commit_generator", "--transport", "stdio"]
    },
    "uvx-mcp-git-commit-generator": {
      "command": "uvx",
      "args": ["mcp-git-commit-generator"]
    }
  }
}
  • mcp-git-commit-generator: Runs the server in a Docker container (default: stdio transport), using the published image.

  • sse-mcp-git-commit-generator: Connects to the MCP server using Server-Sent Events (SSE) at http://localhost:3001/sse. Only useful if you run the server with --transport sse.

  • stdio-mcp-git-commit-generator: Connects using standard input/output (stdio), running the server as a subprocess. This is the default and recommended for local development and debugging.

  • uvx-mcp-git-commit-generator: Uses uvx to automatically install and run the package from PyPI.

๐Ÿž Debugging the MCP Server

Notes:

  • MCP Inspector is a visual developer tool for testing and debugging MCP servers.

  • All debugging modes support breakpoints, so you can add breakpoints to the tool implementation code.

  • You can test tool arguments directly in the Inspector UI: When using the Inspector, select a tool and provide arguments in the input fields to simulate real usage and debug argument handling.

Debug Mode

Description

Steps to debug

MCP Inspector

Debug the MCP server using the MCP Inspector.

1. Install Node.js 2. Set up Inspector: cd inspector && npm install 3. Open VS Code Debug panel. Select Debug in Inspector (Edge) or Debug in Inspector (Chrome). Press F5 to start debugging. 4. When MCP Inspector launches in the browser, click the Connect button to connect this MCP server. 5. Then you can List Tools, select a tool, input parameters (see arguments above), and Run Tool to debug your server code.

โš™๏ธ Default Ports and Customizations

Debug Mode

Ports

Definitions

Customizations

Note

MCP Inspector

3001 (Server, SSE only); 5173 and 3000 (Inspector)

tasks.json

Edit launch.json, tasks.json, __init__.py, mcp.json to change above ports.

N/A

๐Ÿ’ฌ Feedback

If you have any feedback or suggestions, please open an issue on the MCP Git Commit Generator GitHub repository

๐Ÿ“– Troubleshooting

Common Issues

  • "Path is not a valid git repository": Ensure you're in a directory with a .git folder

  • "No staged changes found": Run git add <files> to stage your changes first

  • "Git is not installed": Install Git from git-scm.com

  • Docker permission issues: Ensure Docker can access your home directory

  • MCP connection fails: Verify your client configuration matches the examples above

Getting Help

  • Check the Issues page for solutions

  • Use the Inspector UI for interactive debugging

  • Run uv run pytest -v to verify your installation (recommended)

  • Or run pytest -v if using pip

๐Ÿ“„ License

MIT License ยฉ 2025 Theoklitos Bampouris

Available Tools

2 tools
check_git_statusA

Check the current git repository status.

Args: repo_path: Optional path to the target git repository. If not provided, uses the current working directory.

Returns: Current git status including staged, unstaged, and untracked files

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It mentions the return includes staged, unstaged, and untracked files, but does not cover potential issues like missing git repo or side effects. It is adequate but not thorough.

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, front-loaded with the main purpose, and uses a clear Args/Returns structure with no wasted words.

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?

For a simple tool with one optional parameter, the description covers the key aspects. It mentions return contents, but does not elaborate on output format. Given the tool's simplicity and presence of an output schema, it is nearly complete.

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

Parameters4/5

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

The schema has 0% description coverage, so the description must add meaning. It explains the optional repo_path parameter and its default behavior, providing clear semantics beyond the schema.

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 'Check the current git repository status,' which is a specific verb and resource. The sibling tool 'generate_commit_message' is distinct, so no confusion.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives or when not to use it. It simply describes the action.

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

generate_commit_messageA

Prepare a structured analysis and instruction block for generating a Conventional Commit message from staged git changes only.

Behavior: - Validates the repository path and operates on the provided repo or CWD. - Collects staged diff, porcelain status, and a name-status summary. - Incorporates optional user preferences for commit_type and scope. - Returns a single formatted string that includes context plus strict output instructions for an LLM to produce a Conventional Commit.

Args: repo_path: Optional path to the target git repository. If not provided, uses the current working directory. commit_type: Optional commit type (feat, fix, docs, style, refactor, perf, build, ci, test, chore, revert) scope: Optional scope of the change

Returns: A formatted prompt containing git change context and clear output rules for generating a Conventional Commit message

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathNo
commit_typeNo
scopeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

The description details validation, data collection (staged diff, porcelain, name-status), incorporation of user preferences, and output format. Since no annotations are provided, the description adequately covers behavioral traits.

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 clear sections for behavior and args, front-loads the purpose, and uses concise bullet points without unnecessary words.

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 optional parameters and presence of output schema, the description covers purpose, behavior, and parameter semantics adequately, though it could briefly mention that the output is a string.

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

Parameters4/5

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

With 0% schema description coverage, the description adds meaning by explaining each parameter's role: repo_path defaults to CWD, commit_type lists allowed types, and scope describes change scope, compensating for schema gaps.

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 it prepares a structured analysis and instruction block for generating a Conventional Commit message from staged git changes, with specific verb and resource, and distinguishes from sibling check_git_status.

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 usage for generating commit messages but does not explicitly state when to use this tool versus the sibling check_git_status or provide guidance on prerequisites or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedcheck_git_status
    • First observedgenerate_commit_message

TDQS

A4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one checks git status, the other generates a commit message prompt. There is no overlap in functionality, making them easy to distinguish.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern using snake_case (check_git_status, generate_commit_message), which is predictable and clear.

Tool Count3/5

With only two tools, the server feels thin. While it covers checking status and generating commit messages, the narrow scope makes it borderline acceptable for its stated purpose.

Completeness4/5

The generate_commit_message tool bundles diff collection and prompt construction, but a separate tool to inspect staged changes directly could be useful. Still, the core workflow is covered without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

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/theoklitosBam7/mcp-git-commit-generator'

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