A
licenseB
qualityD
maintenanceA specialized MCP server for in-depth analysis of git repositories, offering tools for branch overview, time period analysis, file changes, and merge recommendations.
4
7
Apache 2.0
Simple Merge Review MCP
by sigmade
Provides tools for Git merge analysis, including showing changes between branches and quick merge change summaries.
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., "@Simple Merge Review MCPShow changes between main and feature/login"
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.
Simple Merge Review MCP
A lightweight MCP server for quick Git merge analysis. Shows only essential information without complex conflict checks.
🚀 Features
Quick Merge Overview - core change statistics
Changed Files List - what will be affected by merge
Simple Statistics - number of commits, lines, files
Related MCP server: Git Stuff Server
📦 Installation
# Clone the repository
git clone <repository-url>
cd local-merge-review-mcp
# Install dependencies
npm install
# Build the project
npm run build🛠️ Just 2 Simple Tools
1. show_merge_diff
Show changes between branches before merge.
await mcp.call_tool("show_merge_diff", {
repoPath: "/path/to/your/repo",
fromBranch: "main", // optional, defaults to main
toBranch: "feature/new-feature" // optional, defaults to current
});Result:
{
"sourceBranch": "main",
"targetBranch": "feature/new-feature",
"filesChanged": ["src/component.js", "package.json", "README.md"],
"insertions": 45,
"deletions": 12,
"commits": 3,
"summary": "3 commits, 3 files, +45/-12 lines"
}2. quick_merge_summary
Quick merge change summary.
await mcp.call_tool("quick_merge_summary", {
repoPath: "/path/to/your/repo",
branch: "feature/auth" // optional, defaults to current
});Result:
{
"currentBranch": "feature/auth",
"baseBranch": "main",
"message": "5 commits ahead",
"aheadBy": 5,
"behindBy": 0,
"needsMerge": true
}📋 Common Use Cases
Quick Pre-merge Check
"Show changes in feature/payment branch compared to main"
# show_merge_diffBranch Status Check
"How many commits ahead is the current branch?"
# quick_merge_summaryUnderstanding Change Scope
"How many files will change after merging this branch?"
# show_merge_diff + file list analysis📝 Usage with Claude Example
"Show changes between main and feature/auth in /home/user/myproject"
"How many commits ahead is current branch from main?"
"Which files will change after merge?"⚡ Why Simple is Better
Fast - no complex conflict checks
Clear - only essential information
Reliable - minimal dependencies
Practical - covers 90% of use cases
By default, conflicts are not expected, so complex checks are unnecessary. This MCP shows only what's truly important before merging.
⚠️ Requirements
Git installed and available in PATH
Node.js >= 18.0.0
🚧 Easy to Add Features
Format handling for specific files (.js, .py, etc)
Package.json version integration
Basic metrics (lines of code, comments)
Export to various formats
Available Tools
3 toolsquick_merge_summaryB
Quick summary of changes for merge
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to the git repository | |
| branch | No | Branch to analyze (default: current) |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only says 'summary of changes' without stating whether the tool is read-only, what format the summary is in, or any side effects. This is insufficient for an agent to understand the tool's behavior.
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 with one short sentence. It is well-structured and front-loaded, but could benefit from slightly more detail without becoming wordy.
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 output schema, the description should clarify what the summary contains (e.g., list of files, commit messages) and its format. The tool has 2 parameters and is a summary operation, but the description fails to provide sufficient context for an agent to use it correctly.
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% with clear descriptions for repoPath and branch. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 'Quick summary of changes for merge' clearly indicates the tool's purpose: it produces a summary of changes related to merging. It effectively differentiates from sibling tools show_file_diff and show_merge_diff, which are likely more detailed diff views.
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 this tool vs siblings. The name 'quick' implies it for overview rather than detailed diffs, but it lacks explicit when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_file_diffB
Show specific changes in a file between branches
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to the git repository | |
| filename | Yes | Path to the file relative to the repository root | |
| fromBranch | No | Branch to compare from (default: main/master) | |
| toBranch | No | Branch to compare to (default: current) |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as output format, whether it runs git diff, or prerequisites like a clean working directory. Minimal transparency beyond purpose.
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?
A single sentence that is concise and front-loaded with the core action. No wasted words.
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, the description should explain the return value (e.g., a text diff). It only says 'show changes,' leaving ambiguity. Sibling tools exist but no comparative completeness.
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 each parameter. The description adds no additional meaning beyond what the schema provides, resulting in baseline score.
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 shows specific changes in a file between branches, with a specific verb and resource. It distinguishes from siblings like quick_merge_summary and show_merge_diff, which focus on merge summaries and diffs.
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?
No guidance on when to use this tool versus alternatives like show_merge_diff. The description implies usage for a single file diff between branches but provides no when-not-to-use or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_merge_diffA
Show changes between branches before merge
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to the git repository | |
| fromBranch | No | Branch to merge from (default: main) | main |
| toBranch | No | Branch to merge into (default: current) |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation with 'show' but does not detail output format, side effects, or limitations such as large diffs. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence with no wasted words. Efficiently communicates the core purpose.
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 has 3 parameters, no output schema, and no annotations, the description is adequate but could be enhanced with details on what the diff output looks like (e.g., unified diff) or how the default branches work. Not fully complete 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?
Schema description coverage is 100% with clear descriptions for each parameter. The tool description adds no extra meaning beyond what the schema provides. Baseline of 3 is appropriate.
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 verb 'show', resource 'changes between branches', and context 'before merge'. It is specific and distinguishes from siblings: quick_merge_summary likely shows a summary, show_file_diff shows file-level diffs.
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?
Usage is implied by the description and name, but there is no explicit guidance on when to use this tool versus alternatives like quick_merge_summary or show_file_diff, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose: one provides a summary, one shows diffs for a specific file, and one shows the overall diff between branches. There is no overlap or ambiguity.
Naming Consistency4/5
All tools use snake_case and start with a descriptive term. However, 'quick_merge_summary' uses an adjective, while the others use a verb, creating a slight inconsistency in pattern.
Tool Count5/5
With only 3 tools, the server is well-scoped for its purpose of simple merge review. Each tool is essential and nothing seems unnecessary or missing.
Completeness4/5
The tools cover the core needs for merge review: a summary, overall diff, and file-level diff. Minor features like listing changed files or branch management are not present but are not essential for the minimal scope.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Freeze and unfreeze merges across a GitHub organization, with an audit trail.
Related MCP Servers
- FlicenseCqualityDmaintenanceMCP server providing Git-related functionalities, primarily a tool to generate diffs for Git merge commits against their first parent.4
- AlicenseNot gradedqualityDmaintenanceAutomatically generates comprehensive merge request summaries from git logs, analyzing commit history and categorizing changes into structured descriptions. Provides tools to analyze git repositories, compare branches, and create detailed summaries with change categorization, impact analysis, and review time estimates.1MIT
- AlicenseNot gradedqualityDmaintenanceEnables SQL queries against git repositories via MergeStat, allowing users to analyze commits, authors, and files using natural language.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sigmade/Git-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server