How is this different from listing pull requests?

Listing returns many PRs in shallow form, enough to triage a queue. Getting one returns that PR in depth. GitHub's pull_request_read, for instance, includes the diff, the reviews, and the comment threads, which a list call leaves out. An agent lists to decide which PR to look at, then gets that one to actually read the change.

Does a get call include the diff and review comments?

On GitHub, yes: pull_request_read returns the diff, reviews, and comments together. Bitbucket and Gitea return the pull request's details for the one you ask for by id or index; how much of the conversation comes back depends on the server. If your agent needs the code changes plus the discussion in one fetch, GitHub's read is the most complete here.

MCP servers that can get a pull request

3 verified servers expose a tool that can get a pull request's details

Listing PRs tells an agent what is open; getting one tells it what the change actually is. Fetching a single pull request pulls back the diff, the reviews, and the comment threads, the full record an agent needs to read a change rather than just count it.

These verified servers fetch one pull request's details on the major code hosts. This is the deep read on a specific PR, distinct from listing the PRs on a repository.

Top pick

GitHub

Official

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

version-control30,334

Tool:

pull_request_read

pull_request_read returns one PR's details, diff, reviews, and comments in a single call, the deepest single-PR read here and the basis for an agent summarizing or reviewing a change on GitHub.

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:

getPullRequest

Addressing one PR rather than the queue, getPullRequest returns the details for a specific pull request, the focused read for teams whose code lives in Bitbucket.

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:

get_pull_request_by_index

On a self-hosted Gitea instance, get_pull_request_by_index fetches a pull request by its index, the same single-PR lookup on a forge you run yourself.

What to know

The difference from a list call is depth on one target. GitHub's read goes furthest: details, the diff, the reviews, and the comments in a single fetch, enough for an agent to summarize a change, weigh the discussion, or decide whether it is mergeable. Bitbucket and Gitea return the specifics of one PR addressed by id or index, the record you read before commenting on it or acting on it. You list to find the PR; you get to understand it. An agent reviewing or summarizing lives in the get call.

A PR's details are a moving target while review is live, so the fetch itself is worth repeating. What an agent gains from earlier sessions is the judgment around it: the concerns it already raised on this PR, the points it decided were fine, the thread it is waiting on. Carry that forward and a second review pass continues the first instead of re-reading the whole diff as if it had never seen it.

Questions

How is this different from listing pull requests?: Listing returns many PRs in shallow form, enough to triage a queue. Getting one returns that PR in depth. GitHub's pull_request_read, for instance, includes the diff, the reviews, and the comment threads, which a list call leaves out. An agent lists to decide which PR to look at, then gets that one to actually read the change.
Does a get call include the diff and review comments?: On GitHub, yes: pull_request_read returns the diff, reviews, and comments together. Bitbucket and Gitea return the pull request's details for the one you ask for by id or index; how much of the conversation comes back depends on the server. If your agent needs the code changes plus the discussion in one fetch, GitHub's read is the most complete here.