MCP MGit Server
Related Servers
Alternatives to MCP MGit Server
No user-submitted related servers found.
Related Servers
- FlicenseCqualityCmaintenanceEnables MCP clients to inspect and modify local git repositories by running commands such as status, log, diff, add, commit, branch, and stash. Push operations are not performed locally; instead diffs are sent to a configurable HTTP API that handles the upload, with all other remote git commands blocked.27-
- FlicenseBqualityCmaintenanceEnables secure, policy-controlled operations on local git repositories through MCP, including bounded reads, context-checked patches, allowlisted tasks, and guarded git operations.10-
- AlicenseNot gradedqualityNot gradedmaintenanceEnables 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.-
- AlicenseNot gradedqualityDmaintenanceEnables Git repository operations and real-time monitoring via MCP tools, with support for WebSocket events, authentication, and observability.5 npm4MIT
- FlicenseAqualityDmaintenanceMCP 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.63-
- -licenseNot gradedqualityNot gradedmaintenanceEnables MCP clients to securely execute bounded coding tasks through registered backends, with idempotent job submission, status polling, and artifact retrieval. It isolates each job in Git worktrees and supports optional branch publishing and pull request creation under strict policy constraints.-
TDQS
Scored across 3 tools
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 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.
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.
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.