mcp-server-git
MCPA Model Context Protocol server providing tools to read, search, and manipulate Git repositories programmatically via LLMs
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ✓ | SSE transport not explicitly implemented, may need stdio adapter |
| LangChain | ✓ | Tools maintain GitPython repo state which could conflict with parallel execution |
Security findings
Path traversal vulnerability in repository validation
The validate_repo_path function in server.py uses os.path.realpath() but doesn't properly prevent path traversal. An attacker could potentially access repositories outside the allowed directory by using symbolic links or relative paths. The function only checks if the resolved path startswith() the allowed directory, which can be bypassed.
Command injection via unsanitized git operations
Multiple functions (git_checkout, git_branch, git_add, git_commit, etc.) pass user-controlled input directly to GitPython methods without proper validation. For example, git_checkout accepts arbitrary branch names, git_commit accepts unvalidated messages, and git_add accepts file paths without sanitization. While GitPython provides some protection, branch names and commit messages could contain shell metacharacters.
Arbitrary file system access via git operations
The git_add function accepts arbitrary file paths from user input without validation against directory traversal (../ patterns). An attacker could potentially stage files outside the repository: git_add(test_repository, ['../../../etc/passwd']). No path sanitization is performed before calling repo.index.add().
No input length limits on commit messages and branch names
Functions like git_commit and git_create_branch accept message and branch_name parameters without any length validation. An attacker could cause denial of service by providing extremely long strings that consume excessive memory or cause performance issues.
Unrestricted git reset with potential data loss
The git_reset function accepts 'hard' mode without requiring any confirmation or access controls. An attacker could permanently delete uncommitted changes across the entire repository with no safeguards: git_reset(repo, mode='hard'). This is a destructive operation with no recovery mechanism.
Verbose error messages may leak repository structure
Functions return raw exception messages from GitPython which may include full file paths, internal directory structure, and git repository metadata. For example, git_checkout returns full exception text that could reveal system paths.
Missing validation on revision specifiers
No rate limiting or operation throttling
Insufficient validation of format strings in git_log
Reliability
Success rate
78%
Calls made
100
Avg latency
150ms
P95 latency
400ms
Failure modes
- • Git operations raise GitPython exceptions (BadName, GitCommandError) that may not be caught by server handlers
- • Path validation issues with invalid repository paths or non-existent directories
- • File system operations (Path.write_text, file access) lack comprehensive error handling
- • No timeout protection on git operations which could hang on network operations or large diffs
- • Missing validation for empty or malformed commit messages, branch names with special characters
- • No resource limits on diff output size - could cause memory issues with large diffs
- • Concurrent git operations on same repository could cause race conditions
- • Unicode handling in file paths and content not explicitly validated
- • Missing null/empty string checks for required parameters like file paths and branch names
Code health
License
MIT
Has tests
Yes
Has CI
No
Dependencies
4
Overall healthy project with good fundamentals. Strong points: comprehensive test suite (14KB test file), type hints enabled (py.typed marker), MIT licensed, published to PyPI (v0.6.2), good README (10KB), uses modern Python tooling (pyproject.toml, uv.lock), includes dev dependencies for quality tools (pyright, ruff, pytest). The test file shows thorough coverage of core git operations with proper fixtures and error handling tests. Weaknesses: No CI configuration detected (no .github/workflows, .travis.yml, etc.), no CHANGELOG file, and repository activity metrics unavailable from static analysis. The dependency count is minimal (4 production deps) which is good for maintenance. Uses established libraries (click, gitpython, mcp, pydantic). The presence of Dockerfile suggests containerization support. Minor concern: test coverage percentage not explicitly configured or reported. Score of 8 reflects solid code quality and testing practices, but lacks CI automation and changelog documentation that would push it to 9-10.