Best Git MCP Servers for AI Agents

Start with GitHub's official MCP server if your code lives on GitHub: it covers repositories, issues, pull requests and Actions, with a hosted endpoint and a Docker image. For local Git operations, use the reference mcp-server-git or cyanheads' git-mcp-server. For GitLab, look at the community servers and GitLab's own documentation. Many agents can already run git in a shell, so add a server only for a reason. Checked 31 October 2026.

The short version

Single-pair pages for these get almost no search demand, so this page is a category roundup. Our listings are Git MCP and GitHub MCP, and the wider directory is MCP servers.

Do you need one?

Coding agents like Claude Code and Codex can run git in a shell. That already covers status, diff, commit and push. So the real question is what a server adds.

• Typed tools instead of raw shell. The agent calls git_commit with fields, which is easier to allow or deny per tool than a free shell.
• A shell-free setup. An agent in a chat app may have no shell at all.
• Hosting services. Issues, pull requests, reviews and CI runs live on GitHub or GitLab, not in your repository. A server for the service gives the agent those, and a shell cannot, unless it also has the vendor's CLI.
• Permission control. Some servers have read-only modes.

If your agent has a shell and a logged-in gh CLI, you may need nothing. Claude Code's own docs say CLI tools such as gh are more context-efficient than MCP servers, as we note in MCP vs API.

The comparison table

Repository facts on 31 October 2026:

GitHub MCP server

Maintained by GitHub. The README calls it GitHub's official MCP server. It is MIT licensed and there are two ways to run it.

Remote. A hosted server at https://api.githubcopilot.com/mcp/. Sign in with OAuth, where each host application must configure a GitHub App or OAuth App, or with a personal access token. The README documents toolsets, request headers and an insiders mode at /mcp/insiders with early features. Toolsets let you enable only the groups of tools you want. There is also documentation for GitHub Enterprise Cloud with data residency.

Local. The Docker image is ghcr.io/github/github-mcp-server. For Claude Code the README gives:

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

Use a fine-grained token with only the permissions you need, since the server acts with your token. The README lists scopes such as read:packages for Docker image access. Our listing is GitHub MCP.

Why start here. It reaches things a local Git server cannot: issues, pull request reviews, Actions runs, code search. For agents that already have a shell and gh, test whether it adds enough to justify its tool definitions in context. Toolsets help you keep the tool list short.

Reference Git server

Part of the MCP project's collection of reference servers. The README warns that mcp-server-git is in early development, and that functionality and tools may change. Tools listed include git_status, git_diff_unstaged, git_diff_staged, git_diff, git_commit, git_add, git_reset, git_log, git_create_branch, git_checkout, git_show and git_branch. Run it with uvx mcp-server-git, or install with pip install mcp-server-git.

The main repository README describes its servers as reference implementations meant to show MCP features and SDK usage, not production-ready solutions, and points to the official MCP Registry for discovery. Treat it as a good starting point and an example to read. GitHub shows its licence as NOASSERTION, so read the repository's licence files before reuse.

cyanheads git-mcp-server

A community server, Apache-2.0, that advertises 28 tools, one resource and one prompt over stdio and Streamable HTTP. The tools cover repository management (init, clone, status, clean), staging and commits, history and inspection (log, show, blame, reflog), an analysis tool that gathers context for LLM-written changelogs, and branching and merging, including merge, rebase and cherry-pick. The description also mentions worktrees and stashes.

It is the fuller of the two local servers. With that comes more risk: rebase, clean and reset can destroy work, so use it in a repository with a clean backup, and keep human approval on for destructive tools. The last push we saw was 26 September 2026 and the star count is small, so read the open issues before you adopt it.

GitMCP

Described in our docs roundup: a free, open-source, remote server that turns a public GitHub repository or GitHub Pages site into a documentation source, through gitmcp.io/{owner}/{repo}. It reads documentation rather than managing your repository, so it complements the others. Use it to let an agent read a library's own docs and llms.txt.

GitLab

For GitLab, the servers we found on GitHub are community projects, such as jmrplens/gitlab-mcp-server (MIT, about 45 stars, pushed 30 October 2026, describing a dynamic find and execute approach) and yoda-digital/mcp-gitlab-server (MIT, a larger tool set). Their star counts are small, so inspect the code and permissions yourself. GitLab itself has documentation for its own MCP integration, which we could not fetch from the docs site, so check it for which plans include it.

Whatever you choose, give it a project access token with limited scope rather than your personal token.

Three workflows worth setting up

1. Issue triage, read-only. Connect the GitHub server with only the issue-related toolset and a token that can read issues but not write them. Ask the agent to list open issues with no labels, group them by theme and draft a label for each. You review the draft and apply labels yourself. Nothing the agent does can change the repository, which makes this the safest first use.

2. Pull request review. Give the agent the pull request number. It fetches the diff and comments through the server, reads the touched files in your local clone, and writes a review for you to post. Keep posting manual until you trust the quality. The agent's value here is catching what a quick skim misses, such as a changed function signature that a caller still uses.

3. Release notes. Ask the agent to read the commits since the last tag, using a local Git server or a shell, and draft notes in your house style. The cyanheads server includes an analysis tool aimed at this, which gathers context for a changelog. Check every line against the commits, since models summarise confidently.

Token cost and the case for fewer tools

Each server adds tool definitions to your agent's context, and a big server adds many. GitHub's server has a large surface. Its toolsets exist to let you load only what you need, and the README notes that default toolsets apply when none are specified. Pick the smallest set for the job.

Claude Code defers MCP tool definitions by default, loading only names until a tool is used, but other agents may load them all at the start. If your agent feels slower or costs more after you add a server, remove the toolsets you do not use. And if your agent already has a shell with git and gh, compare a session with and without the server on the same task. Sometimes the shell is simply cheaper, and the server earns its place only when you need its permission controls or its reach into the hosting service.

Troubleshooting

• Authentication fails. Check that the token has the right scopes and has not expired. Fine-grained tokens are tied to specific repositories, so a token without access to the repo returns not found rather than forbidden.
• The agent cannot see a private repository. The token, not the server, decides access. Add the repository to the token.
• Docker errors on pull. The README notes that the image is public and that an expired Docker login can cause pull errors. Log out of the registry and retry.
• The tool list is huge. Reduce toolsets or switch to read-only.
• Commits have the wrong author. A local Git server uses your repository's configured identity. Set user.name and user.email before the agent commits.
• Force pushes. Turn on branch protection on the host. A tool setting is not a substitute.

Install for each agent

The GitHub server's README lists one-click installs for VS Code and other hosts, and the command for Claude Code above. For remote setup in any client that supports HTTP servers, point at https://api.githubcopilot.com/mcp/ and provide a token header or OAuth. The reference Git server runs with uvx mcp-server-git in an agent's MCP config. Check each agent's MCP page for exact syntax; Claude Code MCP servers and best MCP servers list more.

Safe use

A Git server can rewrite history and a GitHub server can merge pull requests. Treat both as write-capable.

1. Least privilege. Use a fine-grained token limited to the repositories and actions you need. Read-only where possible.
2. Branch protection. Protect your main branch on the host so an agent cannot force-push to it, whatever the tool allows.
3. Human approval on commit, push, merge and delete tools.
4. Work on a branch or a clone. Let the agent experiment where mistakes are cheap.
5. Do not auto-run destructive tools such as clean, reset and rebase.
6. Treat issue and pull request text as untrusted. A comment in a public repository can contain instructions aimed at your agent. The MCP specification says tools represent arbitrary code execution, and hosts should get user consent before invoking them.
7. Keep tokens out of config files you commit.

Which to pick for which job

Token permissions by workflow

The server acts with whatever your token can do, so the token is the real policy. Set it per workflow and not once for everything.

GitHub's README recommends a fine-grained token with only the permissions you need. Fine-grained tokens are tied to chosen repositories, which is the feature that keeps one agent from seeing your whole account. Keep one token per workflow, name each by what it does, and set an expiry so a forgotten token dies by itself.

A team policy in five lines

Teams argue about this most when nothing is written down. Agree these and put them in your instructions file.

1. The agent may read any repository the token covers and may draft, but a person posts and merges.
2. Destructive Git actions (reset, clean, rebase, force push) stay with a person, backed by branch protection on the host.
3. Tokens are issued per person, never shared, and expire.
4. Issue and pull request text is untrusted input, so the agent summarises it and does not obey it.
5. Any new server is reviewed for its licence, maintainer and last push date before it is installed, the same way the table above does it.

Questions people ask

Do I need a server if I have `gh` installed? Often not. Claude Code and Codex can run gh in a shell, and the section above notes Claude Code's docs call CLI tools more context-efficient than MCP servers. A server helps when you want typed tools, per-tool permissions or an agent with no shell.

Why does the agent say a private repository does not exist? The token decides what is visible. A fine-grained token without that repository returns not found, as the troubleshooting list notes.

Which local Git server should I pick? The reference server is smaller and flagged as early development. The cyanheads server has 28 tools, which means more power and more risk. Choose by how many tools you want to approve.

Our take

Most developers need one server, and it is GitHub's if GitHub is where the work lives. Use toolsets to keep it small and a fine-grained token to keep it safe. Add a local Git server only if your agent has no shell or you want typed, individually permissioned tools, and prefer the reference server for simplicity or cyanheads' for breadth.

We did not run these servers against a shared task, so we make no claims about speed or reliability. The table comes from each repository on 31 October 2026, and open points are marked. A good first test is read-only: ask the agent to summarise the last ten pull requests or the last ten commits, and check it against what you know.

Related pages

• GitHub MCP and Git MCP
• Best docs MCP servers
• Best database MCP servers
• Best MCP servers