MCP Git server: what it is and how to choose one.

The short answer

An MCP Git server is a program that exposes Git operations as Model Context Protocol tools, so an AI agent can call repo.status or diff.text as structured tools instead of parsing raw git output. The important choice is the write policy: a read-only server can only inspect, a direct-write server can move refs on its own, and an approval-gated server lets the agent propose a write that a human confirms before it runs. For anything destructive, approval-gated is the safe default.

What is MCP, briefly

The Model Context Protocol is an open standard for connecting AI agents to tools and data. A host like Claude Code, Cursor, or Codex launches an MCP server, asks it what tools it offers, and then lets the model call those tools during a conversation. The protocol is transport-agnostic and vendor-neutral, so one server works across any compatible host. An MCP Git server is just an MCP server whose tools happen to be Git operations.

The reason this matters over letting the agent shell out to git directly is twofold. Structured tools return typed JSON the model does not have to parse from porcelain output, and each tool can be annotated as read-only or as a write, which is what makes a real permission boundary possible in the first place.

The three designs

Every MCP Git server sits somewhere on a spectrum of how much it trusts the agent. There are three practical points on it.

Read-only. The agent can inspect anything and change nothing. It explains why a branch diverged, summarizes a diff, or walks the reflog after a bad reset, but you switch to a terminal to actually move refs. Safe, and limited: the agent is a research assistant behind glass.

Direct write. The agent gets merge, rebase, reset, and commit as ordinary tools and decides for itself when to call them. This demos beautifully and fails badly in production, because a hallucination, a misunderstood task, or prompt injection from a malicious README all become real destructive Git operations with nobody in the loop.

Write with approval. The agent can propose a write but never holds the capability to execute one. A human sees the exact diff, the risk, and the recovery point that will be captured, and approves or rejects before anything runs. You get the agent's speed on the read and plan side, and a hard stop on the write side.

Start free: the read-only shell

You do not need to buy anything to try this. FluxGit's MCP server is published as an Apache-2.0 open-source shell at fluxgit-hq/fluxgit-mcp-server. Run standalone, it answers the read-only surface against your local git: repo.status, repo.brief, diff.text, repo.reflog, and the rest. Wiring it into a host is a short JSON block:

{
  "mcpServers": {
    "fluxgit": {
      "command": "fluxgit-mcp-sidecar",
      "args": []
    }
  }
}

One measured payoff of the structured surface: on a 44-commit, 40-file test repo, the usual ten-command git orientation sweep produced 1,886 tokens of output across ten round trips. One repo.brief call returned the same situational picture in 607 tokens and one round trip. That is measured with a real tokenizer on a synthetic repo, not estimated, and it is orientation only; we do not claim token savings for semantic diff, where the richer payload buys review precision rather than fewer tokens.

The write side, without handing over the keys

Reading is the easy, safe half. The write half is where an MCP Git server earns or loses your trust. FluxGit's full surface is 23 read-only tools for inspection and 11 write tools that only ever propose. Every proposed commit, branch, push, merge, rebase, reset, discard, patch, or worktree operation opens an approval card in the FluxGit desktop app, pre-filled with the agent's plain-language reason, the diff, and a note that a restore point will be captured first. Nothing touches the repository until you approve.

This is a design choice a cloud-only MCP server structurally cannot make: it has no UI to render an approval card in. The approval loop needs an application you already trust for Git, which is why the interesting write tools require the desktop app while the read-only shell runs anywhere. When you approve, FluxGit runs the operation through the same internal action a manual click would, so restore points, conflict preflight, and the Safety Timeline all apply unchanged.

How to choose

If you only want the agent to explain and summarize, a read-only server (including the free FluxGit shell) is enough. If you want the agent to actually help you land changes but you are not willing to let it move refs unwatched, pick an approval-gated server. Reserve direct-write servers for throwaway sandboxes where a wiped repo costs you nothing, because in a real repository the blast radius is your history.

There are host-specific setup guides for the common agents: FluxGit for Claude Code, for Cursor, and for Codex.