mcp-server-git: mit uvx starten, zuerst den Arbeitsbaum prüfen

Für wen

Für alle, die ein Modell auf einem lokalen Git-Repository interagieren und automatisieren lassen und zuerst den Arbeitsbaum lesen, bevor sie suchen oder ändern. Passend, wenn uv schon installiert ist (damit mcp-server-git direkt per uvx läuft) und ein echter repo_path bereitsteht. Nicht geeignet ohne lokales Repository oder wenn die Dokumentation bereits alle Schreib-Tools auflisten soll. Offizielle Seite: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git

Erster Versuch in 3 Minuten

Nur einen offiziellen Weg gehen: mcp-server-git direkt mit uvx ausführen. Nicht zuerst pip nehmen.

Voraussetzung: uv / uvx ist auf dieser Maschine nutzbar. Die Hinweise sagen für diesen Fall “no specific installation is needed”. Zusätzlich einen lokalen Git-Repository-Pfad bereithalten; späteres repo_path muss darauf zeigen. uv-Hinweise: https://docs.astral.sh/uv/ uvx-Hinweise: https://docs.astral.sh/uv/guides/tools/

Installations- und Konfigurationsort: Im MCP-Client den Startbefehl als direkten Aufruf schreiben:

uvx mcp-server-git

Aktion mit geringem Risiko: Nach erfolgreicher Verbindung nur git_status aufrufen, Parameter ist repo_path (Zeichenkette, Git-Repository-Pfad). Es zeigt den Arbeitsbaumstatus und liefert Text zum aktuellen Arbeitsverzeichnis. Beim ersten Mal keine „manipulate“-Operationen: Der Auszug garantiert nur, dass der Server read / search / manipulate kann; andere Toolnamen außer git_status stehen nicht da.

Erfolgssignal: Ein Stück Status-Text zum Arbeitsbaum kommt zurück (sauber oder mit uncommitteten Änderungen zählt), nicht „Repository nicht gefunden“ oder „Befehl existiert nicht“. Bei Fehlschlag zuerst prüfen, ob uvx verfügbar ist und repo_path auf ein vorhandenes Git-Repository zeigt.

Anwendungsfälle

Fall 1: Arbeitsbaum ansehen. Entspricht dem Tool git_status. Bevor irgendetwas gesucht oder geändert wird, das Modell lesen lassen, ob der aktuelle Branch sauber ist und ob es untracked Dateien gibt. Eingabe ist nur repo_path, Rückgabe ist Textstatus. Die Belege beschreiben keine Feldstruktur dieses Statustexts; nicht annehmen, dass ein strukturiertes Diff direkt kommt.

Fall 2: Auf demselben Repository über Nur-Lesen hinaus automatisieren. Der Server ist als “Git repository interaction and automation” positioniert und kann read, search, manipulate. Der aktuelle Auszug entfaltet aber nur git_status; zugleich steht das Projekt in early development, Funktionen und verfügbare Tools ändern und erweitern sich. Der zweite Fall reicht deshalb nur so weit: zuerst mit git_status prüfen, dass das Repository erreichbar ist, dann auf anderen Tools arbeiten, die der Client tatsächlich auflistet – listet der Client keine Schreib- oder Suchtools, bei der Statusabfrage bleiben. commit / push nicht aus anderen Git-Plugins ergänzen.

Nutzungsgrenzen

Das ist ein Server in früher Entwicklung. Die Tool-Liste kann wachsen oder schrumpfen; Namen im aktuellen Client nicht als langfristig stabile API behandeln.

Empfohlene Installation ist uvx; mcp-server-git per pip installieren und dann python -m mcp_server_git ausführen ist nur Fallback. Nicht neben uvx als ersten Weg stellen.

Die Belege beschreiben nur git_status ausführlich. read / search / manipulate ist eine Fähigkeitsübersicht, keine drei veröffentlichten Tool-Handbücher. manipulate am Repository hat Nebenwirkungen; der Prüfpunkt muss sein, dass Arbeitsbaum oder Commit-Historie die erwartete Änderung zeigt und repo_path nicht auf das falsche Verzeichnis zeigte.

Zugriff erfolgt auf ein lokales Git-Repository. Das ist weder null lokales Lesen noch eine null Privatsphäre-Grenze. Es gibt keine Clientliste und keinen remote gehosteten Einstieg.