Why is GitHub's pick a search tool instead of a list?

Because GitHub's MCP server has no plain repository-list call. Repos are reached through search_repositories, a query against the index. To approximate "list all my repos," an agent searches on owner or org and pages through results, rather than reading a flat list the way it would on Bitbucket or Gitea.

How does an agent handle an account with hundreds of repos?

Through pagination and filtering. Bitbucket's listRepositories takes a name filter and pages, so an agent narrows by name and walks the pages instead of pulling everything at once. Gitea's search_repos and GitHub's search_repositories both accept a query, which is the more direct way to cut a large account down to the repos that matter for the task.

MCP servers that can list repositories

3 verified servers expose a tool that can list repositories

Before an agent clones, audits, or reports across a codebase, it has to know which repositories exist. Listing repositories is the discovery step: enumerate what a workspace or account holds, then decide where to look first.

The servers below give an agent that enumeration as a single tool call, across hosted forges and self-hosted ones.

Top pick

GitHub

Official

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

version-control30,334

Tool:

search_repositories

GitHub exposes no plain list, so discovery runs through search_repositories: a query against the repo index, the read an agent uses to find repos by name, owner, or topic before it clones or scans them.

Pick 2

Bitbucket

MatanYemini

Community

A maintained MCP server for Bitbucket Cloud and Server: browse repos, drive pull requests, comments, tasks, and pipelines.

version-control143

Tool:

listRepositories

Scoped to a workspace, listRepositories enumerates the repos that workspace owns, with optional name filtering and pagination so a large account comes back in manageable pages rather than a single dump.

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

Tools:

list_my_repos
search_repos

Self-hosted Gitea covers both questions: list_my_repos returns the authenticated user's own repositories, while search_repos runs a free-form query, so an agent picks "what I own" or "what matches" on a forge you run in-house.

What to know

Repository discovery splits along how each host models a collection. Bitbucket lists by workspace, the unit that owns repos on its platform, with name filtering and pagination so a large org's list comes back in pages rather than one wall. GitHub has no plain list at all: you reach repos through search, a query against the index, which is why the tool here is search_repositories rather than a list call. Gitea offers both shapes, the authenticated user's own repos and a free-form search, so an agent can ask either "what do I own" or "what matches this name." Pick the one that fits the question.

The set of repos in a workspace turns over slowly. An agent that re-enumerates the whole account on every task to find the three it actually works on is paying a discovery cost for a fact that rarely moved since last session. Remembering which repos are in scope, and which it already audited, keeps the next run pointed at the right targets.

Questions

Why is GitHub's pick a search tool instead of a list?: Because GitHub's MCP server has no plain repository-list call. Repos are reached through search_repositories, a query against the index. To approximate "list all my repos," an agent searches on owner or org and pages through results, rather than reading a flat list the way it would on Bitbucket or Gitea.
How does an agent handle an account with hundreds of repos?: Through pagination and filtering. Bitbucket's listRepositories takes a name filter and pages, so an agent narrows by name and walks the pages instead of pulling everything at once. Gitea's search_repos and GitHub's search_repositories both accept a query, which is the more direct way to cut a large account down to the repos that matter for the task.