Can an agent filter the list, or does it get everything?

GitHub's list_pull_requests takes filters for state, base, and head branch, so an agent can ask for just the open PRs against main, for example. Gitea lists a repo's PRs similarly. SonarQube returns the PRs it has analyzed for a project, scoped to that project.

Why is SonarQube on a pull-request list?

Because it lists PRs from the quality-analysis angle rather than the repository. An agent that wants to know which open PRs passed or failed their quality gate reads SonarQube's list; one that wants the diffs and review threads reads GitHub or Gitea.

MCP servers that can list pull requests

3 verified servers expose a tool that can list pull requests

Reviewing what is open is its own job, separate from opening a PR. Before an agent picks up review work, triages a queue, or reports on what is in flight, it needs to list the pull requests and read their state.

These verified servers let an agent list the pull requests on a repository or project.

Top pick

GitHub

Official

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

version-control30,334

Tool:

list_pull_requests

list_pull_requests returns a repository's PRs with filters for state, base, and head, the broad starting point for review and triage automation on GitHub.

Pick 2

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_repo_pull_requests

list_repo_pull_requests lists a repository's pull requests on a self-hosted Gitea instance, the same triage step on a forge you run yourself.

Pick 3

SonarQube

Sonar

Official

Sonar's official MCP server brings SonarQube code quality, security, and coverage analysis into your AI agent.

devops-ci563

Tool:

list_pull_requests

On the analysis side, list_pull_requests returns the PRs SonarQube has scanned for a project, so an agent can check quality gates rather than code.

What to know

A list call with filters is the starting point for most review automation: find the open PRs, the ones awaiting a given reviewer, the stale ones. What the agent does next depends on the server. GitHub and Gitea sit on the repository, so the list is per-repo with branch and state filters. SonarQube comes at it from the analysis side, listing the PRs it has scanned for a project, which is where an agent checks a quality gate rather than a diff.

A queue of open PRs moves between runs, so the list itself is worth re-fetching each time. What an agent benefits from carrying forward is the context around them: which PRs it already triaged and what it decided, so a review pass does not start cold every session.

Questions

Can an agent filter the list, or does it get everything?: GitHub's list_pull_requests takes filters for state, base, and head branch, so an agent can ask for just the open PRs against main, for example. Gitea lists a repo's PRs similarly. SonarQube returns the PRs it has analyzed for a project, scoped to that project.
Why is SonarQube on a pull-request list?: Because it lists PRs from the quality-analysis angle rather than the repository. An agent that wants to know which open PRs passed or failed their quality gate reads SonarQube's list; one that wants the diffs and review threads reads GitHub or Gitea.