Quick overview
Git MCP is the version-control boundary between an agent and repository history, and its most valuable output is not the current file tree — it is causality. A working tree tells you what exists; Git tells you why it exists, which commit changed it, which branch introduced it, and whether the apparent fix is actually a regression from an earlier revert. The server exposes repository-aware operations such as log, diff, status, branch inspection, commit lookup, and content search without requiring the agent to execute arbitrary shell commands. That narrower surface matters: a coding agent can investigate a bug and construct a patch context while remaining unable to run curl, install packages, or read unrelated host files. The hidden edge case is repository state ambiguity. A detached HEAD, shallow clone, sparse checkout, submodule, or uncommitted worktree can make a perfectly valid Git response look like project truth while silently omitting the context the agent needs. Production workflows should report repository root, current ref, HEAD SHA, shallow/sparse status, and dirty files before reasoning about history. Git MCP is a history engine, not a sandbox; filesystem and write permissions still determine the blast radius.