The Git server is the official reference implementation for working with a local repository. It gives a model the read side of git — status, staged and unstaged diffs, log, show, branch listing — and the write side too: stage files, create branches, check out and commit.
Bring your own
Claude Sonnet 4.5
Chat with 60+ AI models on the same workflow — switch to a different model mid-conversation and re-run the same prompt, or use Compare mode to put several side-by-side and balance quality vs. cost.
No token required
How models use it and what it is built for.
This is the third piece of the local development set, alongside the filesystem and GitHub servers, and it covers the part neither of the others reach. The filesystem server sees files as they are now; GitHub sees what has already been pushed. Git sees the working tree — what changed, what is staged, what the history says about why. In practice that is what makes a model useful on a real branch: it can read git_diff_staged before writing a commit message, check git_log to match the repository conventions, or run git_show on the commit that introduced a bug. The write tools are deliberately narrow. There is no push, no rebase, no force anything — the destructive end of git is simply not exposed, so the blast radius of a confused agent stays inside the local repository. You point the server at a repository path when you launch it.
Typical tools an AI model can call. Exact names vary by version.
Taken from the official Git documentation — see Git MCP Server — official reference implementation for the full reference.
Client configuration
uvx (recommended)
Pass --repository to bind the server to one repo. Without it, the client supplies the path through Roots.
{
"mcpServers": {
"git": {
"command": "uvx",
"args": ["mcp-server-git", "--repository", "/path/to/your/repo"]
}
}
}pip install
Use this when you want the package pinned in an environment you manage rather than resolved at launch.
{
"mcpServers": {
"git": {
"command": "python",
"args": ["-m", "mcp_server_git", "--repository", "/path/to/your/repo"]
}
}
}Copy any of these into MCP Agent Studio after connecting.
Read the staged diff and write a commit message that matches this repo’s style.
What changed on this branch compared to main, and does anything look unrelated?
Find the commit that introduced this function and show me what else it touched.
Create a branch for this fix, stage only the files I changed, and commit.
This is not a single-model product: you get the same MCP connection with 60+ models (Claude, GPT, Gemini, DeepSeek, open-weight, and more), you can switch mid-conversation, and you can open Compare mode to run the same prompt against multiple models at once. The card above is a suggested starting point for this server — not the only choice.
Default pick for Git
Claude Sonnet 4.5
Reading a diff and summarising intent is the core task here. Sonnet 4.5 writes commit messages that describe why rather than restating the changed filenames.
Listing tools proves the server is reachable, not that a model can work with it. Evals go further: they read every tool on the server, write a test suite from its real schemas, and run it — code decides pass/fail on the responses (schema conformance, error codes, pagination, result caps) while a scoring model grades plain-English tasks driven through the tools.
Get a pass/fail report per tool with the evidence behind each verdict — and replay the same suite after every schema change. Destructive tools are excluded from the run.
Run evalsOpen MCP Agent Studio with the connection pre-filled. Add your token, pick any of 60+ models, and start chatting — no install required.
Open Agent StudioCommon questions about connecting, scoping and using it safely.
It is an official reference server from the Model Context Protocol project, published on PyPI as mcp-server-git. It lets a model read and manipulate a local git repository — status, diffs, log, branches, staging and commits.
The GitHub server talks to GitHub’s API — pull requests, issues, code search, anything already pushed. The Git server operates on a repository on your own disk, including uncommitted work. They complement each other: read the working tree with Git, then open a PR with GitHub.
No. The tool set stops at commit — there is no push, rebase, reset --hard or force operation exposed at all. That is a deliberate design choice, and it means the worst outcome is a local commit you can undo rather than rewritten remote history.
Pass --repository with an absolute path when launching the server. Clients that support Roots can instead supply the working directory dynamically, which is useful if you move between projects in the same session.
Reasonably, because git itself is the safety net — a bad commit is one reset away, and nothing leaves your machine. The real practice worth keeping is reviewing git_diff_staged yourself before approving the commit call, which also catches the case where the model staged more than you expected.