Git MCP server for Codex, Claude Code and Cursor.

The short answer

A Git MCP server exposes Git operations as Model Context Protocol tools, so an AI agent can call repo.status or diff.text and receive structured results. FluxGit exposes 25 read-only tools, 12 operation.preview.* tools that create proposals, and operation.cancel for the calling agent's own pending proposal. It exposes no direct Git mutation endpoint. FluxGit Desktop executes a supported write only after a person reviews that operation's impact, risk and available recovery information and approves it. A shell granted separately by the agent host remains outside this boundary.

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 annotations such as readOnlyHint describe the intended behavior to a host. The official MCP guidance treats those annotations as untrusted hints, not enforcement. FluxGit's boundary comes from exposing no direct mutation endpoint and requiring its desktop app to approve each proposal before its own execution path runs.

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 increases the possible impact of a hallucination, misunderstood task, or prompt injection. Its practical safety then depends on controls outside the server, such as the host's sandbox, permissions and confirmation policy.

Write with approval. The agent can propose a write but never holds a direct execution tool. A human sees an operation-specific preview, risk and available recovery context, then 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, 13 tools inspect local Git directly. Four hybrid tools provide documented local fallbacks, five safety tools require the FluxGit app, and operation.status reads an accepted proposal's lifecycle. Wiring the shell into a host starts with cargo install fluxgit-mcp-sidecar --locked. The release is also listed in the official MCP Registry. Then use a short JSON block:

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

The structured surface reduces the number of separate commands an agent needs for repository orientation. In our reproducible Git context benchmark, repo.brief used 362 output tokens in one call versus 1,790 across a broad ten-command CLI sweep. A deliberately minimal five-command CLI used 492 tokens, which repo.brief now also beats; the page keeps that comparison and the cases where MCP used more tokens public. Semantic diff remains a richer review payload rather than a token-saving claim.

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 25 read-only tools for inspection and 13 human-gated operation tools. Twelve submit proposals; the thirteenth cancels an agent's own pending proposal. A proposal opens an approval card in the FluxGit desktop app, pre-filled with the agent's plain-language reason and an operation-specific preview, risk and available recovery context. Nothing runs through FluxGit until you approve it.

FluxGit places this approval loop in the desktop application that already owns the local repository workflow. That lets it show repository-specific impact, risk and recovery context before its own execution path runs, while the read-only shell remains useful on its own. When you approve, FluxGit runs the operation through the same internal action a manual click would. The result reports the actual outcome and includes restore-point metadata only when that operation captured one.

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. For any other MCP host, use the generic Git MCP setup guide.