Skip to main content
Glama
thicapistrano

GitHub Code Reviewer

by thicapistrano
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

MCP GitHub Code Reviewer

An MCP (Model Context Protocol) server that gives Claude the ability to fetch Pull Request diffs from GitHub and post inline code review comments directly on the PR — either as a pending draft for you to approve, or published immediately.

How it works

You (Claude Code) ──► MCP Server (src/index.ts) ──► GitHub API
                           │
                     Two tools + two prompts exposed:
                     • get_pull_request_diff
                     • post_pr_review_comment
                     • review_pr (prompt — guided)
                     • review_pr_auto (prompt — autonomous)

When running as an MCP server, Claude can call these tools in response to natural language prompts. You describe which PR to review, and Claude fetches the diff, analyzes the code, and posts structured inline comments.

You can also use the built-in review_pr prompt to give Claude step-by-step instructions automatically — no need to describe the process manually each time.

Related MCP server: Bitbucket MCP Server

Prompts available

There are two prompts, each with a different review style:

review_pr — guided review

Instructs Claude to follow a fixed step-by-step process: fetch the diff, analyze it across specific categories, and post inline comments.

Parameter

Type

Required

Description

owner

string

yes

GitHub username or organization

repo

string

yes

Repository name

pull_number

number

yes

PR number

status

string

no

PENDING (default) or PUBLIC

The prompt instructs Claude to focus on:

  • Bugs and logic errors

  • Security vulnerabilities

  • Performance issues

  • Code style and readability

  • Missing error handling

review_pr_auto — autonomous review

Just fetches the diff and lets the LLM review freely using its own judgment — no rigid checklist.

Parameter

Type

Required

Description

owner

string

yes

GitHub username or organization

repo

string

yes

Repository name

pull_number

number

yes

PR number

status

string

no

PENDING (default) or PUBLIC

Tools available

get_pull_request_diff

Fetches the raw diff of a Pull Request from GitHub.

Parameter

Type

Description

owner

string

GitHub username or organization

repo

string

Repository name

pull_number

number

PR number

post_pr_review_comment

Posts an inline review comment on a specific line of a changed file.

Parameter

Type

Description

owner

string

GitHub username or organization

repo

string

Repository name

pull_number

number

PR number

path

string

File path (e.g. src/app.js)

line

number

Line number where the comment will appear

body

string

Comment text in Markdown

status

string

PENDING saves as a draft (you publish on GitHub); PUBLIC submits immediately

Prerequisites

  • Node.js 18+

  • A GitHub Personal Access Token with repo scope

  • Claude Code (to use as an MCP server)

Installation

npm install

Configuration

Create a .env file in the project root:

GITHUB_TOKEN=ghp_YourGitHubTokenHere

Running as an MCP server (Claude Code)

Add this server to your Claude Code MCP configuration (~/.claude/claude_desktop_config.json or via claude mcp add):

{
  "mcpServers": {
    "github-code-reviewer": {
      "command": "npx",
      "args": ["tsx", "/path/to/mcp-github-reviewer/src/index.ts"],
      "env": {
        "GITHUB_TOKEN": "ghp_YourGitHubTokenHere"
      }
    }
  }
}

Or start the server manually:

npx -y @modelcontextprotocol/inspector@latest --mode cli npx tsx src/index.ts

Example usage

Guided review (step-by-step):

Use the prompt review_pr with owner="seu-usuario", repo="seu-repo", pull_number=42

Autonomous review (LLM decides):

Use the prompt review_pr_auto with owner="seu-usuario", repo="seu-repo", pull_number=42

Publish comments immediately:

Use the prompt review_pr with owner="seu-usuario", repo="seu-repo", pull_number=42, status="PUBLIC"

Manual prompt (without using any built-in prompt):

Review the PR 360 in seu-usuario/seu-repositorio and use post_pr_review_comment with status: "PENDING" so I can double-check everything on GitHub before publishing.

Project structure

mcp-github-reviewer/
├── src/
│   └── index.ts      # MCP server — exposes tools to Claude
├── package.json
├── tsconfig.json
└── .env              # GITHUB_TOKEN goes here

Dependencies

Package

Role

@modelcontextprotocol/sdk

MCP server framework

@octokit/rest

GitHub API client

dotenv

Loads .env variables

tsx

Runs TypeScript directly without a build step

Available Tools

2 tools
get_pull_request_diffA

Fetches the code changes (diff) of a specific Pull Request for analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesRepository name
ownerYesRepository owner
pull_numberYesPull Request number

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, and the description only states it fetches diff. Does not disclose any behavioral traits like rate limits, authentication, size limits, or return format. Insufficient for a read operation.

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 sentence, front-loaded with key action and purpose. No wasted words.

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 tool simplicity (3 simple params, no output schema), the description is adequate. Could mention output format (e.g., unified diff) but not critical.

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

Parameters3/5

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

Schema coverage is 100%, so parameters are fully defined in schema. Description adds no extra meaning beyond what schema provides, so baseline 3 is appropriate.

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?

Describes exactly what the tool does: fetches the diff of a specific PR. Differentiates from sibling 'post_pr_review_comment' which is a write action.

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?

No explicit guidance on when to use or when not to use. The purpose implies it's for analyzing the diff, but lacks comparison with alternatives or prerequisites.

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

post_pr_review_commentA

Posts a code review comment on a specific line of a file changed in the PR. All comments must be written in English.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesThe review comment in Markdown with suggestions. MUST be written in English.
lineYesThe line number in the file where the comment should be placed
pathYesFile path (e.g. src/app.js)
repoYes
ownerYes
statusYesDefines whether the comment should be published immediately ('PUBLIC') or created as a draft review pending user approval ('PENDING').
pull_numberYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. Only states posting action and language requirement. Lacks details on effects, authentication, rate limits, error handling, or whether comment is immediately visible beyond status parameter.

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?

Two sentences, concise, front-loaded with action then constraint. No unnecessary words.

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?

For a mutation tool with 7 required params and no annotations or output schema, description should cover more context like input expectations, response behavior, and usage restrictions. Currently only covers basic action and language constraint.

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

Parameters3/5

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

Schema coverage is 57%. Description adds no parameter-level detail beyond reinforcing body language. Owner, repo, pull_number are standard but undocumented. Description does not compensate for missing param 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?

Clearly states verb 'posts' and resource 'code review comment on a specific line of a file changed in the PR'. Distinct from sibling tool get_pull_request_diff which retrieves diffs.

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?

Implies use when wanting to post a comment, but no explicit guidance on when to use vs alternative (get_pull_request_diff) or prerequisites. Mentions language constraint but not tool selection context.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.0
    • First observedget_pull_request_diff
    • First observedpost_pr_review_comment
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one fetches the diff of a PR, the other posts a review comment. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern in snake_case: 'get_pull_request_diff' and 'post_pr_review_comment'. No inconsistencies.

Tool Count3/5

With only 2 tools, the server feels thin for a code reviewer. While the tools are focused, a typical code review workflow would benefit from additional tools like listing PRs or getting PR details.

Completeness2/5

The tool surface is incomplete for a code reviewer: it lacks CRUD operations for PRs, file listing, approval/request changes, and other common actions. Agents would face dead ends without these.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thicapistrano/mcp-github-reviewer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server