mcp-server-git: arranca con uvx y primero consulta el estado del árbol de trabajo

Para quién

Para quien necesita que un modelo interactúe y automatice un repositorio Git local: primero lee el estado del árbol de trabajo y luego decide si busca o cambia algo. Encaja si uv ya está instalado (así uvx puede ejecutar mcp-server-git directamente) y se puede dar un repo_path real. No encaja sin repositorio local, o si se espera que la documentación ya liste todas las herramientas de escritura. Página oficial: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git

Primer intento en 3 minutos

Sigue una sola ruta oficial: ejecuta mcp-server-git directamente con uvx. No empieces por pip.

Requisito previo: uv / uvx está disponible en esta máquina. Las notas dicen que entonces “no specific installation is needed”. Prepara también una ruta de repositorio Git local; el repo_path posterior debe apuntar a ella. Notas de uv: https://docs.astral.sh/uv/ Notas de uvx: https://docs.astral.sh/uv/guides/tools/

Dónde instalar y configurar: en el cliente MCP escribe el comando de arranque como una llamada directa:

uvx mcp-server-git

Acción de bajo riesgo: tras conectar con éxito, llama solo a git_status, con repo_path (cadena, ruta del repositorio Git) como parámetro. Muestra el estado del árbol de trabajo y devuelve texto del directorio de trabajo actual. No hagas operaciones de tipo “manipulate” en el primer intento: el extracto solo garantiza que el servidor tiene capacidades read / search / manipulate; no nombra herramientas distintas de git_status.

Señal de éxito: vuelve un texto de estado del árbol de trabajo (limpio o con cambios sin confirmar cuenta), no un error de repositorio no encontrado o de comando inexistente. Si falla, confirma primero que uvx está disponible y que repo_path apunta a un repositorio Git existente.

Casos de uso

Caso 1: inspeccionar el árbol de trabajo. Corresponde a la herramienta git_status. Antes de cualquier búsqueda o cambio, haz que el modelo lea si la rama actual está limpia y si hay archivos sin seguimiento. La única entrada es repo_path; la devolución es estado en texto. La evidencia no describe la estructura de campos de ese texto; no asumas que puedes obtener un diff estructurado directo.

Caso 2: automatizar más allá de solo lectura en el mismo repositorio. El servidor se posiciona como “Git repository interaction and automation” y afirma que puede read, search, manipulate. Pero el extracto actual solo desarrolla git_status; también dice que el proyecto está en early development y que las funciones y herramientas disponibles cambiarán y se ampliarán. Por eso el segundo caso solo llega hasta aquí: primero confirma el acceso al repositorio con git_status y luego opera en otras herramientas que el cliente liste de verdad; si el cliente no lista herramientas de escritura o búsqueda, detente en la consulta de estado. No completes commit / push desde otros complementos de Git.

Límites de uso

Es un servidor en desarrollo temprano. La lista de herramientas puede crecer o reducirse; no trates los nombres que ves en el cliente actual como una API estable a largo plazo.

La instalación recomendada es uvx; instalar mcp-server-git con pip y luego ejecutar python -m mcp_server_git es solo una alternativa. No la pongas al mismo nivel que uvx como primera ruta.

La evidencia solo describe git_status con detalle. read / search / manipulate es un resumen de capacidades, no tres manuales de herramientas ya publicados. manipulate sobre un repositorio tiene efectos secundarios; el punto de confirmación debe ser que el árbol de trabajo o el historial de commits muestre el cambio esperado, y que repo_path no apuntara al directorio equivocado.

Se accede a un repositorio Git local. No es cero lecturas locales ni un límite de privacidad nulo. No hay lista de clientes ni entrada alojada en remoto.