Was ist Git (reference server)?
Der Git-Server ist ein Python-Referenzserver, den das MCP-Projekt pflegt. Stand Oktober 2026 ist er weiterhin einer von sieben Servern im Haupt-Repository modelcontextprotocol/servers; er gehörte nicht zu den ausgemusterten Referenzservern, die in das archivierte Repo servers-archived verschoben wurden. Er wird aktiv gepflegt: Die PyPI-Version 2026.10.19 baute ihn auf dem Python SDK 2.x neu auf, und er spricht jetzt sowohl die Protokollrevision 2025-11-25 als auch 2026-07-28.
Er stellt 12 Tools bereit: git_status, git_diff_unstaged, git_diff_staged, git_diff, git_commit, git_add, git_reset, git_log, git_create_branch, git_checkout, git_show und git_branch. Ein git_init gibt es nicht; ein Sicherheitshinweis vom Dezember 2025 zeigte, dass das alte überall auf der Festplatte Repositories anlegen konnte.
Du startest ihn mit uvx mcp-server-git --repository path/to/repo, mit pip oder mit dem Docker-Image mcp/git. Er arbeitet nur mit lokalen Repositories; er hat keine Netzwerk-Tools und spricht weder mit GitHub noch mit einem anderen Host.
Git (reference server) installieren
uvx mcp-server-git --repository path/to/repoLohnt sich Git (reference server)?
Dieser Server hat in genau einer Situation seine Berechtigung: bei einem Client wie Claude Desktop, der keine Shell-Befehle ausführen kann, aber Diffs lesen und Commits machen können soll. Dort erledigt er die Aufgabe mit typisierten Eingaben und Klartext-Ausgabe, und ein fehlgeschlagener Aufruf liefert eine Fehlermeldung, die das Modell lesen und korrigieren kann. In Claude Code, Cursor oder jedem Agenten mit Terminal dupliziert er nur git selbst, mit weniger Optionen.
Der Umfang endet am lokalen Arbeitsverzeichnis. Es gibt kein push, pull, fetch, merge, rebase oder stash, das Modell kann also Arbeit vorbereiten und committen, aber veröffentlichen muss sie weiterhin ein Mensch, was manche Teams als Sicherheitsmerkmal werten werden. Das README bezeichnet den Server noch als frühe Entwicklungsphase und warnt, dass sich Tools ändern können, und das haben sie: Der Neuaufbau vom Oktober 2026 änderte, wie unbekannte Tool-Namen gemeldet werden, und lässt Tool-Aufrufe nacheinander laufen.
Seine Sicherheitsbilanz spricht dafür, aktuell zu bleiben. Gegen mcp-server-git wurden vier Sicherheitshinweise veröffentlicht: drei mit mittlerem Schweregrad im Dezember 2025, die Argument Injection in git_diff und git_checkout, fehlende Pfadprüfung für --repository und das uneingeschränkte Tool git_init betrafen, und eine Path Traversal in git_add im Februar 2026, mit der sich Dateien außerhalb des Repositorys stagen ließen. Zu jedem gab es eine Korrektur, und die Releases vom Oktober verlangen außerdem GitPython 3.1.60 oder neuer wegen Sicherheitshinweisen im Upstream.
Die Eingrenzung ist gröber, als das Flag vermuten lässt. --repository geht bis zur Wurzel des Repositorys hoch, wer es also auf einen Unterordner richtet, gibt das ganze Repository frei, und ohne das Flag darf jeder Aufruf einen beliebigen repo_path auf dem Rechner nennen. git_reset nimmt nur Dateien aus dem Staging, aber git_checkout kann Branches unter einem Editor mit ungespeicherter Arbeit wechseln, und der Server fragt nicht nach; das bleibt den Freigabe-Prompts des Clients überlassen. Was das Modell hier liest, sind deine eigene Historie und deine Dateien, eine weit kleinere Angriffsfläche für Prompt Injection als bei einem Server, der Webseiten abruft.
Wo es sich lohnt
Eine Produktmanagerin, die ein Dokumentations-Repository aus Claude Desktop bearbeitet
Sehen, was sich seit letzter Woche geändert hat, und eine Formulierungskorrektur committen
git_log mit start_timestamp auf '1 week ago', git_diff gegen main, dann git_add und git_commit. Kostenlos; das Hauptrisiko ist ein Commit auf den falschen Branch, also lass die Freigabe-Prompts für Schreibvorgänge eingeschaltet.
Ein Plattformteam, das einen internen Code-Review-Agenten ohne Shell-Zugriff baut
Den Agenten Diffs und Historie eines ausgecheckten Repos lesen lassen und sonst nichts
Das Docker-Image mcp/git nur mit diesem Repository eingebunden betreiben und im Client nur die Lese-Tools (status, diff, log, show, branch) erlauben. Das erspart es, eine Shell in eine Sandbox zu stecken, und das Pushen bleibt bei der CI.
Bevor du dich festlegst
- Einrichtung
- uvx mcp-server-git --repository /path/to/repo, pip install mcp-server-git oder das Docker-Image mcp/git mit dem Repo als Bind-Mount. Das README enthält Konfigurationen für Claude Desktop, VS Code, Zed und Zencoder; die Tools erscheinen, sobald der Client neu startet.
- Integrationen
- 12 Tools. Lesen: git_status, git_diff_unstaged, git_diff_staged, git_diff, git_log, git_show, git_branch. Schreiben: git_add, git_commit, git_reset (nur Unstaging), git_create_branch, git_checkout.
- Daten und Datenschutz
- Läuft lokal mit den Dateirechten deines Nutzers und macht keine Netzwerkaufrufe, aber die Diffs und Dateiinhalte, die er zurückgibt, gehen an den Modellanbieter, den dein Client nutzt. Vier Sicherheitshinweise zwischen Dezember 2025 und Februar 2026 betrafen Argument Injection, Path Traversal und ungeprüfte Repository-Pfade.
- Kosten im großen Maßstab
- Kostenlos und Open Source. Die Kosten sind Kontext: git_diff und git_show liefern den vollständigen Text, ein großer Diff landet also komplett im Kontextfenster; context_lines und max_count sind die einzigen Größenregler.
- Grenzen
- Keine Remote-Operationen und keine Tools für stash, merge, blame oder tag; nur stdio, daher nicht als Remote-Server teilbar; Tool-Aufrufe werden serialisiert, parallele Aufrufe landen also in einer Warteschlange.
Was gut ist
- 12 typisierte Tools für Status, Diffs, Commits, Branches und Log
- Macht selbst keine Netzwerkaufrufe
- Aktiv gepflegt; unterstützt die Protokollversionen 2025-11-25 und 2026-07-28
- Veröffentlichte Sicherheitshinweise wurden zügig behoben
Was nicht
- Kein push, pull, merge, rebase oder stash
- --repository gibt das ganze Repo frei, und ohne das Flag ist jeder Pfad erlaubt
- Noch als frühe Entwicklungsphase gekennzeichnet; das Verhalten hat sich zwischen Releases geändert
- Überflüssig für Agenten mit Terminal
Am besten für
Nutzer von MCP-Clients im Chat-Stil, die das Modell ohne Shell-Zugriff lokale Änderungen prüfen und committen lassen wollen.
Alternativen zu Git (reference server)
Git (reference server): häufige Fragen
- Lohnt sich Git (reference server)?
- Ein ordentlicher, gut gepatchter Weg, einem Chat-Client ohne Shell Git zu geben, auch wenn jeder Agent mit Terminal bereits einen besseren hat. Wir bewerten es mit 3.8 von 5.
- Was kostet Git (reference server)?
- Kostenlos und Open Source.
- Welche Nachteile hat Git (reference server)?
- Kein push, pull, merge, rebase oder stash; --repository gibt das ganze Repo frei, und ohne das Flag ist jeder Pfad erlaubt; Noch als frühe Entwicklungsphase gekennzeichnet; das Verhalten hat sich zwischen Releases geändert; Überflüssig für Agenten mit Terminal.
- Für wen eignet sich Git (reference server)?
- Nutzer von MCP-Clients im Chat-Stil, die das Modell ohne Shell-Zugriff lokale Änderungen prüfen und committen lassen wollen.
- Was kostet Git (reference server) für ein Team oder im Produktivbetrieb?
- Kostenlos und Open Source. Die Kosten sind Kontext: git_diff und git_show liefern den vollständigen Text, ein großer Diff landet also komplett im Kontextfenster; context_lines und max_count sind die einzigen Größenregler.
- Ist Git (reference server) sicher für Firmendaten?
- Läuft lokal mit den Dateirechten deines Nutzers und macht keine Netzwerkaufrufe, aber die Diffs und Dateiinhalte, die er zurückgibt, gehen an den Modellanbieter, den dein Client nutzt. Vier Sicherheitshinweise zwischen Dezember 2025 und Februar 2026 betrafen Argument Injection, Path Traversal und ungeprüfte Repository-Pfade.
- Was sind die besten Alternativen zu Git (reference server)?
- Die nächsten Alternativen, die wir getestet haben, sind GitHub MCP Server und Filesystem (reference server).
Antworten geprüft am 23. Okt. 2026.