Local checkout or hosted repo?

Both. git_branch reads from a clone on disk, which fits an agent already working in a checkout. GitHub and Gitea list branches through their APIs, which is what you want when the repo lives on the host and the agent has no local copy. The returned list of branch names is the same regardless of source.

What does an agent do with a branch list?

It picks a target. Knowing the branches lets an agent choose which to check out, which to merge into, or which stale ones to delete after a feature ships. The list is also a guard: an agent confirms a branch exists before it tries to push to it or open a pull request against it.

MCP servers that can list branches

3 verified servers expose a tool that can list branches in a repository

Branches are the working surface of a repository, and an agent has to see which ones exist before it checks one out, merges into another, or prunes the dead ones. Listing branches answers that: every named line of work, including the ones nobody has touched in months.

The servers below return that list across local checkouts and hosted repos, so the read works whether the code sits on disk or behind an API.

Top pick

GitHub

Official

GitHub's official remote MCP server for repos, issues, pull requests, Actions, and code search.

version-control30,334

Tool:

list_branches

On GitHub, list_branches returns the branches of a hosted repository through the API, the read an agent reaches for when the code lives on the host and there is no local clone to inspect.

Pick 2

Git

Anthropic (Model Context Protocol)

Official

Reference MCP server for local Git: status, diffs, commits, branches, and history on a repo path.

version-control86,565

Tool:

git_branch

git_branch reads the branches straight from a local checkout, the plain-git version for an agent already inside a working tree deciding what to check out or merge.

Pick 3

Gitea

Official

Gitea's official MCP server for repos, branches, issues, pull request reviews, releases, Actions, and wikis on any Gitea instance.

version-control73

Tool:

list_branches

Self-hosted Gitea gives a private forge the same discovery: list_branches lists the branches of a repository you host in-house, so an internal forge reads no differently than a public one.

What to know

The shape of the answer is the same everywhere, a set of branch names, but the source differs. On GitHub, list_branches reads the branches of a hosted repository through the API, which is what an agent uses when there is no local clone to inspect. git_branch reads straight from a checkout on disk, the plain-git path for an agent already working in a working tree. Self-hosted Gitea offers the same list_branches read on a forge you run yourself, so a private forge gets the same discovery as a public one. Three sources, one question: what lines of work are open right now.

Branch lists drift between sessions: someone merges and deletes, a teammate cuts a new feature line, a release branch appears. So this is one read worth refreshing rather than trusting stale, but remembering which branch an agent itself created last time still matters. That memory is what lets it clean up its own stale branches instead of leaving them for a human to find.

Questions

Local checkout or hosted repo?: Both. git_branch reads from a clone on disk, which fits an agent already working in a checkout. GitHub and Gitea list branches through their APIs, which is what you want when the repo lives on the host and the agent has no local copy. The returned list of branch names is the same regardless of source.
What does an agent do with a branch list?: It picks a target. Knowing the branches lets an agent choose which to check out, which to merge into, or which stale ones to delete after a feature ships. The list is also a guard: an agent confirms a branch exists before it tries to push to it or open a pull request against it.