How do I use mcp-review-pr?

1. Click on "Install 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., "@mcp-review-pr Review my current pull request" 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.

mcp-review-pr

by thangtn83

Overview Schema Related Servers Score Discussions

TypeScript

mcp-review-pr

An MCP (Model Context Protocol) server for multi-language PR review with deterministic analysis. It provides AI-powered code review tools that automatically detect languages, apply relevant review guidelines, and run quality checks on your pull requests.

✨ Features

Skill-Based Architecture — Modular review skills that auto-activate based on file types, path patterns, and content detection
Deterministic Quality Checks — Run linters and tests as part of the review pipeline, not just AI suggestions
Impact Analysis — Classify changes by architectural layer (UI, domain, infra, shared) and detect breaking changes
Smart Diff Chunking — Automatically splits large PRs into prioritized chunks for incremental review
Result Caching — Cache diff results and guidelines keyed by commit SHA for fast re-runs
Custom Rules — Layer project-specific rules on top of skill-provided guidelines via a simple rules.md file
Configurable — Tune behavior with .mcp.config.json (ignored files, risk thresholds, max diff size, etc.)

Related MCP server: pr-mcp-server

📦 Built-in Skills

Skill	Priority	Activates On	Linter
Security	15	`.ts`, `.js`, `.tsx`, `.jsx`, `.mjs` + `api/`, `auth/`, `middleware/` paths	—
React	10	`.tsx`, `.jsx` + React imports + `components/`, `pages/`, `app/` paths	ESLint
TypeScript	8	`.ts`, `.mts`, `.cts`	ESLint
Clean Architecture	7	`.ts`, `.js`, `.tsx`, `.jsx` + `domain/`, `usecases/`, `services/`, `repositories/`, etc.	—
JavaScript	5	`.js`, `.mjs`, `.cjs`	ESLint

Skills are activated automatically when PR diffs match their criteria. Multiple skills can be active simultaneously — their guidelines and rules are merged by priority.

🛠 MCP Tools

The server exposes the following tools via the MCP protocol:

Tool	Description
`get_pr_diff`	Get structured file diffs with additions, deletions, and change types
`analyze_impact`	Classify changes by layer, detect breaking changes, assign risk level
`list_skills`	List all available skills and which ones are active for the current PR
`get_skill_guidelines`	Get merged review guidelines from all active skills + custom rules
`load_rules`	Load all applicable rules (skill rules + custom repo rules)
`run_quality_checks`	Run skill linters and test suites, returns lint issues and test results
`generate_review`	Full structured PR review combining all tools into a comprehensive `ReviewOutput`

🚀 Getting Started

Prerequisites

Node.js ≥ 18
npm

Installation

npm install

Build

npm run build

Running as MCP Server

Start the server over stdio transport (for integration with MCP-compatible clients):

# Using the compiled output
npm start

# Or during development
npm run dev

Then configure your MCP client to connect via stdio. For example, in your MCP client config:

{
  "mcpServers": {
    "review-pr": {
      "command": "node",
      "args": ["/path/to/mcp-review-pr/dist/server.js"]
    }
  }
}

Running as CLI

The CLI provides standalone usage without an MCP client:

# Review the current repository
npx mcp-review

# Compare against a specific branch
npx mcp-review --base develop

# List available skills and which are active
npx mcp-review --mode skills

# Show active guidelines for your PR
npx mcp-review --mode guidelines

# Analyze impact only
npx mcp-review --mode impact

# Output as markdown instead of JSON
npx mcp-review --format markdown

# Use custom skills directory
npx mcp-review --skills-dir ./my-skills

CLI Options

Option	Alias	Description	Default
`--repo <path>`	`-r`	Repository path	Current directory
`--base <branch>`	`-b`	Base branch to diff against	`main`
`--skills-dir <path>`	`-s`	Custom skills directory	Built-in skills
`--format <type>`	`-f`	Output format: `json` or `markdown`	`json`
`--mode <mode>`	`-m`	Mode: `review`, `skills`, `guidelines`, `impact`, `server`	`review`
`--help`	`-h`	Show help	—

⚙️ Configuration

Create a .mcp.config.json in your repository root to customize behavior:

{
  "productionBranches": ["main", "production"],
  "maxDiffLines": 5000,
  "failOnRiskLevel": "high",
  "ignoreFiles": ["package-lock.json", "yarn.lock", "pnpm-lock.yaml"],
  "enableCaching": true
}

Option	Type	Default	Description
`productionBranches`	`string[]`	`["main", "production"]`	Branches considered production
`maxDiffLines`	`number`	`5000`	Max diff lines per review chunk
`failOnRiskLevel`	`string`	`"high"`	Risk level threshold to flag
`ignoreFiles`	`string[]`	Lock files	Files to exclude from review
`enableCaching`	`boolean`	`true`	Enable diff/guideline caching

Custom Rules

Add a rules.md file to your repository root with project-specific review rules:

- All API endpoints must validate input with Zod schemas
- Database queries must use parameterized statements
- Components must have display names for debugging

These rules are merged with skill-provided rules during review.

🧩 Creating Custom Skills

Skills are directories containing three files. Place them in the skills/ directory (or a custom directory via --skills-dir):

skills/
└── my-skill/
    ├── skill.json      # Manifest (required)
    ├── guideline.md    # Review guidelines
    └── rules.md        # Checklist rules

`skill.json` — Manifest

{
  "name": "my-skill",
  "description": "Description of what this skill reviews",
  "version": "1.0.0",
  "filePatterns": ["**/*.py"],
  "activateOn": {
    "extensions": [".py"],
    "fileContains": ["import django"],
    "pathPatterns": ["views/", "models/"]
  },
  "priority": 8,
  "linter": {
    "command": "npx",
    "args": ["pylint", "--output-format", "json"],
    "fileExtensions": [".py"]
  }
}

Field	Required	Description
`name`	✅	Unique skill identifier
`description`	—	Human-readable description
`version`	—	Semantic version
`filePatterns`	—	Glob patterns for relevant files
`activateOn`	✅	Activation criteria (see below)
`priority`	—	Higher = evaluated first (default: 0)
`linter`	—	Optional linter configuration

Activation criteria (any match triggers activation):

extensions — File extensions in the diff (e.g., [".ts", ".tsx"])
fileContains — Strings found in diff content (e.g., ["from 'react'"])
pathPatterns — Path substrings in changed files (e.g., ["components/"])

`guideline.md` — Review Guidelines

Free-form markdown that provides context and best practices for the reviewer. This is included in the review context when the skill is active.

`rules.md` — Review Rules

A markdown list of specific, checkable rules:

- Use strict type annotations, avoid `any`
- Prefer `const` over `let` where possible
- All exported functions must have JSDoc comments

🏗 Architecture

src/
├── server.ts         # MCP server — registers all tools
├── cli.ts            # CLI entry point with argument parsing
├── config.ts         # .mcp.config.json loader
├── types.ts          # Shared TypeScript types
├── cache.ts          # Diff and guideline caching (SHA-keyed)
├── chunker.ts        # Smart diff chunking with priority ordering
├── retry.ts          # Exponential backoff utility
├── skills/
│   ├── index.ts      # Public API re-exports
│   ├── types.ts      # Skill manifest & runtime types
│   ├── loader.ts     # Skill discovery, activation, guideline/rule loading
│   └── runner.ts     # Skill linter execution
└── tools/
    ├── diff.ts       # Git diff extraction via simple-git
    ├── impact.ts     # Change impact & risk analysis
    ├── quality.ts    # Lint + test orchestration
    ├── review.ts     # Structured review generation
    └── rules.ts      # Custom rules.md loader

📜 Scripts

Script	Description
`npm run build`	Compile TypeScript to `dist/`
`npm run dev`	Run in development mode (via `tsx`)
`npm start`	Start the compiled MCP server
`npm test`	Run tests (Vitest)
`npm run test:watch`	Run tests in watch mode
`npm run typecheck`	Type-check without emitting
`npm run lint`	Lint source files with ESLint

📄 License

MIT

Available Tools

3 tools

generate_reviewB

Generate a complete structured PR review. Runs all analysis tools (diff, impact, skills, quality) and produces a comprehensive ReviewOutput.

ParametersJSON Schema

Name	Required	Description
`repoPath`	Yes	Absolute path to the git repository
`skillsDir`	No
`baseBranch`	No

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden but fails to disclose behavioral traits like side effects, resource usage, or rate limits. It only states it runs analysis tools.

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 a single, clear sentence with no wasted words, effectively summarizing the tool's function.

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 no output schema and low parameter coverage, the description lacks details about the ReviewOutput, return format, and parameter usage, leaving the agent underinformed.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description adds no parameter meaning beyond the schema. Key parameters like skillsDir and baseBranch remain undocumented.

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

Purpose4/5

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

The description clearly states the tool generates a complete structured PR review and runs all analysis tools, distinguishing it from more specific sibling tools like run_quality_checks.

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 use for comprehensive reviews but does not explicitly specify when to use this tool versus alternatives or when not to use it.

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

load_rulesC

Load all applicable rules: skill-specific rules for active skills plus custom repo rules from rules.md.

ParametersJSON Schema

Name	Required	Description
`repoPath`	Yes	Absolute path to the git repository
`skillsDir`	No
`baseBranch`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavior. It only states it loads rules without indicating side effects, permissions, or whether it is read-only. The lack of behavioral detail is a significant gap.

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

Conciseness4/5

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

The description is a single concise sentence with no redundant information. It is front-loaded and efficient, earning its place.

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?

For a tool with 3 parameters, no output schema, and moderate complexity, the description is incomplete. It does not explain the output format, how active skills are determined, or the role of parameters like skillsDir and baseBranch.

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

Parameters2/5

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

The description does not explain any parameters beyond what is in the schema. With schema coverage at 33% (only repoPath described), the description should compensate but fails to add meaning to skillsDir or baseBranch.

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

Purpose4/5

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

The description clearly states the tool loads rules, specifying two sources: skill-specific rules for active skills and custom repo rules from rules.md. This provides a specific verb and resource, though it does not explicitly distinguish from sibling tools like run_quality_checks and generate_review.

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 is given on when to use this tool versus alternatives like run_quality_checks or generate_review. The description does not mention context, prerequisites, or exclusions.

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

run_quality_checksB

Run deterministic quality checks: skill linters (ESLint, etc.) and test suite. Returns lint issues and test results.

ParametersJSON Schema

Name	Required	Description
`repoPath`	Yes	Absolute path to the git repository
`skillsDir`	No
`baseBranch`	No

TDQS

B3.4/5.0

Behavior3/5

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 discloses that checks are deterministic and returns lint issues and test results, but does not mention whether the tool has side effects, requires permissions, or has rate limits. The description is adequate but not comprehensive for a mutation-like tool.

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 with no extraneous information. The first sentence clearly states the purpose, and the second specifies the return value. Every sentence earns its place.

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 tool with 3 parameters, no output schema, and no annotations, the description is somewhat complete in stating purpose and return value, but lacks detail on parameters and usage context. It does not differentiate from siblings or provide enough information for an agent to use it correctly in all scenarios.

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

Parameters2/5

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

Schema coverage is only 33% (only repoPath has a description). The description does not explain the roles of skillsDir or baseBranch, leaving two parameters effectively undocumented. The description adds minimal value beyond the schema for parameter understanding.

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 'run', the resource 'quality checks', and specifies the types of checks (skill linters and test suite). It distinguishes from sibling tools (load_rules, generate_review) by focusing on running checks rather than loading rules or generating reviews.

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 is given on when to use this tool versus alternatives, or when not to use it. The description only states what it does, leaving the agent without context for appropriate invocation.

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.

3 tool updatesv1.0.0Jul 26, 2026
- First observedgenerate_review
- First observedload_rules
- First observedrun_quality_checks

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: load_rules handles loading rules, run_quality_checks performs deterministic checks, and generate_review produces the final review. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: load_rules, run_quality_checks, generate_review.

Tool Count5/5

Three tools is ideal for a focused PR review server; each tool has a clear role without being too few or too many.

Completeness5/5

The tool set covers the full workflow: loading rules, running quality checks, and generating a comprehensive review. No obvious gaps for the intended domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622
saidsef-mcp-github-pr-issue-analyser
ai.smithery
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Version Control Developer Tools Project Management
26
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2

Related MCP Servers

Cursor Auto-Review MCP Server
Developer Tools Version Control Testing & QA Tools
dev-prajwal
F
license
Not graded
quality
D
maintenance
An MCP server that automates code reviews through linting, testing, and git diff analysis. It also generates conventional commit messages and detailed pull request descriptions based on file changes and code patterns.
Updated 8 months ago (2026-01-02 07:01 UTC)
-
pr-mcp-server
Version Control Code Analysis Developer Tools
valentin-harrang
A
license
A
quality
D
maintenance
MCP server to automate Pull Request creation with AI. Analyzes Git branches, generates descriptions, titles, suggests reviewers, and performs code reviews.
Updated 10 months ago (2025-10-30 15:17 UTC)
8
4
MIT
code-reviewer-mcp
Developer Tools Code Analysis
ArthDh
A
license
Not graded
quality
D
maintenance
An MCP server that performs automated code reviews by analyzing git diffs against configurable review standards with custom reviewer personas.
Updated 7 months ago (2026-02-04 17:34 UTC)
2
MIT
code-review-automation
Testing & QA Tools Code Analysis
KennyWayn3
A
license
Not graded
quality
B
maintenance
MCP server for automated code review using AI agents. It analyzes code diffs or file paths for bugs, security issues, and style violations.
Updated 2 months ago (2026-07-11 07:32 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/thangtn83/mcp_pr_review'

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

mcp-review-pr

✨ Features

📦 Built-in Skills

🛠 MCP Tools

🚀 Getting Started

Prerequisites

Installation

Build

Running as MCP Server

Running as CLI

CLI Options

⚙️ Configuration

Custom Rules

🧩 Creating Custom Skills

skill.json — Manifest

guideline.md — Review Guidelines

rules.md — Review Rules

🏗 Architecture

📜 Scripts

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`skill.json` — Manifest

`guideline.md` — Review Guidelines

`rules.md` — Review Rules