Which integrations are available for this server?

Provides integration with MGit, a command-line tool for managing multiple Git repositories, enabling batch push operations with commit messages across multiple Git projects simultaneously.

How do I use MCP MGit Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP MGit Server push my latest changes to the main repository" 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 MGit Server

by liliangshan

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

MCP MGit Server

A MCP server for executing mgit push operations with multiple instance support.

Prerequisites

⚠️ Important: This MCP server requires the MGit tool to be installed and configured on your system.

MGit is a command-line tool for managing multiple Git projects. It helps you efficiently manage, synchronize, and update multiple Git repositories.

MGit Installation and Setup

Before using this MCP server, please:

Install MGit: Download and install MGit from https://github.com/liliangshan/mgit/releases
Initialize MGit: Follow the MGit setup instructions in the MGit README
Configure Projects: Use mgit init to add your Git repositories to MGit
Verify Setup: Use mgit list to view available repository names

For detailed MGit usage instructions, features, and configuration, please refer to the MGit README.

Key MGit Features

Multi-project Management: Manage multiple Git projects with one click
Multi-language Support: Supports multiple languages including Chinese (Simplified/Traditional), English, Japanese, Korean, French
Remote Database Sync: Supports project configuration synchronization across multiple devices
Smart Branch Management: Automatically detects and switches branches to avoid conflicts
Batch Operations: Supports pulling/pushing changes for multiple projects simultaneously

Related MCP server: Git MCP Server

Features

✅ Execute mgit push command for repositories
✅ Configurable mgit command (default: mgit)
✅ Multiple instance support with repository name isolation
✅ Operation logging
✅ Error handling and recovery

Installation

Global Installation (Recommended)

npm install -g @liangshanli/mcp-server-mgit

Local Installation

npm install @liangshanli/mcp-server-mgit

From Source

git clone https://github.com/liliangshan/mcp-server-mgit.git
cd mcp-server-mgit
npm install

Configuration

Set environment variables:

# Required: Repository name (use 'mgit list' to view available repository names)
export REPO_NAME="my-repo"

# Optional: MGit command (default: mgit)
export MGIT_CMD="mgit"

# Optional: Language setting (default: en)
# Supported values: en (English), zh (Chinese), zh-CN (Simplified Chinese), zh-TW (Traditional Chinese)
export LANGUAGE="en"

# Optional: Enable/disable push history check (default: true)
# Set to false to skip history check requirement
export CHECK_PUSH_HISTORY="true"

# Optional: Project branding
export PROJECT_NAME="MyProject"

Usage

1. Direct Run (Global Installation)

mcp-server-mgit

2. Using npx (Recommended)

npx @liangshanli/mcp-server-mgit

3. Direct Start (Source Installation)

npm start

4. Managed Start (Recommended for Production)

npm run start-managed

Managed start provides:

Auto-restart (up to 10 times)
Error recovery
Process management
Logging

5. Development Mode

npm run dev

Editor Integration

Cursor Editor Configuration

Create .cursor/mcp.json file in your project root:

{
  "mcpServers": {
    "mgit": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mgit"],
      "env": {
        "REPO_NAME": "my-repo",
        "MGIT_CMD": "mgit",
        "LANGUAGE": "en",
        "PROJECT_NAME": "MyProject"
      }
    }
  }
}

VS Code Configuration

Install the MCP extension for VS Code
Create .vscode/settings.json file:

{
  "mcp.servers": {
    "mgit": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mgit"],
      "env": {
        "REPO_NAME": "my-repo",
        "MGIT_CMD": "mgit",
        "LANGUAGE": "en",
        "PROJECT_NAME": "MyProject"
      }
    }
  }
}

Multiple MGit Server Instances Support

You can configure multiple MGit server instances with different REPO_NAME and PROJECT_NAME to isolate tools and configurations. Each instance must have a unique REPO_NAME (required). This is useful when you need to push to different repositories or manage different project groups. Use mgit list (or ${MGIT_CMD} list) to view available repository names.

Example: Cursor Editor Configuration

Create .cursor/mcp.json file:

{
  "mcpServers": {
    "mgit-local": {
      "disabled": false,
      "timeout": 60,
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mgit"],
      "env": {
        "REPO_NAME": "local-repo",
        "MGIT_CMD": "mgit",
        "PROJECT_NAME": "local-mgit"
      }
    },
    "mgit-custom": {
      "disabled": false,
      "timeout": 60,
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mgit"],
      "env": {
        "REPO_NAME": "custom-repo",
        "MGIT_CMD": "/path/to/custom-mgit",
        "PROJECT_NAME": "custom-mgit"
      }
    }
  }
}

Benefits of Multiple Instances:

Tool Isolation: Each instance has its own tool names (e.g., local_mgit_push, custom_mgit_push)
Config Isolation: Logs are stored in separate directories (e.g., ./.setting.local/, ./.setting.custom/)
Different Commands: Configure different mgit commands for each instance
Project Branding: Each instance can have its own project name for better identification

Note: When using multiple instances, tools will be prefixed with REPO_NAME. For example:

local-repo_mgit_push - uses local mgit command for local-repo
custom-repo_mgit_push - uses custom mgit command for custom-repo

As MCP Server

The server communicates with MCP clients via stdin/stdout after startup:

{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2025-06-18"}}

Available Tools

mgit_push: Execute mgit push command for the repository configured via REPO_NAME environment variable

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "mgit_push",
    "arguments": {
      "message": "Update project files"
    }
  }
}

get_operation_logs: Get operation logs

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_operation_logs",
    "arguments": {
      "limit": 50,
      "offset": 0
    }
  }
}

Logging

General Logs

Log file location: ./.setting/mcp-mgit.log (or ./.setting.<REPO_NAME>/mcp-mgit.log if REPO_NAME is set)

Logged content:

All requests and responses
MGit operation records
Error messages
Server status changes

Error Handling

Individual request errors don't affect the entire server
Process exceptions are automatically restarted (managed mode)
Detailed error messages in logs

Environment Variables

Variable	Default	Description
REPO_NAME		Required repository name for push operations. Use `mgit list` (or `${MGIT_CMD} list`) to view available repository names. Example: `export REPO_NAME="my-repo"`
MGIT_CMD	mgit	Optional mgit command to execute (can be full path)
LANGUAGE	en	Optional language setting for commit messages. Supported values: `en` (English), `zh` or `zh-CN` (Simplified Chinese), `zh-TW` (Traditional Chinese). The tool will prompt users to provide commit messages in the configured language.
CHECK_PUSH_HISTORY	true	Optional flag to enable/disable push history check before pushing. Set to `false` to skip the history check requirement. When `true` (default), you must call `get_push_history` tool before using `mgit_push`. When `false`, you can push directly without checking history. Note: If you encounter the error `Encountered error in step execution: error executing cascade step: CORTEX_STEP_TYPE_MCP_TOOL: calling "tools/call": EOF`, please set `CHECK_PUSH_HISTORY="false"` to disable push history check.
PROJECT_NAME		Optional project branding for tool descriptions
MCP_LOG_DIR	./.setting (or ./.setting. if REPO_NAME is set)	Log directory
MCP_LOG_FILE	mcp-mgit.log	Log filename

Development

Project Structure

mcp-server-mgit/
├── src/
│   └── server-final.js    # Main server file
├── bin/
│   └── cli.js              # CLI entry point
├── start-server.js         # Managed startup script
├── package.json
└── README.md

Testing

npm test

Quick Start

1. Install Package

npm install -g @liangshanli/mcp-server-mgit

2. Configure Environment Variables

# Required: Repository name
export REPO_NAME="my-repo"

# Optional: MGit command (default: mgit)
export MGIT_CMD="mgit"

# Optional: Language setting (default: en)
export LANGUAGE="en"

# Optional: Enable/disable push history check (default: true)
# Set to false to skip history check requirement
export CHECK_PUSH_HISTORY="true"

# Optional: Project branding
export PROJECT_NAME="MyProject"

3. Run Server

mcp-server-mgit

Usage Example

Using the mgit_push tool

The mgit_push tool executes the command: ${MGIT_CMD} push ${REPO_NAME} "<message>"

Note: The repository name is configured via the REPO_NAME environment variable (required). Use mgit list (or ${MGIT_CMD} list) to view available repository names.

Parameters:

message (required): The commit message for the push operation

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "mgit_push",
    "arguments": {
      "message": "Update documentation"
    }
  }
}

If REPO_NAME="my-project" and MGIT_CMD="mgit", this will execute: mgit push my-project "Update documentation"

Troubleshooting

Error: `Encountered error in step execution: error executing cascade step: CORTEX_STEP_TYPE_MCP_TOOL: calling "tools/call": EOF`

If you encounter this error when trying to push code, it may be caused by the push history check feature. To resolve this issue, disable the push history check by setting the environment variable:

export CHECK_PUSH_HISTORY="false"

After setting this variable, restart the MCP server and try pushing again. This will allow you to push directly without checking push history first.

License

MIT

Available Tools

3 tools

my-project-repo_get_operation_logsC

[My Awesome Project] Get operation logs

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Limit count, default 50
`offset`	No	Offset, default 0

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('Get operation logs') without describing what the logs contain, their format, whether this is a read-only operation, potential rate limits, authentication requirements, or what happens when parameters are omitted. For a tool with no annotation coverage, this is insufficient behavioral context.

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

Conciseness4/5

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

The description is extremely concise at just 5 words, which is appropriately sized for a simple retrieval tool. However, it's arguably too brief given the lack of behavioral context needed when annotations are absent. The structure is front-loaded with the core purpose but lacks supporting details.

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

Completeness2/5

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

Given no annotations, no output schema, and a description that only states the basic purpose, this is incomplete for effective tool usage. The agent needs to know what 'operation logs' contain, their format, how they differ from push history, and what the tool returns. The description doesn't compensate for the lack of structured metadata.

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

Parameters3/5

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

The input schema has 100% description coverage with clear documentation of both parameters (limit and offset). The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

Purpose3/5

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

The description states the tool's purpose as 'Get operation logs' which is a clear verb+resource combination. However, it doesn't specify what 'operation logs' contain or distinguish this from sibling tools like 'get_push_history' which likely retrieves similar historical data. The description is vague about the specific scope of operations being logged.

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. There's no mention of when this should be used instead of 'get_push_history' or 'mgit_push', nor any context about what types of operations are included in these logs versus push history. The agent receives no usage differentiation.

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

my-project-repo_get_push_historyA

[My Awesome Project] Get the last 5 push history records for repository "my-project-repo". This tool MUST be called before using mgit_push to ensure the current changes have not been pushed before. After calling this tool, you can proceed with mgit_push.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 carries the full burden. It describes the tool's behavior as retrieving 'the last 5 push history records', which implies a read-only operation, but does not disclose other behavioral traits such as error handling, rate limits, or authentication needs. The description adds some context about its role in a workflow but lacks details on operational constraints.

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

Conciseness3/5

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

The description is three sentences long. The first sentence clearly states the purpose, but the second and third sentences are somewhat repetitive in emphasizing the tool's mandatory use before mgit_push. While front-loaded with key information, it could be more concise by combining the usage instructions into a single, streamlined sentence.

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

Completeness3/5

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

Given the tool's complexity (simple read operation with no parameters) and lack of annotations or output schema, the description is moderately complete. It explains the purpose and usage guidelines well but omits details on output format, error cases, or other behavioral aspects. For a tool with no structured data support, it provides a basic but incomplete picture.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information beyond the schema, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the description compensates by explaining the tool's fixed scope ('last 5' records) without needing to detail parameters.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Get the last 5 push history records for repository "my-project-repo"'. It specifies the verb ('Get'), resource ('push history records'), and scope ('last 5'), but does not explicitly differentiate from sibling tools like 'my-project-repo_get_operation_logs', which might also retrieve logs but for different types of operations.

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

Usage Guidelines5/5

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

The description provides explicit usage guidelines: 'This tool MUST be called before using mgit_push to ensure the current changes have not been pushed before. After calling this tool, you can proceed with mgit_push.' It clearly states when to use it (before mgit_push) and references an alternative (mgit_push) for the next step, offering strong guidance on workflow integration.

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

my-project-repo_mgit_pushA

[My Awesome Project] Execute mgit push command for repository "my-project-repo" with a commit message.

IMPORTANT:

You MUST call get_push_history tool FIRST to view the last 5 push records before using this tool
Confirm that the changes in this push have not been pushed before, otherwise modify the push message and push again
The repository name is configured via REPO_NAME environment variable
Language setting: en (default: en)
Push history check is enabled (CHECK_PUSH_HISTORY=true). You must review push history before pushing.

USAGE:

First call get_push_history to view recent push records
Then call this tool with the commit message parameter. Example: {message: "Update project files"}

Please provide the commit message in English language.

NOTE: If the push result contains a branch merge URL (such as a pull request URL), please output it to the user. If you can open a browser, you may also automatically open the URL.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Commit message in English language. Example: {message: "Update project files"}

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the requirement to check push history first, the repository configuration via environment variable, language settings, and what to do with output (e.g., handling branch merge URLs). However, it doesn't mention potential side effects like overwriting data or error conditions, which would be helpful for a push operation.

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

Conciseness3/5

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

The description is front-loaded with the core purpose but includes redundant sections (e.g., repeating usage steps and language requirements). Some sentences, like 'Language setting: en (default: en)' and 'Push history check is enabled (CHECK_PUSH_HISTORY=true)', could be condensed or integrated more smoothly. The structure is clear but not optimally concise.

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 complexity (a push operation with preconditions), no annotations, and no output schema, the description does a good job covering usage steps, prerequisites, and output handling. It mentions sibling tools and environment configurations. However, it lacks details on error cases or what happens on failure, which would improve completeness for this type of tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single parameter 'message' with its type and example. The description adds minimal value beyond this, only restating that the commit message should be in English. It doesn't provide additional context like message formatting rules or constraints beyond what's in the schema.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Execute mgit push command for repository "my-project-repo" with a commit message.' This specifies the verb (execute push command), resource (repository), and required input (commit message). However, it doesn't explicitly differentiate from sibling tools like get_push_history or get_operation_logs beyond mentioning they should be called first.

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

Usage Guidelines5/5

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

The description provides explicit, step-by-step usage guidelines: 'You MUST call get_push_history tool FIRST to view the last 5 push records before using this tool' and 'Confirm that the changes in this push have not been pushed before, otherwise modify the push message and push again.' It names the specific alternative tool (get_push_history) and includes clear prerequisites and conditions for use.

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.

3 tool updatesDec 8, 2025
- First observedmy-project-repo_get_operation_logs
- First observedmy-project-repo_get_push_history
- First observedmy-project-repo_mgit_push

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-04-18 08:00 across 3 tools

Disambiguation4/5

The three tools have distinct purposes: get_operation_logs retrieves logs, get_push_history fetches recent push records, and mgit_push performs a push operation. However, the strong dependency between get_push_history and mgit_push (with mandatory ordering) creates some conceptual overlap, as they are tightly coupled for the push workflow, which could cause minor confusion if an agent misinterprets their separation.

Naming Consistency2/5

Naming is inconsistent across tools: my-project-repo_get_operation_logs and my-project-repo_get_push_history follow a prefix_verb_noun pattern, while my-project-repo_mgit_push uses a prefix_command pattern with 'mgit' instead of a clear verb. This mix of conventions (verb_noun vs. command) and the inclusion of 'mgit' as part of the tool name deviates from a predictable naming scheme, making it harder for agents to infer patterns.

Tool Count3/5

With 3 tools, the count is borderline for a Git-related server. While it covers a basic push workflow with logging and history checks, it feels thin for broader Git operations (e.g., no tools for cloning, branching, or pulling). The scope is narrowly focused on push operations, which justifies a small set, but it may limit usability for more complex agent tasks, placing it in the middle range.

Completeness2/5

The tool surface is significantly incomplete for a Git server. It only supports push-related operations (history check and push) and logging, missing core Git functionalities like commit, pull, branch management, or repository initialization. This creates obvious gaps that will cause agent failures when attempting standard Git workflows, as the server cannot handle basic version control tasks beyond a narrow push scenario.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
GenMBOAuth
com.genmb
List, read, edit, and deploy your GenMB AI-generated apps from any MCP client.
AI & Machine Learning Developer Tools
2
ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622

Related MCP Servers

Git MCP
Version Control Developer Tools Code Execution
kjozsa
F
license
A
quality
D
maintenance
MCP server for managing Git operations on local repositories, allowing users to list repositories, get and create tags, list commits, push tags, and refresh repositories through a standardized interface.
Updated 2 years ago (2025-03-05 10:13 UTC)
6
3
-
Git MCP Server
Version Control Developer Tools CI/CD & DevOps
yevheniikravchuk
A
license
Not graded
quality
Not graded
maintenance
Enables git repository operations through REST endpoints, providing access to repository status, diffs, and commits. Enforces security through configurable root directory allowlists for safe git operations.
Updated a year ago (2025-10-28 00:07 UTC)
-
Git Memory MCP Server
Version Control Monitoring
nirutyodjai
A
license
Not graded
quality
D
maintenance
Enables Git repository operations and real-time monitoring via MCP tools, with support for WebSocket events, authentication, and observability.
Updated a year ago (2025-10-04 23:27 UTC)
5 npm
4
MIT
Cross Repo Ops MCP
Version Control Developer Tools
DHCross
F
license
B
quality
C
maintenance
Enables secure, policy-controlled operations on local git repositories through MCP, including bounded reads, context-checked patches, allowlisted tasks, and guarded git operations.
Updated 24 days ago (2026-08-27 15:17 UTC)
10
-

MCP MGit Server

Prerequisites

MGit Installation and Setup

Key MGit Features

Features

Installation

Global Installation (Recommended)

Local Installation

From Source

Configuration

Usage

1. Direct Run (Global Installation)

2. Using npx (Recommended)

3. Direct Start (Source Installation)

4. Managed Start (Recommended for Production)

5. Development Mode

Editor Integration

Cursor Editor Configuration

VS Code Configuration

Multiple MGit Server Instances Support

As MCP Server

Available Tools

Logging

General Logs

Error Handling

Environment Variables

Development

Project Structure

Testing

Quick Start

1. Install Package

2. Configure Environment Variables

3. Run Server

Usage Example

Using the mgit_push tool

Troubleshooting

Error: Encountered error in step execution: error executing cascade step: CORTEX_STEP_TYPE_MCP_TOOL: calling "tools/call": EOF

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Error: `Encountered error in step execution: error executing cascade step: CORTEX_STEP_TYPE_MCP_TOOL: calling "tools/call": EOF`