mcp-server-git : démarrer avec uvx, d’abord lire l’état de l’arbre de travail

À qui ça s’adresse

À ceux qui ont besoin qu’un modèle interagisse avec un dépôt Git local et l’automatise : d’abord lire l’état de l’arbre de travail, puis décider de chercher ou de modifier. Convient si uv est déjà installé (donc uvx peut lancer mcp-server-git directement) et si un vrai repo_path peut être fourni. Ne convient pas sans dépôt local, ou si l’on attend que la documentation liste déjà tous les outils d’écriture. Page officielle : https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git

Premier essai en 3 minutes

Une seule voie officielle : exécuter mcp-server-git directement avec uvx. Ne pas commencer par pip.

Prérequis : uv / uvx est utilisable sur cette machine. Les notes indiquent alors “no specific installation is needed”. Préparer aussi un chemin de dépôt Git local ; le repo_path ultérieur doit le viser. Notes uv : https://docs.astral.sh/uv/ Notes uvx : https://docs.astral.sh/uv/guides/tools/

Emplacement d’installation et de configuration : dans le client MCP, écrire la commande de lancement comme un appel direct :

uvx mcp-server-git

Action à faible risque : une fois connecté, n’appeler que git_status, avec repo_path (chaîne, chemin du dépôt Git) comme paramètre. Il affiche l’état de l’arbre de travail et renvoie un texte sur le répertoire de travail courant. Ne pas enchaîner sur des opérations « manipulate » dès le premier essai : l’extrait garantit seulement que le serveur a les capacités read / search / manipulate ; il ne nomme aucun outil autre que git_status.

Signal de succès : un texte d’état de l’arbre de travail revient (propre ou avec des changements non validés, les deux comptent), pas une erreur de dépôt introuvable ou de commande inexistante. En cas d’échec, vérifier d’abord qu’uvx est disponible et que repo_path pointe vers un dépôt Git existant.

Cas d’usage

Cas 1 : inspecter l’arbre de travail. Correspond à l’outil git_status. Avant toute recherche ou modification, faire lire au modèle si la branche courante est propre et s’il y a des fichiers non suivis. La seule entrée est repo_path ; le retour est un état textuel. Les preuves ne décrivent pas la structure de champs de ce texte ; ne pas supposer qu’un diff structuré est disponible directement.

Cas 2 : automatiser au-delà de la lecture seule sur le même dépôt. Le serveur est positionné comme “Git repository interaction and automation” et indique qu’il peut read, search, manipulate. Mais l’extrait actuel ne développe que git_status ; il précise aussi que le projet est en early development, et que les fonctions et outils disponibles changeront et s’étendront. Le second cas ne peut donc aller que jusque-là : d’abord confirmer l’accès au dépôt avec git_status, puis opérer sur les autres outils que le client liste réellement — s’il n’en liste aucun d’écriture ou de recherche, s’arrêter à l’interrogation d’état. Ne pas compléter commit / push à partir d’autres greffons Git.

Limites d’usage

C’est un serveur en early development. La liste d’outils peut s’allonger ou se réduire ; ne pas traiter les noms vus dans le client actuel comme une API stable à long terme.

L’installation recommandée est uvx ; installer mcp-server-git avec pip puis exécuter python -m mcp_server_git n’est qu’une solution de repli. Ne pas la mettre au même rang qu’uvx comme première voie.

Les preuves ne décrivent en détail que git_status. read / search / manipulate est un aperçu de capacités, pas trois manuels d’outils déjà publiés. manipulate sur un dépôt a des effets de bord ; le point de contrôle doit être que l’arbre de travail ou l’historique des commits montre le changement attendu, et que repo_path n’a pas visé le mauvais répertoire.

L’accès porte sur un dépôt Git local. Ce n’est ni zéro lecture locale, ni une frontière de confidentialité nulle. Il n’y a ni liste de clients, ni entrée hébergée à distance.