mcp-server-git: inicie com uvx e primeiro consulte o estado da árvore de trabalho

Para quem é

Para quem precisa que um modelo interaja e automatize um repositório Git local: primeiro lê o estado da árvore de trabalho e depois decide se pesquisa ou altera. Serve se o uv já está instalado (assim o uvx executa mcp-server-git diretamente) e um repo_path real pode ser fornecido. Não serve sem repositório local, ou se se espera que a documentação já liste todas as ferramentas de escrita. Página oficial: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/git

Primeira tentativa em 3 minutos

Siga só um caminho oficial: execute mcp-server-git diretamente com uvx. Não comece pelo pip.

Pré-requisito: uv / uvx está disponível nesta máquina. As notas dizem que, nesse caso, “no specific installation is needed”. Prepare também um caminho de repositório Git local; o repo_path posterior deve apontar para ele. Notas do uv: https://docs.astral.sh/uv/ Notas do uvx: https://docs.astral.sh/uv/guides/tools/

Onde instalar e configurar: no cliente MCP, escreva o comando de inicialização como uma chamada direta:

uvx mcp-server-git

Ação de baixo risco: após conectar com sucesso, chame só git_status, com repo_path (string, caminho do repositório Git) como parâmetro. Ele mostra o estado da árvore de trabalho e devolve texto do diretório de trabalho atual. Não faça operações do tipo “manipulate” na primeira tentativa: o trecho só garante que o servidor tem capacidades read / search / manipulate; não nomeia ferramentas além de git_status.

Sinal de sucesso: volta um texto de estado da árvore de trabalho (limpo ou com alterações não confirmadas conta), não um erro de repositório não encontrado ou de comando inexistente. Se falhar, confirme primeiro que o uvx está disponível e que repo_path aponta para um repositório Git existente.

Casos de uso

Caso 1: inspecionar a árvore de trabalho. Corresponde à ferramenta git_status. Antes de qualquer pesquisa ou alteração, faça o modelo ler se o ramo atual está limpo e se há ficheiros não rastreados. A única entrada é repo_path; o retorno é estado em texto. A evidência não descreve a estrutura de campos desse texto; não presuma que dá para obter um diff estruturado direto.

Caso 2: automatizar além da leitura no mesmo repositório. O servidor posiciona-se como “Git repository interaction and automation” e afirma que pode read, search, manipulate. Mas o trecho atual só desenvolve git_status; também diz que o projeto está em early development e que as funções e ferramentas disponíveis mudarão e se expandirão. Por isso o segundo caso só chega até aqui: primeiro confirme o acesso ao repositório com git_status e depois opere nas outras ferramentas que o cliente listar de facto; se o cliente não listar ferramentas de escrita ou pesquisa, pare na consulta de estado. Não complete commit / push a partir de outros plugins Git.

Limites de uso

É um servidor em desenvolvimento inicial. A lista de ferramentas pode crescer ou encolher; não trate os nomes vistos no cliente atual como uma API estável a longo prazo.

A instalação recomendada é uvx; instalar mcp-server-git com pip e depois executar python -m mcp_server_git é só alternativa. Não a coloque ao lado do uvx como primeiro caminho.

A evidência só descreve git_status em detalhe. read / search / manipulate é um resumo de capacidades, não três manuais de ferramentas já publicados. manipulate num repositório tem efeitos colaterais; o ponto de confirmação deve ser que a árvore de trabalho ou o histórico de commits mostre a alteração esperada, e que repo_path não apontou para o diretório errado.

O acesso é a um repositório Git local. Não é zero leituras locais nem uma fronteira de privacidade nula. Não há lista de clientes nem entrada alojada em remoto.