Allows listing, reading, reviewing, and commenting on GitHub pull requests, enabling automated code review and management of PRs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@github-pr-review list open pull requests"
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.
An MCP server that gives any LLM client the ability to list, read, review, and comment on GitHub pull requests — turning your AI assistant into a fully capable code reviewer.
This server wraps the GitHub REST API using FastMCP, exposing pull request operations as tools any MCP-compatible client can call. Connect it to Claude Desktop and you can ask Claude to review your open PRs, read diffs, post inline comments, approve, or request changes — all without leaving your conversation.
The server maintains a single authenticated httpx client across its lifetime, initialised on startup and shared across all tool calls via FastMCP's lifespan context.
Related MCP server: git-reviewer
Tool | Description |
| List all open PRs with author, title, draft status, and URL |
| Get file changes and unified diffs for a specific PR |
| Get all existing review comments on a PR |
| Post an inline comment on a specific file and line |
| Approve a PR with an optional review message |
| Request changes on a PR with a review message |
Note:
approve_prandrequest_changesrequire the authenticated user to be different from the PR author. GitHub does not permit self-review.
github-pr-mcp/
├── server.py # FastMCP instance, lifespan, tool registration
├── config.py # Environment variables and constants
├── tools/
│ ├── __init__.py
│ ├── prs.py # list_open_prs, get_pr_diff
│ └── reviews.py # get_pr_comments, post_review_comment, approve_pr, request_changes
├── .env # Your secrets (never committed)
├── .env.example # Template
├── requirements.txt
├── Dockerfile
└── README.mdPython 3.11+
A GitHub Personal Access Token with repo scope
1. Clone the repository:
git clone https://github.com/Festuskipkoech/github-pr-mcp.git
cd github-pr-mcp2. Install dependencies:
uv sync3. Configure your environment:
cp .env.example .envEdit .env and fill in your values:
GITHUB_TOKEN=your_personal_access_token
GITHUB_OWNER=your_github_username
GITHUB_REPO=your_repository_nameGenerate a token at GitHub Settings → Developer Settings → Personal Access Tokens. Enable full repo scope for read and write access.
uv run python server.pyOr with the FastMCP CLI on Streamable HTTP transport:
fastmcp run server.py:mcp --transport streamable-httpStart the server in one terminal:
fastmcp run server.py:mcp --transport streamable-httpLaunch the Inspector in a second terminal:
npx -y @modelcontextprotocol/inspectorIn the Inspector UI:
Transport: Streamable HTTP
URL: http://127.0.0.1:8000/mcp
Click Connect
Recommended test sequence:
Step | Tool | Input |
1 |
| (no arguments) |
2 |
|
|
3 |
|
|
4 |
|
|
Add the following to ~/.config/Claude/claude_desktop_config.json:
{
"mcpServers": {
"github-pr-review": {
"command": "/home/your-user/.local/bin/uv",
"args": [
"run",
"--directory",
"/absolute/path/to/github-pr-mcp",
"python",
"server.py"
]
}
}
}Use the full path to uv (find it with which uv). Credentials are read from the .env file automatically — no need to pass them in the config.
Restart Claude Desktop, then try:
List all open pull requests in my repo and show me the diff for PR number 1Claude calls list_open_prs and get_pr_diff and returns structured results:
Full PR diff and file changes returned inline:
docker build -t github-pr-mcp .
docker run --env-file .env -p 8000:8000 github-pr-mcpFor Streamable HTTP transport, update server.py to run with:
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)Error | Cause | Fix |
| Invalid or expired token | Regenerate PAT on GitHub |
| Token lacks write scope | Enable full |
| Wrong owner or repo name | Check |
| Self-review attempt | GitHub blocks approving your own PRs by design |
Approve a pull request, optionally with a review message.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | An optional message to include with the approval. | |
| pr_number | Yes | The pull request number to approve. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It fails to mention side effects, required permissions, or the fact that the message parameter is actually required despite being described as optional. This inconsistency reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but it omits important details and contains an inconsistency. It is not well-structured for an agent to infer correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, output schema exists), the description is minimal but lacks guidance on return values or edge cases. The contradiction between description and schema further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description contradicts the schema: the message is described as optional but is required in the schema. This confusion overrides the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (approve) and resource (pull request), and mentions the optional message. It distinguishes from siblings like request_changes and post_review_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., request_changes or post_review_comment). No context on prerequisites or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all review comments on a specific pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_number | Yes | The pull request number to retrieve comments for. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'get all review comments' without disclosing behaviors like idempotency, resolved/unresolved status, pagination, or whether it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that front-loads the purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema (not shown), the description is adequate. It does not cover pagination or filtering but the low complexity makes it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (pr_number) is described in the schema with 'The pull request number to retrieve comments for.' The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'all review comments on a specific pull request', which is distinct from sibling tools like approve_pr, get_pr_diff, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need all comments for a given PR. No explicit exclusions or alternatives are provided, but the simplicity of the tool makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the file changes and diff for a specific pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_number | Yes | The pull request number to retrieve the diff for. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only repeats the purpose without adding any details about rate limits, authentication, side effects, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is efficient and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is minimally adequate. It does not mention prerequisites or context, but it is complete enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 changes and diff for a specific pull request.' It distinguishes from siblings like approve_pr and get_pr_comments, which handle different aspects of pull requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when a user needs the diff of a pull request. However, it does not explicitly state when not to use it or compare it to alternatives like get_pr_comments for comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open pull requests in the configured repository.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a read operation with no side effects, but lacks details on authorization, rate limits, pagination, or behavior when no PRs exist. The description is minimal and offers no extra behavioral context beyond the obvious read action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the essential purpose with no wasted words. It is front-loaded and efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema exists (though not shown). The description is adequate for the straightforward task. It could optionally mention that the output is a list of PRs, but the output schema likely covers that. Overall, it provides the necessary information to understand what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters). Per the guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information because none is needed. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('open pull requests'), and the scope ('in the configured repository'). The tool name also aligns perfectly with its purpose, and the sibling tools (approve, comment, diff) are distinct actions, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. However, the purpose is intuitive given the sibling tools; it implies usage when a list of open PRs is needed, but no explicit when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post an inline comment on a specific file and line via a review submission.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The text content of the comment. | |
| line | Yes | The line number in the file to attach the comment to. | |
| path | Yes | The relative file path to comment on. | |
| pr_number | Yes | The pull request number to comment on. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether it creates a pending review, submits immediately, or requires permissions. Missing behavioral details like side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the core action and parameters. Output schema exists but not needed here. For a simple tool with 4 params, description is nearly complete; lacks only minor behavioral clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have descriptions in the input schema (100% coverage). The description adds no new meaning beyond consolidating the schema info. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (post), the resource (inline comment), and the specifics (file, line, via review submission). It distinguishes from sibling tools like get_pr_comments or approve_pr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives like request_changes. Usage is implied by context (PR review), but no exclusions or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request changes on a pull request with a review message.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The review message explaining what changes are needed. | |
| pr_number | Yes | The pull request number to request changes on. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only says 'request changes' without disclosing behavioral traits like whether it creates a review, blocks merging, or is reversible. No return value information is provided despite an output schema being present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action. However, it may be overly brief for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description is insufficient. It lacks context about the effect of the action, prerequisites, or what the response contains. A mutation tool should provide more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the parameter names and types. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests changes on a pull request with a review message. The verb 'request changes' is specific and distinct from sibling tools like approve_pr or post_review_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., post_review_comment or approve_pr). The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0approve_prget_pr_commentsget_pr_difflist_open_prspost_review_commentrequest_changesEach tool has a clearly distinct purpose: listing PRs, getting diffs, getting comments, posting inline comments, approving, and requesting changes. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., approve_pr, get_pr_diff), making them predictable and easy to distinguish.
Six tools is an ideal size for a focused PR review server, covering the essential actions without being overwhelming or sparse.
The set covers the core PR review workflow (list, diff, comments, approve, request changes) but lacks features like merging or dismissing reviews, which are minor gaps given the server's specific scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Festuskipkoech/github-pr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
