Which integrations are available for this server?

Allows browsing and reviewing GitHub pull requests, including listing repositories, open PRs, and fetching diffs for review.

How do I use PR Reviewer MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PR Reviewer MCP Server List open pull requests in my-org/my-repo" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PR Reviewer MCP Server

by subhamyadav580

Overview Schema Source Related Servers Discussions Admin

Python

Remote

PR Reviewer MCP Server

An MCP (Model Context Protocol) server that connects Claude to GitHub, allowing it to list repositories, browse open pull requests, and inspect PR diffs — all from within Claude Code.

Prerequisites

Python 3.11+
uv — fast Python package manager
Claude Code CLI installed (npm i -g @anthropic-ai/claude-code)
A GitHub Personal Access Token with repo scope

Related MCP server: PR Review MCP Server

Setup

1. Clone the repository

git clone https://github.com/subhamyadav580/pr-reviewer.git
cd pr-reviewer

2. Install dependencies

uv sync

This creates a .venv and installs all pinned dependencies from uv.lock.

3. Get a GitHub Personal Access Token

Go to GitHub → Settings → Developer settings → Personal access tokens and create a token with at minimum the repo scope (add read:org if your org repos are private).

4. Register the MCP server with Claude Code

Run this once — it registers the server at user scope so it's available in every project:

claude mcp add pr-reviewer -s user \
  -e GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx \
  -e GITHUB_ORG=your-github-org-name \
  -- /absolute/path/to/pr-reviewer/.venv/bin/python \
     /absolute/path/to/pr-reviewer/main.py

Replace:

ghp_xxxxxxxxxxxxxxxxxxxx — your GitHub PAT
your-github-org-name — the GitHub org you want to query (e.g. my-company)
/absolute/path/to/pr-reviewer — the full path where you cloned this repo

Verify it was registered:

claude mcp list

You should see pr-reviewer in the output.

5. (Optional) Install the `/review-pr` slash command

The repo ships with a review-pr.md slash command that gives Claude a structured, step-by-step review workflow. Copy it into your global Claude commands folder:

mkdir -p ~/.claude/commands
cp /absolute/path/to/pr-reviewer/review-pr.md ~/.claude/commands/review-pr.md

Now in any Claude Code session type /review-pr and Claude will:

List all org repositories for you to pick from
Show open PRs in the selected repo
Fetch the PR details and diff
Post a structured review with Blockers / Suggestions / Positives and a merge recommendation

Available MCP Tools

Tool	Description
`list_org_repositories`	Lists all repositories in the configured GitHub org
`list_open_pull_requests(repo_full_name)`	Lists open PRs for a repo (e.g. `"my-org/my-repo"`)
`get_pull_request_details(repo_full_name, pr_number)`	Returns PR metadata: title, body, author, file count, additions/deletions
`get_pull_request_diff(repo_full_name, pr_number)`	Returns per-file diffs with the raw unified diff patch

Usage

Once registered you can talk to Claude naturally:

"List all open PRs in my org" "Show me the diff for PR #42 in my-org/backend" "Review PR #15 in my-org/frontend — flag bugs and style issues"

Or use the /review-pr slash command for a guided, structured review flow.

Project Structure

pr-reviewer/
├── main.py          # MCP server — all tool definitions
├── review-pr.md     # Slash command for Claude Code (/review-pr)
├── pyproject.toml   # Project metadata and dependencies
├── uv.lock          # Pinned dependency versions
├── .python-version  # Python version pin (3.11)
└── .env.example     # Template — copy to .env for local use

Claude Desktop

If you prefer Claude Desktop instead of the CLI, add this to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "pr-reviewer": {
      "command": "/absolute/path/to/pr-reviewer/.venv/bin/python",
      "args": ["/absolute/path/to/pr-reviewer/main.py"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxx",
        "GITHUB_ORG": "your-github-org-name"
      }
    }
  }
}

Restart Claude Desktop after saving.

Development

Run the server manually to test it:

uv run python main.py

To add a new tool, define a function decorated with @mcp.tool() in main.py. FastMCP exposes it to Claude automatically.

Available Tools

4 tools

get_pull_request_detailsA

Get metadata for a specific pull request.

Returns title, description, author, changed file count, additions,
deletions, and commit count — useful for understanding PR scope before
reading the diff.

Args:
    repo_full_name: Full repo identifier in "owner/repo" format.
    pr_number: The pull request number.

ParametersJSON Schema

Name	Required	Description	Default
`repo_full_name`	Yes
`pr_number`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry the burden. It correctly states it returns metadata (read-only) but lacks details on authorization, rate limits, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences and a structured args list, no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, it lists return fields and context. Could include more on error handling, but adequate for a simple metadata tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to both parameters: 'repo_full_name' format and 'pr_number' as the number, which the schema lacks (0% coverage).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'get metadata' and names the resource 'pull request', listing returned fields. It clearly distinguishes from siblings by focusing on metadata vs diff or listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description suggests using before reading the diff, providing clear context. However, it does not explicitly state when not to use or compare alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pull_request_diffA

Get the file-by-file diff for a specific pull request.

Returns each changed file with its status (added/modified/removed),
line-level additions and deletions, and the raw unified diff patch.

Args:
    repo_full_name: Full repo identifier in "owner/repo" format.
    pr_number: The pull request number.

ParametersJSON Schema

Name	Required	Description	Default
`repo_full_name`	Yes
`pr_number`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the return structure (file status, line-level changes, raw patch) and lists the required parameters. It does not cover authentication or rate limits, but for a read-only tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a one-line purpose, a sentence on return format, and two lines for parameter comments. No wasted words, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return value. The tool is simple with two required parameters, and the description covers both input and output sufficiently. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's 'Args' section adds meaning for both parameters: repo_full_name (format 'owner/repo') and pr_number (the PR number). This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'file-by-file diff for a specific pull request', which distinguishes it from sibling tools like get_pull_request_details (likely summary) and list_open_pull_requests (list of PRs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (to get a diff), but does not explicitly state when not to use it or mention alternatives. Usage context is provided indirectly through the purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_open_pull_requestsA

List all open pull requests for a repository.

Args:
    repo_full_name: Full repo identifier in "owner/repo" format.

ParametersJSON Schema

Name	Required	Description	Default
`repo_full_name`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as pagination, result limits, or ordering. It only states the action without further details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is incomplete: it doesn't mention output format, pagination, or any constraints. For a list tool, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 0%, so the description compensates by explaining the repo_full_name parameter format (owner/repo). This adds meaningful guidance beyond the schema structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists open pull requests for a repository, using a specific verb and resource. It distinguishes from siblings like get_pull_request_details or list_org_repositories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to list open PRs for a repo) but provides no explicit guidance on when not to use it or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_org_repositoriesA

List all repositories in the configured GitHub org.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry the burden. It lacks details on behavior like pagination, rate limits, authentication, or what 'configured org' means, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, clear sentence with no wasted words; appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is simple, it omits details about the return value (e.g., what fields are returned, pagination limits) which are important for a listing tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (schema coverage 100%), and the description adds meaning by specifying the scope ('configured GitHub org'), which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'repositories in the configured GitHub org', distinguishing it from sibling tools which focus on pull requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives; no exclusions or context provided beyond the basic action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jun 23, 2026
- First observedget_pull_request_details
- First observedget_pull_request_diff
- First observedlist_open_pull_requests
- First observedlist_org_repositories

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-23 04:15 across 4 tools

Disambiguation5/5

Each tool serves a clear, non-overlapping purpose: listing repos, listing PRs, fetching PR metadata, and fetching PR diffs. No ambiguity in intent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_pull_request_details, list_open_pull_requests), making them predictable.

Tool Count5/5

4 tools is well-scoped for a PR review server, covering the essential read operations without bloat or insufficiency.

Completeness5/5

The tool set covers the full read-only PR review workflow: discover repositories, list PRs, and examine details and diffs. No obvious gaps for its intended purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,977
smithery-ai-github
ai.smithery
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Version Control Developer Tools CI/CD & DevOps
295
Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
72

Related MCP Servers

GitHub MCP Server
Version Control Developer Tools
shibdad
A
license
Not graded
quality
Not graded
maintenance
Connects Claude Desktop to GitHub repositories, enabling users to perform git operations and GitHub API interactions through natural conversation.
Updated a year ago (2025-04-26 01:34 UTC)
291 npm
-
PR Review MCP Server
Version Control Developer Tools Testing & QA Tools
IskanderAl
A
license
Not graded
quality
D
maintenance
Connects Claude to GitHub Pull Requests to fetch and filter code diffs for AI-assisted reviews. It enables listing open PRs and analyzing changes while automatically excluding binary and asset files to focus on relevant code.
Updated 7 months ago (2026-02-22 07:53 UTC)
22
MIT
ship-it-mcp
Version Control Developer Tools
jjm7271985
F
license
Not graded
quality
D
maintenance
Enables to interact with GitHub repositories directly from Claude, supporting actions like viewing repos, checking status, committing and pushing changes, and managing pull requests.
Updated 3 months ago (2026-06-13 01:03 UTC)
-
GitHub MCP Server
Version Control Developer Tools
maycwu
A
license
Not graded
quality
C
maintenance
Connects Claude to GitHub repositories for querying repos, reviewing PRs, managing issues, searching code, and automating workflows.
Updated 2 months ago (2026-07-15 20:55 UTC)
MIT

PR Reviewer MCP Server

Prerequisites

Setup

1. Clone the repository

2. Install dependencies

3. Get a GitHub Personal Access Token

4. Register the MCP server with Claude Code

5. (Optional) Install the /review-pr slash command

Available MCP Tools

Usage

Project Structure

Claude Desktop

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

5. (Optional) Install the `/review-pr` slash command