Git Conflict MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| init_projectA | Initialize the project by setting the root directory path. This must be the first tool called to set up the environment. |
| list_conflictsA | List files with git conflicts including conflict types. Returns a map of ID to file info with conflict type and suggested resolution. (Rate limit: 2 calls per minute). IMPORTANT: You must run init_project before using this tool. |
| read_conflictA | Read the content of a conflicted file by its ID. (Rate limit: 5 calls per minute). You must use list_conflicts to get the ID first. |
| post_resolveA | Execute this tool BEFORE running resolve_conflict to confirm the resolution process. This acts as a safety confirmation step. |
| resolve_conflictA | Request conflict resolution by its ID or file path. The actual resolution will be performed by a human through the WebUI. Supports different resolution types for various conflict scenarios (content conflicts, delete/modify conflicts, etc.). You must run post_resolve before running this tool. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose with no overlap: init_project sets up the environment, list_conflicts enumerates conflicts, read_conflict reads file content, post_resolve confirms resolution, and resolve_conflict requests resolution. The descriptions clearly differentiate their roles, eliminating any ambiguity.
The tools follow a consistent verb_noun pattern (e.g., init_project, list_conflicts, read_conflict, resolve_conflict), which is predictable and readable. The minor deviation is post_resolve, which uses 'post' as a prefix instead of a verb, but it still fits the overall naming style without causing confusion.
With 5 tools, the count is well-scoped for a Git conflict resolution server. Each tool earns its place by covering essential steps: initialization, listing, reading, confirming, and resolving conflicts, without being overly sparse or bloated.
The tool set provides complete coverage for the core Git conflict resolution workflow, including setup, inspection, and resolution steps. A minor gap is the lack of a tool to directly modify or apply resolutions programmatically, as resolve_conflict relies on human intervention via WebUI, but agents can still navigate the process effectively.