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., "@Gitmoji Commit MCP Create a commit message for adding user login with the appropriate emoji."
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.
A Model Context Protocol (MCP) server for creating, validating, and formatting Git commits following the emoji-enhanced conventional commit standard.
This MCP server provides AI assistants with tools to help developers create well-formatted, meaningful commit messages with emojis. It implements a comprehensive commit convention that combines the clarity of conventional commits with the visual appeal of emojis.
Related MCP server: Cursor Auto-Review MCP Server
Automated Commit Formatting: Generate properly formatted commit messages with correct emojis
Type Suggestions: Analyze staged changes and suggest appropriate commit types
Message Validation: Validate commit messages against convention rules
Git Integration: Seamlessly create commits directly from the tools
TypeScript: Fully typed implementation for reliability
16 Commit Types: Support for primary and extended commit types
npm install -g gitmoji-commit-mcpgit clone <repository-url>
cd gitmoji-commit-mcp
npm install
npm run buildAdd this server to your MCP client configuration:
Edit your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"git-emoji-commit": {
"command": "npx",
"args": ["-y", "gitmoji-commit-mcp"]
}
}
}Or if installed globally:
{
"mcpServers": {
"git-emoji-commit": {
"command": "gitmoji-commit-mcp"
}
}
}VSCode has native MCP support. Edit your VSCode MCP configuration file:
Location: %APPDATA%\Code\User\mcp.json (Windows) or ~/.config/Code/User/mcp.json (macOS/Linux)
{
"servers": {
"gitmoji-commit-mcp": {
"command": "npx",
"args": ["-y", "gitmoji-commit-mcp"]
}
}
}Or if installed globally (via npm install -g or npm link):
{
"servers": {
"gitmoji-commit-mcp": {
"command": "gitmoji-commit-mcp"
}
}
}If you're using the Continue extension for VSCode, add to your Continue configuration:
Location: ~/.continue/config.json (macOS/Linux) or %USERPROFILE%\.continue\config.json (Windows)
{
"mcpServers": {
"git-emoji-commit": {
"command": "npx",
"args": ["-y", "gitmoji-commit-mcp"],
"disabled": false
}
}
}For OpenAI Codex, edit your config file:
Location: ~/.codex/config.toml (macOS/Linux) or %USERPROFILE%\.codex\config.toml (Windows)
[mcp_servers.gitmoji-commit-mcp]
transport = "stdio"
command = "npx"
args = ["-y", "gitmoji-commit-mcp"]
description = "MCP server for creating Git commits with emojis following conventional commit standards"Or if installed globally (via npm install -g or npm link):
[mcp_servers.gitmoji-commit-mcp]
transport = "stdio"
command = "gitmoji-commit-mcp"
description = "MCP server for creating Git commits with emojis following conventional commit standards"For any MCP-compatible client that supports the Model Context Protocol:
{
"servers": {
"git-emoji-commit": {
"type": "stdio",
"command": "npx",
"args": ["-y", "gitmoji-commit-mcp"]
}
}
}Note: Configuration file location and format may vary by client. Refer to your specific MCP client's documentation.
git_format_messageFormat a commit message according to the convention.
Parameters:
type (required): Commit type (feat, fix, docs, etc.)
title (required): Brief description in imperative mood
scope (optional): Context like #123, auth, api
description (optional): Detailed explanation
breaking (optional): Whether this is a breaking change
Example:
{
"type": "feat",
"scope": "auth",
"title": "add OAuth2 authentication",
"description": "Implemented OAuth2 flow with Google and GitHub providers.",
"breaking": false
}Output:
✨ feat(auth): add OAuth2 authentication
Implemented OAuth2 flow with Google and GitHub providers.git_validate_messageValidate a commit message against the convention.
Parameters:
message (required): The commit message to validate
Example:
{
"message": "✨ feat(auth): add OAuth2 authentication"
}Output:
✅ Commit message is valid!git_suggest_typeAnalyze staged changes and suggest an appropriate commit type.
Parameters:
repo_path (optional): Path to the target git repository when MCP server runs outside project directory
Output:
Suggested commit type: ✨ feat
Confidence: high
Reason: Significant additions (245 lines added vs 12 deleted) suggest new feature
Type description: A new featuregit_commitCreate a git commit following the convention.
Parameters: Same as git_format_message, plus:
repo_path (optional): Path to the target git repository when MCP server runs outside project directory
Output:
✅ Commit created successfully!
Commit hash: abc123def456
Message:
✨ feat(auth): add OAuth2 authentication
Implemented OAuth2 flow with Google and GitHub providers.Git tools (git_suggest_type, git_commit) resolve repository context in this order:
repo_path argument from the tool call
MCP request metadata (_meta, if client provides cwd/workspace info)
Environment variables (GITMOJI_REPO_PATH, MCP_REPO_PATH, MCP_WORKSPACE_ROOT, MCP_WORKING_DIR, PROJECT_ROOT, INIT_CWD, PWD)
process.cwd() of the MCP server
If your client starts MCP servers outside your repository, pass repo_path explicitly:
{
"type": "feat",
"title": "add OAuth login",
"repo_path": "C:/Users/Alex/Projects/my-repo"
}Type | Emoji | Description |
| ✨ | A new feature |
| 🐛 | A bug fix |
| 📝 | Documentation only changes |
| 🎨 | Code formatting (no logic change) |
| ♻️ | Code restructuring (no feature/fix) |
| ⚡ | Performance improvements |
| 🧪 | Adding or updating tests |
| 📦 | Build system/dependencies |
| 👷 | CI/CD configuration |
| 🔧 | Maintenance tasks |
| ⏪ | Revert previous commit |
Type | Emoji | Description |
| 🔒 | Security fixes |
| ⚠️ | Deprecation warnings |
| 💥 | Breaking changes |
| 🌐 | Internationalization |
| ♿ | Accessibility improvements |
| ⬆️ | Dependency updates |
<emoji> <type>(<scope>): <title>
<description>Title:
Use imperative mood: "add feature" not "added feature"
Don't capitalize first letter
No period at the end
Maximum 50 characters
Description:
Separate from title with blank line
Wrap at 72 characters
Explain WHAT and WHY, not HOW
User: "I added a new login feature with OAuth"
AI: Let me analyze your changes and create a commit.
[calls git_suggest_type]
This looks like a new feature. I'll create a commit for you.
[calls git_commit with type='feat', scope='auth', title='add OAuth login']
✅ Created commit: feat(auth): add OAuth loginStage your changes:
git add src/auth/*Ask AI to suggest type:
"What type of commit should this be?"Create the commit:
"Create a commit with type feat, scope auth, and title 'add OAuth2 authentication'"gitmoji-commit-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── types.ts # Type definitions and commit types
│ ├── utils.ts # Formatting and validation
│ └── git.ts # Git operations
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdnpm run buildnpm run watchFor local development without publishing to npm:
Build the project:
npm run buildLink globally (creates a symlink to your local development version):
npm linkTest the server:
gitmoji-commit-mcpThe server communicates via stdio and expects MCP protocol messages.
After running npm link, you can use the simplified "installed globally" configuration in all MCP clients (see configuration examples above). The symlink ensures your local changes are reflected immediately after rebuilding - no need to republish or reinstall!
Once configured, Claude can automatically use these tools when you ask questions like:
"Create a commit for my changes"
"What type of commit should this be?"
"Validate my commit message"
"Format a commit for adding authentication"
The Continue extension brings AI assistance directly into VSCode with MCP support. After configuration, you can:
Ask Continue to analyze your staged changes and suggest commit types
Request formatted commit messages directly in the editor
Validate commit messages before committing
Use natural language to create commits: "Commit these changes as a bug fix"
Usage: Press Cmd+L (macOS) or Ctrl+L (Windows/Linux) to open Continue, then interact with the MCP tools.
Any MCP-compatible client can use this server:
Zed Editor: Configure in MCP settings for AI-assisted commits
Custom MCP Clients: Use the stdio transport protocol
API Integrations: Connect via the Model Context Protocol specification
Add it to your client's server configuration with the appropriate command and args. The server uses stdio transport and follows the standard MCP protocol.
The validator checks for:
Required Format: <emoji> <type>(<scope>): <title>
Valid Types: Must be one of the defined commit types
Emoji Match: Emoji must match the commit type
Title Length: Recommended max 50 characters
Title Case: Should start with lowercase
Title Period: Should not end with period
Imperative Mood: Basic check for common mistakes
Description Format: Blank line after title, 72 char lines
The git_suggest_type tool analyzes:
File Types: Documentation, tests, configs, CI files
File Patterns: Build files, dependencies, source code
Change Ratio: Additions vs deletions
Change Volume: Total lines changed
Returns suggestion with confidence level (high/medium/low).
All tools provide clear error messages:
No staged changes for commit
Invalid commit type
Malformed commit message
Git operation failures
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT
For issues, questions, or contributions, please visit the GitHub repository.
Initial release
Four MCP tools: format, validate, suggest, commit
Support for 16 commit types
TypeScript implementation
Git integration with simple-git
Comprehensive validation and formatting
Made with ❤️ for better Git commits
Create a git commit following the emoji-commit convention. Validates staged changes exist, formats the message, and creates the commit.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | The commit type (feat, fix, docs, etc.) | |
| scope | No | Optional scope (e.g., #123, auth, api) | |
| title | Yes | Brief description in imperative mood (50 chars max) | |
| breaking | No | Whether this is a breaking change | |
| repo_path | No | Optional path to the git repository. Use when MCP server runs outside your project directory. | |
| description | No | Optional detailed explanation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It does disclose important behaviors: it validates staged changes, formats the message, and creates the commit. However, it omits other relevant traits such as failure modes, commit hooks, or repository configuration needs, so it provides only partial transparency.
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 only two sentences, front-loaded with the main action. It avoids unnecessary detail and every sentence adds value, even though 'creates the commit' appears twice.
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 tool with 6 parameters and no output schema, the description covers the core purpose and a key prerequisite, but does not explain return values or broader context like repo_path usage. Still, the schema comprehensively documents parameters, so the description is reasonably 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; it does not elaborate on how parameters like 'scope' or 'breaking' are used.
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 the specific action: 'Create a git commit following the emoji-commit convention.' It also names the resource (git commit) and differentiates from sibling tools that only format/validate/suggest messages by emphasizing the creation step: 'creates the commit.'
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 gives clear context by noting the prerequisite of staged changes ('Validates staged changes exist') and the workflow (format then create). However, it does not explicitly mention alternatives like git_format_message or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a commit message according to the git-emoji-commit convention. Takes commit parameters and returns a properly formatted message with emoji.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | The commit type (feat, fix, docs, etc.) | |
| scope | No | Optional scope (e.g., #123, auth, api) | |
| title | Yes | Brief description in imperative mood (50 chars max) | |
| breaking | No | Whether this is a breaking change | |
| description | No | Optional detailed explanation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explicitly states the tool 'returns a properly formatted message,' which implies a pure, side-effect-free operation and no repository mutation. This is adequate for a formatter, though it does not explicitly declare read-only status or error behavior.
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 a single, front-loaded sentence that communicates the core purpose and output without fluff. Every word earns its place, and there is no unnecessary repetition of schema details.
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 pure formatting function, the description covers input ('commit parameters') and output ('properly formatted message with emoji'). Since there is no output schema, this return-value description is sufficient. It omits deep format details, but schema and the convention named provide enough context.
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 100% coverage for all parameters, so the schema already documents meaning. The description adds no extra parameter semantics beyond the generic phrase 'commit parameters,' making the baseline 3 appropriate.
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 the tool 'Format a commit message according to the git-emoji-commit convention' with a specific verb and resource, and clarifies it 'returns a properly formatted message with emoji.' This directly distinguishes it from sibling tools like git_validate_message, git_suggest_type, and git_commit.
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 as a formatter for commit messages but does not explicitly state when to use this tool versus alternatives. It does not name siblings or provide exclusions, leaving the agent to infer the role from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze staged git changes and suggest an appropriate commit type. Returns suggested type with reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | Optional path to the git repository. Use when MCP server runs outside your project directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns a suggested type and reasoning, and 'analyze' implies read-only behavior. However, it doesn't explicitly state that it makes no modifications, nor does it mention any prerequisites like an initialized repository or existing staged changes. This leaves some behavioral traits undisclosed.
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 two concise sentences, front-loaded with the core purpose and followed by the return value. Every word is useful, with no redundancy or irrelevant detail.
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?
The tool is simple with one optional parameter and no output schema. The description covers the main purpose and return value. It could mention that staged changes must exist or that the tool works only in a git repository, but these are minor gaps given the low complexity.
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 100% coverage for the single optional parameter repo_path, so the description doesn't need to add param details. The baseline of 3 applies because the description adds no extra meaning beyond the schema, but it also doesn't need to.
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 the tool's function: analyzing staged git changes and suggesting a commit type. The verb 'suggest' and resource 'staged git changes' are specific, and it distinguishes itself from siblings (format, validate, commit) by focusing on type suggestion.
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 gives clear context: use when you have staged changes and need a commit type suggestion. It doesn't explicitly mention alternatives or exclusions, but the purpose is distinct from sibling tools, and the usage scenario is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a commit message against the git-emoji-commit convention. Returns validation results with any issues or warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The commit message to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return behavior ('Returns validation results with any issues or warnings') but does not detail the result structure, error handling, or whether the operation is read-only. This is minimal but not misleading.
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, consisting of two sentences that are front-loaded with the primary purpose and immediately followed by the result summary. Every word earns its place with no redundancy.
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 a single parameter and no output schema, the description adequately covers purpose and return value. It could mention usage against sibling tools or provide an example result, but given the low complexity, it is sufficiently 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 input schema covers 100% of the parameter descriptions, where the 'message' parameter is described as 'The commit message to validate'. The tool description does not add any additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
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 the specific action ('Validate') and the resource ('a commit message against the git-emoji-commit convention'). This distinguishes it from siblings like git_format_message, git_suggest_type, and git_commit.
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 clear context by specifying the exact convention being validated, making it evident this tool is used for checking commit messages before committing. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1git_commitgit_format_messagegit_suggest_typegit_validate_messageEach tool has a clearly distinct role: formatting, validating, suggesting type, and committing. There is no overlap in their primary purposes, making selection unambiguous.
All tool names follow the same `git_<verb>_<object>` pattern (e.g., git_format_message, git_validate_message). The naming is consistent and predictable.
With only 4 tools, the set is tightly focused on the gitmoji commit workflow. Each tool serves a necessary step without redundancy, making the count appropriate.
The tools cover the entire commit workflow: suggesting a type, formatting a message, validating it, and creating the commit. No obvious missing operation within the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
Create, deploy, and operate MCP servers directly from your GitHub repositories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AleksandrSemykin/gitmoji-commit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
