MCP Git Commit Generator
The MCP Git Commit Generator server automates conventional commit message generation and Git repository management by analyzing staged changes.
Core Functions:
Generate conventional commit messages: Analyzes staged Git changes and creates detailed prompts for LLMs to generate conventional commit messages, with auto-detection or manual specification of commit type (feat, fix, docs) and scope
Check git repository status: Provides comprehensive repository state overview, including staged, unstaged, and untracked files
Key Features:
Cross-platform support (macOS, Linux, Windows)
Multiple transport options (stdio, SSE)
Docker integration with pre-built images
Interactive debugging with Inspector UI
Robust error handling and repository path validation
Customizable configurations with flexible commit type and scope options
Provides tools for generating conventional commit messages from staged git changes and checking repository status
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Git Commit Generatorgenerate a commit message for my staged changes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Git Commit Generator
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:
Option 1: Using uvx (Recommended)
The easiest way to use the package is with uvx, which automatically manages the virtual environment:
uvx mcp-git-commit-generatorOption 2: Install from PyPI
pip install mcp-git-commit-generatorOr with uv:
uv pip install mcp-git-commit-generatorOption 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:
Stage your changes:
git add <files>Use the tool through your MCP client to generate a commit message
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:
Using uvx (recommended - automatically manages dependencies)
Using Docker (no local Python installation required)
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):
Using uvx (Recommended)
{
"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):
Cursor with uvx (Recommended)
{
"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):
Windsurf with uvx (Recommended)
{
"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):
Claude Desktop with uvx (Recommended)
{
"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
--mountoption 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
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-generatorDocker: Use the configurations above with Docker
Configure your MCP client using one of the configurations above
Stage some changes in a git repository:
git add <files>Use the tools through your MCP client:
Use
check_git_statusto see your current repository stateUse
generate_commit_messageto create a conventional commit message
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:
Python >= 3.13.5
uv (recommended for dependency management and local development)
Node.js (for Inspector UI, optional)
Python Debugger Extension (for debugging, optional)
Note: The MCP CLI dependency is automatically installed via
uv.lockwhen usinguv sync.
Installation:
Clone the repository:
git clone https://github.com/theoklitosBam7/mcp-git-commit-generator.git cd mcp-git-commit-generatorPrepare 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 dev2. Run VSCode Command "Python: Select Interpreter" and select the python from.venvdirectory 3. The project is installed in editable mode automatically byuv sync.Using
pip1. Create virtual environment:
python -m venv .venv2. 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.(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 mainBuilds: Python package distributions using the
buildpackagePublishes: Automatically publishes to PyPI using trusted publishing (OIDC) when tags are pushed
To publish a new version:
Update the version in
pyproject.tomlCreate and push a git tag:
git tag vX.Y.Z && git push origin vX.Y.ZThe 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:latestBy default, the container runs:
mcp-git-commit-generator --transport stdioIf 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 3001The server will be available at http://localhost:3001 when using SSE.
๐ฅ๏ธ Running the Server Locally
To run locally (without Docker):
Set up your uv or Python environment as described in the Local Development Setup section.
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 sseuv run -m mcp_git_commit_generator --transport sse# Default stdio transport
mcp-git-commit-generator
# With SSE transport
mcp-git-commit-generator --transport ssepython -m mcp_git_commit_generator --transport sseYou can specify other options, for example:
python -m mcp_git_commit_generator --transport sse --host 0.0.0.0 --port 3001 -vThe server listens on
0.0.0.0:3001by 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:inspectorThe 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.pyTest 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: |
โ๏ธ Default Ports and Customizations
Debug Mode | Ports | Definitions | Customizations | Note |
MCP Inspector | 3001 (Server, SSE only); 5173 and 3000 (Inspector) | 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
.gitfolder"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 -vto verify your installation (recommended)Or run
pytest -vif using pip
๐ License
MIT License ยฉ 2025 Theoklitos Bampouris
Available Tools
2 toolscheck_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
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | ||
| commit_type | No | ||
| scope | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
- First observed
check_git_status - First observed
generate_commit_message
TDQS
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.
Both tool names follow a consistent verb_noun pattern using snake_case (check_git_status, generate_commit_message), which is predictable and clear.
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.
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
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
- ShipstarOAuthai.shipstar
Generate and publish changelogs, blog posts, release emails, and social posts from your commits.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Pre-commit code quality guardian. Detects semantic drift in AI-generated code.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceAnalyzes git changes in repositories and generates conventional commit messages using OpenAI's GPT models, supporting both staged and unstaged changes with detailed summaries.2715MIT
- AlicenseNot gradedqualityNot gradedmaintenanceAnalyzes git repository changes to generate conventional commit messages and summaries using OpenAI's GPT-4o-mini. It provides detailed tracking of modified, added, and deleted files to streamline the version control process.27-
- AlicenseAqualityDmaintenanceAnalyzes Git repository changes and generates conventional, context-aware commit messages using the Model Context Protocol.15MIT
- AlicenseAqualityCmaintenanceGenerates commit messages, PR titles and descriptions, and release notes from git changes, with automatic domain detection for appropriate PR templates.10141MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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