Which integrations are available for this server?

Provides tools for executing git push, status, diff, add, log, pull, and managing pending changes and push history.

How do I use MCP Server Git?

1. Click on "Install 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 Server Git show my pending 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 Server Git

by liliangshan

Overview Schema Related Servers Score Discussions

JavaScript

Local

MCP Server Git

A Model Context Protocol (MCP) server for executing git push operations with flexible branch mapping.

Features

Execute git push commands with flexible branch mapping and auto add/commit
Comprehensive Git operations: status, diff, add, log, push
Push history tracking and duplicate prevention
Pending changes review system with forced validation
Operation logging for debugging and monitoring
Support for multiple languages (English, Chinese, Traditional Chinese)
Environment variable configuration for flexibility
Proxy support (HTTP, HTTPS, SOCKS5) for corporate networks

Related MCP server: Git MCP

Installation

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

Environment Variables

The server requires the following environment variables:

Required

PROJECT_PATH: Absolute path to the git repository
LOCAL_BRANCH: Local branch name to push from
REMOTE_BRANCH: Remote branch name to push to

Optional

REMOTE_NAME: Remote name (default: "origin")
PULL_SOURCE_BRANCH: Source branch for git_pull (default: same as REMOTE_BRANCH)
GIT_PUSH_FLAGS: Additional git push flags (default: "--progress")
TOOL_PREFIX: Prefix for MCP tool names (default: "")
REPO_NAME: Repository identifier for logging and identification
LANGUAGE: Language for messages ("en", "zh", "zh-CN", "zh-TW") (default: "en")
MCP_LOG_DIR: Directory for log files (default: "./.setting" or "./.setting.{REPO_NAME}")
MCP_LOG_FILE: Log filename (default: "mcp-git.log")
MCP_PUSH_HISTORY_FILE: Push history filename (default: "push-history.json")
MCP_CHANGES_FILE: Pending changes filename (default: "pending-changes.json")
HTTP_PROXY: HTTP proxy URL (e.g., "http://proxy.company.com:8080")
HTTPS_PROXY: HTTPS proxy URL (e.g., "http://proxy.company.com:8080")
SOCKS_PROXY: SOCKS5 proxy URL (e.g., "socks5://proxy.company.com:1080"). Note: Git may require additional configuration for SOCKS5 proxy support.
NO_PROXY: Comma-separated list of hosts that should not use proxy
ALL_PROXY: Universal proxy URL for all protocols

Usage

1. Set Environment Variables

export PROJECT_PATH="/path/to/your/git/repository"
export LOCAL_BRANCH="main"
export REMOTE_BRANCH="main"
export REMOTE_NAME="origin"  # optional
export GIT_PUSH_FLAGS="--progress --verbose"  # optional
export TOOL_PREFIX="myproject"  # optional
export REPO_NAME="my-project"  # optional

# Proxy settings (optional)
export HTTP_PROXY="http://proxy.company.com:8080"
export HTTPS_PROXY="http://proxy.company.com:8080"
export SOCKS_PROXY="socks5://proxy.company.com:1080"
export NO_PROXY="localhost,127.0.0.1,.local"

2. Start the Server

Using npm script

npm start

Using the CLI

mcp-server-git

Using start-server.js (with validation)

npm run start-managed

Editor Integration

Multiple Project Instances Support

You can configure multiple instances of the Git MCP server in your editor to manage different repositories simultaneously. Use REPO_NAME and TOOL_PREFIX to isolate the tools and logs for each project.

Cursor Editor Configuration

Create or update .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "git-web-app": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-git"],
      "env": {
        "PROJECT_PATH": "D:/projects/web-app",
        "LOCAL_BRANCH": "main",
        "REMOTE_BRANCH": "main",
        "REPO_NAME": "web-app",
        "TOOL_PREFIX": "web"
      }
    },
    "git-api-service": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-git"],
      "env": {
        "PROJECT_PATH": "D:/projects/api-service",
        "LOCAL_BRANCH": "develop",
        "REMOTE_BRANCH": "develop",
        "REPO_NAME": "api-service",
        "TOOL_PREFIX": "api"
      }
    }
  }
}

Benefits of Multiple Instances:

Tool Isolation: Each instance has its own prefixed tools (e.g., web_git_push, api_git_push).
Log Isolation: Logs are stored in separate directories (e.g., ./.setting.web-app/, ./.setting.api-service/).
Independent Config: Different branches and paths for each repository.

💡 Best Practices and Usage Suggestions

To fully leverage the power of MCP Git Server, it is recommended to follow these "strong constraint" instructions when collaborating with AI:

Atomic Recording (save_changes):
- Instruction Suggestion: "Please call the save_changes tool immediately after completing each independent small feature or bug fix. You need to clearly list the modified files and briefly describe your modification logic in one or two sentences. Strictly forbid accumulating a large number of changes without recording them."
- Value: This ensures that AI's memory fragments are solidified in real-time, preventing the loss of initial intent in subsequent complex refactors.
Modular Pushing (git_push):
- Instruction Suggestion: "When we have completed all development and self-testing for the current feature module, please push by calling git_push. Before pushing, you must first fully read and summarize all our saved records from this session via get_pending_changes, generating a clear, structured Commit Message that covers all changes."
- Value: Making "summarizing historical records" a statutory pre-step for pushing, completely eliminating "goldfish memory" commits.
Periodic Review:
- If the session is extremely long (e.g., lasting several hours), you can occasionally ask the AI to call get_pending_changes for a mid-term summary to ensure the stored records perfectly match the current actual code state.

3. MCP Tools

The server provides the following MCP tools:

`git_push` (or `<TOOL_PREFIX>_git_push`)

Execute git push command with a commit message. Automatically adds and commits changes before pushing. Requires reviewing pending changes first.

Important: You MUST call get_pending_changes to review changes before using this tool. The push will be blocked if changes haven't been reviewed.

What it does:

Automatically runs git add . to stage all changes
Automatically runs git commit -m "message" to commit changes
Executes git push to push to remote repository
Clears all pending changes and resets review status

Parameters:

message (string, required): Commit message

Example:

{
  "name": "git_push",
  "arguments": {
    "message": "Update project files"
  }
}

If TOOL_PREFIX is set (e.g., "myproject"), the tool name becomes myproject_git_push.

Required Workflow:

Make code changes
Call save_changes to record your modifications
Call get_pending_changes to review and mark changes as reviewed
Call git_push to automatically add, commit, and push changes
For subsequent pushes, repeat steps 3-4 (review status is reset after each push attempt)

This executes: git push <REMOTE_NAME> <LOCAL_BRANCH>:<REMOTE_BRANCH> --progress

`get_push_history` (or `<TOOL_PREFIX>_get_push_history`)

Get the last 5 push history records to check for duplicates.

Parameters: None

`get_operation_logs` (or `<TOOL_PREFIX>_get_operation_logs`)

Get operation logs for debugging.

Parameters:

limit (number, optional): Number of logs to return (default: 50)
offset (number, optional): Offset for pagination (default: 0)

`git_status` (or `<TOOL_PREFIX>_git_status`)

Show the working directory and staging area status.

Parameters: None

Example:

{
  "name": "git_status"
}

`git_diff` (or `<TOOL_PREFIX>_git_diff`)

Show changes between working directory and HEAD or staging area.

Parameters:

staged (boolean, optional): Show staged changes instead of unstaged (default: false)
files (array, optional): Specific files to show diff for

Examples:

{
  "name": "git_diff"
}

{
  "name": "git_diff",
  "arguments": {
    "staged": true
  }
}

`git_add` (or `<TOOL_PREFIX>_git_add`)

Add file contents to the staging area.

Parameters:

files (array, optional): Files to add (default: ["."] for all files)

Examples:

{
  "name": "git_add"
}

{
  "name": "git_add",
  "arguments": {
    "files": ["src/main.js", "src/utils.js"]
  }
}

`git_log` (or `<TOOL_PREFIX>_git_log`)

Show commit history.

Parameters:

limit (number, optional): Number of commits to show (1-100, default: 10)
oneline (boolean, optional): Show commits in oneline format (default: false)

Examples:

{
  "name": "git_log"
}

{
  "name": "git_log",
  "arguments": {
    "limit": 5,
    "oneline": true
  }
}

`git_pull` (or `<TOOL_PREFIX>_git_pull`)

Execute git pull command from the configured remote and source branch.

Parameters: None

Example:

{
  "name": "git_pull"
}

This executes: git pull <REMOTE_NAME> <PULL_SOURCE_BRANCH>

`save_changes` (or `<TOOL_PREFIX>_save_changes`)

Save pending changes before pushing. Records modified files and change content for review.

Parameters:

files (array, required): Array of modified file paths
content (string, required): Description of the changes made

Example:

{
  "name": "save_changes",
  "arguments": {
    "files": ["src/main.js", "src/utils.js"],
    "content": "Fixed bug in user authentication"
  }
}

`get_pending_changes` (or `<TOOL_PREFIX>_get_pending_changes`)

Get and review pending changes before pushing. This tool MUST be called before git_push to enable pushing.

Important: Calling this tool marks changes as reviewed, allowing git_push to proceed. The review status is reset after each push attempt.

Parameters:

limit (number, optional): Number of changes to return (1-1000, default: 1000 - shows all changes)
offset (number, optional): Offset for pagination (default: 0)

Command Mapping

The server executes the following git command:

cd <PROJECT_PATH>
git push <REMOTE_NAME> <LOCAL_BRANCH>:<REMOTE_BRANCH> --progress

For example, with the default settings:

cd /path/to/project
git push origin main:main --progress

Validation

The server performs the following validations on startup:

Checks for required environment variables
Verifies that PROJECT_PATH exists
Ensures PROJECT_PATH is a valid git repository (contains .git directory)

Logging

All operations are logged to files in the configured log directory
Push history is maintained to prevent duplicate operations
Operation logs include request/response details for debugging

Error Handling

Environment variable validation on startup
Git command error handling with detailed error messages
Automatic logging of all operations and errors

License

MIT

Available Tools

10 tools

get_operation_logsB

Get operation logs for debugging and monitoring purposes.

ParametersJSON Schema

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

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description only mentions purpose, not behavioral traits like read-only nature, output format, or side effects. Minimal transparency beyond implied read operation.

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?

Single, concise sentence front-loads purpose. No filler, but could add value without losing conciseness.

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?

With no output schema, 2 parameters, and no annotations, description lacks critical details about log content, pagination usage, or response format. Incomplete for a debugging 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 coverage is 100% (limit and offset documented within schema). Description does not add extra meaning beyond schema, earning baseline score.

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?

Clear verb and resource: 'Get operation logs' with explicit purpose 'debugging and monitoring.' However, no differentiation from siblings like get_pending_changes or get_push_history, which may have overlapping functionality.

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?

States purpose but lacks explicit guidance on when to use this tool versus alternatives, no exclusions or prerequisites. Agent must infer from name and context.

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

get_pending_changesA

Get pending changes that need to be reviewed before pushing. This tool MUST be called before git_push to enable pushing.

USAGE: Call this tool to view and review all pending changes. This will mark changes as reviewed, allowing git_push to proceed. The review status is reset after each push attempt.

By default, this tool returns ALL pending changes (limit=1000). Use smaller limit values for pagination if needed.

Examples: {} - View and review ALL changes (default) {"limit": 10, "offset": 0} - View and review first 10 changes {"limit": 50} - View and review first 50 changes

NOTE: Review status is valid only for the next push attempt. You may need to review again for subsequent pushes.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Limit count (1-1000), default 1000 (shows all changes).
`offset`	No	Offset, default 0

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses that calling the tool marks changes as reviewed, which is a side effect beyond viewing. It also explains default limit and reset behavior. The only minor omission is not explicitly stating that the operation modifies state, but the disclosure is adequate.

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: a clear purpose statement, usage section, and examples. Every sentence adds value, no redundancy. It is front-loaded with the critical usage note that this tool must be called before pushing.

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?

The description covers purpose, usage, parameters, and side effects adequately given the tool's simplicity. It lacks an explicit description of the output format, but since no output schema is provided and the purpose is clear, this is a minor gap. Overall, it provides sufficient information for correct invocation.

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 already describes both parameters with 100% coverage. The description adds value by explaining the default limit (1000) and providing examples for pagination, which aids understanding beyond the schema alone.

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 gets pending changes for review before pushing, and explicitly distinguishes itself from sibling tools like git_diff and git_status by indicating it must be called before git_push. The verb 'get' combined with 'pending changes' is specific and unambiguous.

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 instructions: it MUST be called before git_push, marks changes as reviewed, and explains that review status resets after each push. It also includes default behavior and pagination examples, giving clear when-to-use context.

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

get_push_historyA

Get the last 5 push history records for the git repository. This tool should be called before using git_push to ensure the current changes have not been pushed before.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description fully conveys the tool's read-only nature and the limitation to the last 5 records. It could mention behavior when no pushes exist, but the core behavior is clear.

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?

Two concise sentences: first states purpose, second provides usage guidance. No superfluous information.

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 parameterless tool with no output schema, the description covers what it returns (last 5 records) and when to use it. Minor gaps like record format or return on empty history are acceptable.

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?

Tool has zero parameters, so baseline is 4. No additional parameter explanation is needed as the schema is empty and fully covered.

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?

Description clearly states 'Get the last 5 push history records for the git repository', specifying the verb 'get' and the resource 'push history records'. This distinguishes it from sibling tools like git_log (commit history) and get_operation_logs (general logs).

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?

Explicitly advises using this tool before git_push to avoid duplicate pushes, providing clear context and a specific alternative (git_push) for when to use it.

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

git_addA

Add file contents to the staging area.

USAGE: Call this tool to stage files for commit. Use "." to add all changes, or specify specific files.

Examples: {} - Add all changes (equivalent to "git add .") {"files": ["src/main.js", "src/utils.js"]} - Add specific files {"files": ["*.js"]} - Add files matching pattern (use shell expansion)

ParametersJSON Schema

Name	Required	Description	Default
`files`	No	Files to add (default: ["."] for all files)

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided. Description states it stages files, which is standard. Does not mention error cases or side effects, but acceptable for a simple tool.

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?

Concise with clear sections: purpose, usage, examples. Every sentence adds value. No fluff.

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?

Covers usage, default, and examples. No output schema needed. Missing details like error handling or edge cases, but sufficient for typical use.

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?

Adds value beyond schema: default value ['.'] and examples with specific files and patterns. Schema coverage 100% but description enriches understanding.

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?

Clear verb ('add') and resource ('file contents to the staging area'). Distinct from siblings like git_diff and git_log.

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

Usage Guidelines4/5

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

Explicitly states when to use: 'to stage files for commit'. Provides usage examples with '.' for all and specific files. No explicit when-not-to, but context is clear.

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

git_diffB

Show changes between working directory and HEAD or staging area.

USAGE: Call this tool to see the differences between your working directory and the last commit, or between staging area and HEAD.

Examples: {} - Show all unstaged changes {"staged": true} - Show staged changes {"files": ["src/main.js"]} - Show changes for specific file(s)

ParametersJSON Schema

Name	Required	Description	Default
`staged`	No	Show staged changes instead of unstaged, default false
`files`	No	Specific files to show diff for

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It implies a read-only operation but does not explicitly state that no modifications occur. The tool's nature (diff) makes it obvious, but explicit transparency would be better.

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 concise with a clear structure: a one-line summary, a usage heading, and examples. No unnecessary information. The examples are helpful but could be considered slightly verbose.

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?

The description does not explain the return format or behavior (e.g., that it outputs a text diff). Since there is no output schema, this omission leaves the agent uncertain about what to expect.

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, so the description does not add significant new meaning beyond what is already in the schema. The examples show usage patterns but do not explain parameter semantics further.

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 states it shows changes between working directory and HEAD or staging area, but the phrasing is ambiguous regarding the default comparison. The examples clarify the two modes (unstaged vs staged), but the initial description could be clearer.

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?

A usage section is provided, but it only says 'Call this tool to see the differences' without explicit guidance on when not to use it or how it compares to sibling tools like git_status or git_log.

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

git_logB

Show commit history.

USAGE: Call this tool to view the commit history of the repository.

Examples: {} - Show last 10 commits with full details {"limit": 5} - Show last 5 commits {"limit": 20, "oneline": true} - Show last 20 commits in oneline format

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of commits to show (1-100), default 10
`oneline`	No	Show commits in oneline format, default false

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention that the tool is read-only, safe, or what the output format will be. The examples hint at output style ('full details', 'oneline') but do not clarify safety or side effects.

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 concise, starting with a short purpose statement, followed by a usage instruction, and concrete examples. Every sentence is useful with minimal redundancy. The examples are well-structured.

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 simplicity (no required params, no output schema), the description covers basic usage adequately. However, it lacks information on return format, pagination, or error behavior. For a simple read tool, it is mostly complete but could be more thorough.

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 coverage is 100% with clear descriptions for both parameters. The description adds example usages illustrating the parameters' effects, but does not provide additional semantic meaning beyond the schema defaults and descriptions.

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 'Show commit history', which defines the tool's purpose as viewing the repository's commit log. It is specific and aligns with the tool name, but does not explicitly differentiate from sibling tools like get_operation_logs or get_push_history.

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 provides a basic usage instruction ('Call this tool to view the commit history'), implying when to use it. However, it lacks guidance on when not to use it or alternatives among sibling tools, such as using get_operation_logs for operation logs.

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

git_pullA

Execute git pull command from "origin/main" to the current branch.

Pull command: git pull origin main

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations; description mentions the exact git command but fails to disclose potential side effects like merge conflicts or the need for a clean working directory.

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?

Extremely concise with two sentences; no wasted words, directly addresses the tool's action.

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?

Lacks description of return values (output schema absent) and prerequisites (e.g., existence of remote origin), leaving gaps for an agent unfamiliar with git internals.

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?

No parameters in schema, schema coverage is 100%. Description adds nothing about parameters as they are absent, which is acceptable per baseline of 4 for zero params.

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?

Description clearly states the verb 'execute git pull' and specifies the resource 'from origin/main to current branch', distinguishing it from sibling tools like git_push and git_add.

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?

No explicit guidance on when to use vs alternatives, such as when to pull from other remotes or branches. Implicitly indicates for pulling from origin/main only.

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

git_pushA

Execute git push command from "main" to "origin/main" in project path "/app/repo".

Push command: git push origin main:main --progress

⚠️ REQUIREMENT: You MUST call get_pending_changes to review changes before using this tool.

USAGE:

First call get_pending_changes to review pending changes
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.

The review status is reset after each push attempt (success or failure).

ParametersJSON Schema

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

TDQS

A3.8/5.0

Behavior3/5

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

The description reveals that the tool pushes from main to origin/main, requires a commit message, and resets review status after each attempt. However, it does not specify whether it also commits, error conditions, or output details. Since no annotations exist, the description carries full burden but leaves gaps.

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 structured with a clear purpose line, followed by important usage notes. It is not overly verbose and each part serves a function, though it could be slightly more concise by omitting the exact git command string.

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?

The tool description explains the prerequisite workflow and mentions handling merge URLs, but lacks details on output/return values and error handling. Given no output schema, more completeness would be beneficial for an agent.

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 single 'message' parameter is well-documented in the schema, and the description reiterates the requirement for an English commit message with example. With 100% schema coverage, the description adds minimal extra value beyond what the schema provides.

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

Purpose5/5

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

The description clearly states the tool's action: 'Execute git push command from "main" to "origin/main"'. It uses a specific verb and resource, and distinguishes it from sibling tools like git_add and git_pull by naming the operation and context.

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

Usage Guidelines4/5

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

The description explicitly requires calling get_pending_changes first and provides step-by-step usage. While it does not discuss when not to use this tool or compare alternatives, the guideline is clear and actionable.

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

git_statusB

Show the working directory and staging area status.

USAGE: Call this tool to see which files have been modified, added, or deleted in your working directory and staging area.

Example: {}

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/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 the action (show status) without detailing whether the tool is read-only, its permissions, or performance characteristics. Implicit read-only, but no explicit transparency.

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 concise, with a clear heading and usage section. The empty example is somewhat redundant but does not detract significantly. It earns its space efficiently.

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 simplicity (no parameters, no output schema), the description is adequate but lacks any preview of the output format or return values. It provides minimal context beyond the basic function.

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 tool has zero parameters, and the schema description coverage is 100% (none needed). The description correctly omits parameter details, as per baseline 4 for zero-parameter tools.

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 it shows working directory and staging area status, with specific mention of modified, added, or deleted files. It effectively conveys the tool's purpose, though it could explicitly distinguish from sibling tools like git_diff or git_log.

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 provides clear context for when to use the tool (to see file changes), but it does not specify when not to use it or mention alternative tools among siblings, such as get_pending_changes for uncommitted changes.

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

save_changesA

Save pending changes before pushing. This tool records modified files and change content for review before git push.

USAGE: Call this tool to save your changes before pushing. The saved changes must be reviewed using get_pending_changes before git_push can proceed.

Please provide the change description in English language.

Example: {"files": ["src/main.js", "src/utils.js"], "content": "Fixed bug in user authentication"}

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes	Array of modified file paths
`content`	Yes	Description of the changes made in English language

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but description discloses that it records files and content for review, requires English description, and implies a workflow dependency. Minor gaps: doesn't specify overwrite behavior or multiple calls.

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?

Description is well-structured with a USAGE section, example, and front-loaded key info. Not overly verbose, but some room for trimming.

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?

Adequately covers purpose, usage, and dependencies with sibling tools. Lacks output description, but acceptable for a simple tool in a workflow.

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 coverage is 100%, so baseline is 3. Description adds example and reiterates 'English language' requirement, but doesn't add significant meaning beyond 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 the tool saves pending changes before pushing, specifies it records modified files and change content, and distinguishes from sibling tools like git_push and get_pending_changes.

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?

Explicitly states usage context: call before pushing, and that saved changes must be reviewed via get_pending_changes before git_push. Provides clear ordering and a usage section.

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.

10 tool updatesv1.0.3Jun 24, 2026
- First observedget_operation_logs
- First observedget_pending_changes
- First observedget_push_history
- First observedgit_add
- First observedgit_diff
- First observedgit_log
- First observedgit_pull
- First observedgit_push
- First observedgit_status
- First observedsave_changes

Install Server

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

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have distinct purposes: logs, pending changes, push history, add, diff, log, pull, push, status, save changes. The only potential confusion is between save_changes and get_pending_changes, but their usage order is clearly specified.

Naming Consistency3/5

Naming is mixed: tools use three patterns (get_*, git_*, and save_changes). Although each pattern is readable, the inconsistency across the set reduces predictability for an agent.

Tool Count5/5

10 tools is within the ideal range (3-15) for a focused Git server. Each tool serves a clear purpose without overloading the surface.

Completeness2/5

The server lacks a git commit tool, which is central to the git workflow. The custom save_changes/get_pending_changes workflow attempts to fill this but does not provide a true commit operation. Additionally, branch management tools are absent, limiting the server to a single-branch workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

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
Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362

Related MCP Servers

git MCP serverofficial
Version Control Developer Tools
modelcontextprotocol
A
license
B
quality
A
maintenance
A Model Context Protocol server for Git repository interaction and automation. This server provides tools to read, search, and manipulate Git repositories via Large Language Models.
Updated 3 days ago (2026-09-03 01:42 UTC)
12
90,042
MIT
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
-
MCP Git Server
Version Control Developer Tools
MementoRC
A
license
C
quality
B
maintenance
A Model Context Protocol server that enables LLMs to interact with Git repositories, providing tools to read, search, and manipulate Git repositories through commands like status, diff, commit, and branch operations.
Updated 16 days ago (2026-08-21 02:50 UTC)
22
4
MIT
Git Commit MCP Server
Version Control Developer Tools
lenslp
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to perform standard Git operations like staging, committing, and pushing changes. It facilitates a high-quality, standardized workflow for managing code repositories through natural language commands.
Updated 7 months ago (2026-02-10 06:34 UTC)
607
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/liliangshan/mcp-server-git'

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

MCP Server Git

Features

Installation

Environment Variables

Required

Optional

Usage

1. Set Environment Variables

2. Start the Server

Using npm script

Using the CLI

Using start-server.js (with validation)

Editor Integration

Multiple Project Instances Support

Cursor Editor Configuration

💡 Best Practices and Usage Suggestions

3. MCP Tools

git_push (or <TOOL_PREFIX>_git_push)

get_push_history (or <TOOL_PREFIX>_get_push_history)

get_operation_logs (or <TOOL_PREFIX>_get_operation_logs)

git_status (or <TOOL_PREFIX>_git_status)

git_diff (or <TOOL_PREFIX>_git_diff)

git_add (or <TOOL_PREFIX>_git_add)

git_log (or <TOOL_PREFIX>_git_log)

git_pull (or <TOOL_PREFIX>_git_pull)

save_changes (or <TOOL_PREFIX>_save_changes)

get_pending_changes (or <TOOL_PREFIX>_get_pending_changes)

Command Mapping

Validation

Logging

Error Handling

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

git MCP serverofficial

Latest Blog Posts

MCP directory API

`git_push` (or `<TOOL_PREFIX>_git_push`)

`get_push_history` (or `<TOOL_PREFIX>_get_push_history`)

`get_operation_logs` (or `<TOOL_PREFIX>_get_operation_logs`)

`git_status` (or `<TOOL_PREFIX>_git_status`)

`git_diff` (or `<TOOL_PREFIX>_git_diff`)

`git_add` (or `<TOOL_PREFIX>_git_add`)

`git_log` (or `<TOOL_PREFIX>_git_log`)

`git_pull` (or `<TOOL_PREFIX>_git_pull`)

`save_changes` (or `<TOOL_PREFIX>_save_changes`)

`get_pending_changes` (or `<TOOL_PREFIX>_get_pending_changes`)