How do I use code-review-mcp?

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., "@code-review-mcp analyze the code quality of src/main.py" 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.

code-review-mcp

by AlanNiew

Overview Schema Related Servers Score Discussions

Python

Local

ai-code-review-mcp

一个基于 MCP（Model Context Protocol）的代码质量审查服务器，为 AI 编码助手（如 OpenCode、Claude Desktop、Cursor 等）提供本地代码分析能力。

PyPI: https://pypi.org/project/ai-code-review-mcp/ GitHub: https://github.com/AlanNiew/code-review-mcp

特性

文件分析 — 检测函数复杂度、行数统计、代码风格问题
Diff 审查 — 审查 git 未提交的变更，发现调试代码和潜在密钥泄露
项目扫描 — 一键扫描整个项目的代码质量概况
质量评分 — 多维评分（总分 / 安全 / 可维护性）A-F 等级
21 条规则 — 12 条安全规则（SEC001-SEC012）+ 5 条复杂度规则（COMPLEX001-005）+ 4 条风格规则（STYLE001-004）
认知复杂度 — 业界领先的人脑理解难度算法（SonarSource 白皮书实现）
配置文件 — .code-review.yml 自定义规则开关、阈值、忽略路径
行级豁免 — # codereview: ignore 灵活豁免误报
多语言支持 — Python 深度分析（AST）+ 通用质量检查（JS/TS/Java/Go/Rust 等）
配套 Skill — 提供标准化的代码审查工作流提示词
零外部依赖 — 仅依赖 mcp 包；YAML 配置可选装 PyYAML

Related MCP server: code-review-mcp-server

安装

pip install ai-code-review-mcp

要求 Python 3.10+

使用教程

一、OpenCode（推荐）

OpenCode 是一个开源 AI 编码助手，原生支持 MCP 和 Skill。

步骤 1：安装 MCP 服务器

pip install ai-code-review-mcp

步骤 2：配置 OpenCode

在项目根目录创建或编辑 opencode.json，添加以下内容：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "code-review-mcp": {
      "type": "local",
      "command": ["ai-code-review-mcp"],
      "enabled": true
    }
  }
}

步骤 3：安装配套 Skill（可选，推荐）

Skill 提供标准化的代码审查工作流，让 AI 按规范流程调用 MCP 工具。

从 GitHub 下载 Skill 文件：

# 方式一：复制到项目级目录（仅当前项目生效）
mkdir -p .opencode/skills/code-review
curl -o .opencode/skills/code-review/SKILL.md https://raw.githubusercontent.com/AlanNiew/code-review-mcp/main/skill/SKILL.md

# 方式二：复制到全局目录（所有项目生效）
mkdir -p ~/.config/opencode/skills/code-review
curl -o ~/.config/opencode/skills/code-review/SKILL.md https://raw.githubusercontent.com/AlanNiew/code-review-mcp/main/skill/SKILL.md

Windows 用户手动创建：

# 项目级
New-Item -ItemType Directory -Path ".opencode\skills\code-review" -Force
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/AlanNiew/code-review-mcp/main/skill/SKILL.md" -OutFile ".opencode\skills\code-review\SKILL.md"

# 全局级
New-Item -ItemType Directory -Path "$env:USERPROFILE\.config\opencode\skills\code-review" -Force
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/AlanNiew/code-review-mcp/main/skill/SKILL.md" -OutFile "$env:USERPROFILE\.config\opencode\skills\code-review\SKILL.md"

步骤 4：开始使用

启动 OpenCode 后，直接在对话中使用：

帮我分析 src/main.py 的代码质量

审查一下当前未提交的代码变更

使用 code-review 技能，扫描项目整体代码质量

二、Claude Desktop

步骤 1：安装 MCP 服务器

pip install ai-code-review-mcp

步骤 2：编辑配置文件

打开 Claude Desktop 配置文件：

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

添加以下内容：

{
  "mcpServers": {
    "code-review-mcp": {
      "command": "ai-code-review-mcp"
    }
  }
}

步骤 3：重启 Claude Desktop

重启后，Claude 会自动加载 MCP 工具，你可以在对话中直接使用：

帮我审查一下 src/utils.py 的代码质量

三、Cursor

步骤 1：安装 MCP 服务器

pip install ai-code-review-mcp

步骤 2：配置 Cursor

打开 Cursor 设置 → MCP，添加一个新的 MCP Server：

Type: command
Command: ai-code-review-mcp

或者在 .cursor/mcp.json 中添加：

{
  "mcpServers": {
    "code-review-mcp": {
      "command": "ai-code-review-mcp"
    }
  }
}

四、使用 uvx 运行（无需 pip install）

如果你使用 uv，可以跳过安装步骤，直接运行：

OpenCode 配置：

{
  "mcp": {
    "code-review-mcp": {
      "type": "local",
      "command": ["uvx", "ai-code-review-mcp"],
      "enabled": true
    }
  }
}

Claude Desktop 配置：

{
  "mcpServers": {
    "code-review-mcp": {
      "command": "uvx",
      "args": ["ai-code-review-mcp"]
    }
  }
}

五、从源码运行（开发者）

git clone https://github.com/AlanNiew/code-review-mcp.git
cd code-review-mcp
pip install -e .

然后在配置中使用：

{
  "mcp": {
    "code-review-mcp": {
      "type": "local",
      "command": ["python", "-m", "code_review_mcp.server"],
      "enabled": true
    }
  }
}

提供的工具

v0.2.0 新增了 list_rules 工具，可在对话中查询所有已注册规则。

1. `analyze_file` — 分析单个文件

分析文件的代码质量、复杂度和安全问题。

示例对话：

帮我分析 src/main.py 的代码质量

返回内容：

语言类型、代码/注释/空白行数
问题列表（21 条规则适用时全部触发）
多维质量评分：overall / security / maintainability（A-F 等级）

2. `review_diff` — 审查 git 变更

审查当前仓库中未提交的变更（staged + unstaged）。

示例对话：

审查一下当前未提交的代码变更

检测内容：

硬编码的密钥或密码（严重）
遗留的 print() / console.log() 调试语句
新增的 TODO/FIXME 标记
过长的代码行

3. `check_project` — 扫描项目概况

扫描整个项目的代码质量。

示例对话：

扫描一下项目整体代码质量

返回内容：

文件总数和总行数、错误/警告/提示计数
语言分布统计
问题最多的前 10 个文件
项目整体质量评分（A-F 等级）

4. `list_rules` — 查询规则清单（v0.2.0 新增）

返回所有已注册规则的元信息（ID、名称、描述、类别、严重级别、适用语言）。

示例对话：

列出所有代码审查规则

规则参考

安全规则（SEC001-SEC012）

借鉴 bandit 的 AST 节点分发模式，针对 Python。

规则 ID	名称	严重级别	检测目标
SEC001	eval-exec	🔴 error	`eval()` / `exec()` 任意代码执行
SEC002	shell-injection	🔴 error	`subprocess(shell=True)` / `os.system` 命令注入
SEC003	unsafe-deserialize	🔴 error	`pickle.loads` / `yaml.load` 不安全反序列化
SEC004	weak-hash	🟡 warning	`hashlib.md5` / `sha1` 弱哈希
SEC005	hardcoded-secret	🔴 error	硬编码密码 / API Key
SEC006	ssl-verify-false	🔴 error	`requests(verify=False)` 关闭 SSL 校验
SEC007	bare-except	🟡 warning	bare except / `except: pass` 吞异常
SEC008	sql-injection	🟡 warning	SQL 字符串拼接
SEC009	assert-in-production	🔵 info	生产代码中的 `assert`
SEC010	flask-debug	🔴 error	Flask `debug=True`
SEC011	jwt-no-verify	🔴 error	JWT 关闭签名校验
SEC012	weak-random	🟡 warning	安全场景使用 `random` 而非 `secrets`

复杂度规则（COMPLEX001-005）

规则 ID	名称	严重级别	默认阈值
COMPLEX001	function-too-long	🟡 warning	函数 > 50 行
COMPLEX002	cyclomatic-complexity	🟡 warning	圈复杂度 > 10
COMPLEX003	cognitive-complexity	🟡 warning	认知复杂度 > 15（SonarSource 白皮书）
COMPLEX004	too-many-params	🔵 info	参数 > 5 个
COMPLEX005	nesting-too-deep	🟡 warning	嵌套 > 4 层

风格规则（STYLE001-004）

规则 ID	名称	严重级别	检测目标
STYLE001	line-too-long	🟡 warning	单行 > 120 字符
STYLE002	todo-comment	🔵 info	注释中的 TODO/FIXME/HACK/XXX
STYLE003	trailing-whitespace	🔵 info	行末空白字符
STYLE004	debug-print	🔵 info	`print` / `console.log` 调试残留

配置文件（v0.2.0 新增）

在项目根目录创建 .code-review.yml、.code-review.yaml 或 .code-review.json 即可自定义行为。（YAML 需要可选依赖 pip install ai-code-review-mcp[yaml]）

.code-review.json 示例：

{
  "rules": {
    "security": { "enabled": true },
    "complexity": { "enabled": true },
    "style": { "enabled": true }
  },
  "thresholds": {
    "max_function_length": 80,
    "max_cognitive_complexity": 20,
    "max_line_length": 100
  },
  "ignore_paths": [
    "tests/*",
    "vendor/",
    "migrations/",
    "*_pb2.py"
  ],
  "severity_overrides": {
    "SEC009": "warning"
  }
}

配置项说明：

字段	类型	说明
`rules.<category>.enabled`	bool	关闭整类规则（如 `rules.style.enabled = false`）
`thresholds.<key>`	int	自定义阈值（见复杂度规则表）
`ignore_paths`	list	路径忽略列表（fnmatch glob + 目录前缀）
`severity_overrides`	dict	覆盖单条规则的默认严重级别

配置查找顺序：

环境变量 CODE_REVIEW_CONFIG 指定的路径（最高优先级）
从当前目录向上递归查找 .code-review.{yml,yaml,json}
内置默认配置

行级豁免（v0.2.0 新增）

借鉴 # noqa / # nosec 的设计，你可以针对单行豁免规则：

# 豁免当前行的所有规则
token = "hardcoded-for-dev-only-1234567890"  # codereview: ignore

# 只豁免指定规则
password = "test1234"  # codereview: ignore=SEC005

豁免标记大小写不敏感，可以放在行内任意位置。

质量评分算法

多维评分（v0.2.0 新增）

每个分析结果包含 3 个独立维度的评分：

维度	包含的类别	用途
overall	所有 issue	综合质量画像
security	仅 `security` 类	安全风险隔离（"代码漂亮但有 SQL 注入"也能被识别）
maintainability	`complexity` / `style` / `debug_code` / `duplication`	可维护性画像

严重级别权重

严重程度	单项扣分	说明
Error	10 分	必须修复（如硬编码密钥）
Warning	3 分	建议修复（如函数过长）
Info	0.5 分	可选优化（如 TODO 标记）

基础分 100，扣完为止。等级划分（借鉴 DeepSource）：

评分	等级	含义
≥ 90	A	优秀
≥ 80	B	良好
≥ 70	C	合格
≥ 60	D	较差
< 60	F	不合格

支持的语言

语言	文件分析	复杂度分析
Python (.py)	✅	✅ AST 深度分析
JavaScript (.js/.jsx)	✅	通用检查
TypeScript (.ts/.tsx)	✅	通用检查
Java (.java)	✅	通用检查
Go (.go)	✅	通用检查
Rust (.rs)	✅	通用检查
C/C++ (.c/.cpp/.h)	✅	通用检查
Ruby (.rb)	✅	通用检查
PHP (.php)	✅	通用检查
Swift (.swift)	✅	通用检查
Kotlin (.kt)	✅	通用检查
Scala (.scala)	✅	通用检查

项目结构

code-review-mcp/
├── pyproject.toml                    # Python 包配置（含 ruff/pytest 配置）
├── README.md                         # 本文件
├── CHANGELOG.md                      # 变更记录
├── LICENSE                           # MIT 许可证
├── .github/workflows/
│   ├── ci.yml                        # CI：多版本矩阵 + ruff + pytest
│   └── publish.yml                   # 自动发布 PyPI + GitHub Release
├── skill/
│   └── SKILL.md                      # 配套的 OpenCode Skill
├── tests/                            # 测试套件（100 个用例）
│   ├── conftest.py                   # 共享 fixtures
│   ├── test_security_rules.py        # SEC001-SEC012 正反例
│   ├── test_complexity.py            # 认知复杂度算法 + 规则
│   ├── test_style_rules.py           # 风格规则
│   ├── test_config.py                # 配置加载 + 行级豁免
│   ├── test_scoring.py               # 多维评分
│   └── test_tools.py                 # MCP 工具端到端
└── src/
    └── code_review_mcp/
        ├── __init__.py
        ├── server.py                 # MCP 服务器主入口（4 个工具）
        ├── models.py                 # Issue + Severity + Category 枚举
        ├── config.py                 # 配置加载 + 行级豁免
        ├── scoring.py                # 多维评分算法
        ├── utils.py                  # 通用工具函数
        ├── analyzers/
        │   ├── __init__.py
        │   ├── context.py            # 规则运行入口
        │   ├── diff.py               # Git diff 分析
        │   └── project.py            # 项目扫描
        └── rules/
            ├── __init__.py
            ├── base.py               # Rule / PythonAstRule / TextRule 基类
            ├── registry.py           # 规则注册表
            ├── security.py           # SEC001-SEC012
            ├── complexity.py         # COMPLEX001-005（含认知复杂度算法）
            └── style.py              # STYLE001-004

常见问题

Q: 启动时报错 "command not found: ai-code-review-mcp"

确保 Python 的 Scripts 目录在系统 PATH 中：

# 检查安装位置
pip show ai-code-review-mcp

# 查找可执行文件位置
where ai-code-review-mcp    # Windows
which ai-code-review-mcp    # macOS/Linux

Q: MCP 工具没有出现在 AI 助手中

确认配置文件路径正确
确认 ai-code-review-mcp 命令可以在终端直接运行
重启 AI 助手应用

Q: 只想用 MCP，不想装 Skill 可以吗？

可以。Skill 是可选的增强功能，不装也能使用所有 3 个 MCP 工具。Skill 的作用是让 AI 按标准流程输出格式化的审查报告。

License

MIT © AlanNiew

Available Tools

4 tools

analyze_fileA

分析单个文件的代码质量、复杂度和安全问题。

会运行所有适用的规则：

安全规则（SEC001-SEC012）：eval/exec、shell 注入、pickle、弱哈希、硬编码密钥、SSL 关闭等
复杂度规则（COMPLEX001-005）：函数长度、圈复杂度、认知复杂度、参数个数、嵌套深度
风格规则（STYLE001-004）：行长、TODO、末尾空白、调试残留

Args: file_path: 要分析的文件路径（相对于项目根目录或绝对路径）

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

TDQS

A4/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It details the specific rule categories (SEC001-012, COMPLEX001-005, STYLE001-004), giving transparent insight into what checks are performed. It does not disclose side effects but the tool is read-only by nature.

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 structured with an overview, rule categories list, and an Args section. While not extremely concise, every sentence adds information. It is well-organized and front-loaded with the core purpose.

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?

Despite detailed rule listings, the description lacks information about return values or error handling (e.g., file not found). With no output schema, the agent must guess the response format. Some behavioral gaps remain.

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?

Schema coverage is 0%, so description compensates by explaining file_path meaning: relative to project root or absolute path. This adds significant value beyond the schema, which only provides type and title.

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 it analyzes code quality, complexity, and security for a single file. It lists specific rule categories, and the sibling tools (check_project, list_rules, review_diff) provide context that this is file-level analysis, distinguishing it from project-level or diff-focused tools.

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 the tool is for single-file analysis but does not explicitly state when to use it versus alternatives like check_project or review_diff. No when-not-to-use guidance or prerequisites are provided.

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

check_projectA

扫描项目目录的代码质量概况。

遍历项目下所有支持的源代码文件（Python/JS/TS/Java/Go/Rust 等），对每个文件运行完整规则集，最后汇总：

总文件数和总行数
语言分布统计
错误/警告/提示计数
问题最多的前 10 个文件
整体质量评分（A-F 等级）

Args: directory: 要扫描的项目目录路径，默认为当前目录

ParametersJSON Schema

Name	Required	Description	Default
`directory`	No		.

TDQS

A3.7/5.0

Behavior3/5

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

The description discloses that it traverses files and runs rules, implying a potentially expensive operation. However, it does not mention performance impact, permissions needed, error handling (e.g., invalid directory), or side effects (none expected).

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 well-structured with bullet points and clear sections. It is not overly verbose, though the initial sentence could be more concise.

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?

For a tool with one parameter and no output schema, the description covers purpose, parameter, and output summary well. It lacks details on failure modes or exact return structure, but is largely complete.

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 only parameter 'directory' is explained in the description (path to scan, defaults to current directory), adding meaning beyond the schema's type and default. Schema coverage is 0% but the description compensates.

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 scans a project directory for code quality, listing specific metrics like file counts, language distribution, error counts, top 10 files, and overall score. It distinguishes from sibling tools like analyze_file (single file) and list_rules (list rules).

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 explicit guidance on when to use this tool versus alternatives (e.g., analyze_file for single files, review_diff for diffs). The description only explains what it does, not the decision criteria.

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

list_rulesA

列出所有已注册的代码审查规则，便于 AI 选择性调用。

返回每条规则的 ID、名称、描述、类别和默认严重级别。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/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 clearly indicates this is a read-only listing operation and describes the return fields (ID, name, description, category, default severity). However, it does not disclose potential ordering, filtering, 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 consists of two concise sentences with the purpose front-loaded. Every word adds value, no redundancy.

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 zero parameters and no output schema, the description fully explains what the tool does and what it returns. It is complete for a simple listing tool.

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?

There are no parameters, and schema description coverage is 100% (vacuous). The description adds context about what the tool returns, but since there are no parameters, it is not deficient. The baseline of 3 is exceeded because the description still provides helpful output information.

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 all registered code review rules, using the verb '列出' (list) and resource '代码审查规则' (code review rules). It distinguishes from sibling tools (analyze_file, check_project, review_diff) which involve analysis or checking rather than listing.

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 usage for AI selective calling but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied as a prerequisite for selecting rules.

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

review_diffA

审查当前 git 仓库中未提交的变更（staged + unstaged）。

对 diff 中的新增行做以下检测：

硬编码的密钥或密码（严重）
遗留的 print/console.log 调试语句
新增的 TODO/FIXME/HACK 标记
过长的新增行

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It details the specific checks performed (hardcoded keys, debug logs, TODO/FIXME/HACK, long lines) and mentions it reviews both staged and unstaged changes. However, it does not clarify if the tool is read-only or what happens if no changes are present.

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 a two-line summary followed by a bullet list of checks. Every sentence is meaningful, no fluff, and the structure is easy to parse.

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, the description covers the tool's purpose and checks well. It lacks details on the return format or how results are presented, but the context is largely complete for a stateless review tool.

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?

With zero parameters, the baseline is 4. The description adds value by explaining the purpose and checks performed, which compensates for the lack of parameters.

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 reviews uncommitted git changes and lists specific checks (hardcoded keys, debug statements, TODO/FIXME/HACK markers, long lines). It distinguishes itself from siblings like analyze_file (which focuses on individual files) and check_project (broader scope) by targeting the diff of staged and unstaged changes.

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 usage before committing but does not explicitly state when to use this tool over alternatives like analyze_file or check_project. No exclusion criteria or recommended contexts are provided.

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.

4 tool updatesv0.2.0Jul 5, 2026
- First observedanalyze_file
- First observedcheck_project
- First observedlist_rules
- First observedreview_diff

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct aspect of code review: single file analysis, full project scan, listing rules, and diff review. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (analyze_file, check_project, list_rules, review_diff), making them predictable.

Tool Count5/5

4 tools is concise and well-scoped for a code review server, covering all essential operations without excess.

Completeness4/5

Covers single file analysis, project-wide scanning, rule listing, and diff review. Missing a tool to fetch raw file content, but that is a minor gap for the intended domain.

Maintenance

ActivityStale

ResponsivenessSyncing

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

mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
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
noteit-mcpOAuth
io.github.bahfahh
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
Note Taking Developer Tools Coding Agents
25
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181

Related MCP Servers

flyto-indexerofficial
Code Analysis Developer Tools Security
flytohub
A
license
Not graded
quality
A
maintenance
MCP server that gives AI assistants impact analysis, cross-project reference tracking, and code health scoring.
Updated 3 days ago (2026-09-03 03:31 UTC)
4
Apache 2.0
code-review-mcp-server
Code Analysis Developer Tools Testing & QA Tools
troshenkov
A
license
Not graded
quality
F
maintenance
An MCP server that provides senior-level code review, quality checks, security analysis, and refactoring suggestions directly in your editor.
Updated 4 months ago (2026-05-15 04:49 UTC)
1
MIT
Code Understanding MCP Server
Code Analysis Version Control Developer Tools
codingthefuturewithai
A
license
C
quality
D
maintenance
An MCP server that analyzes local or remote GitHub repositories, providing intelligent code context and structure to AI coding assistants.
Updated 8 months ago (2025-12-23 19:30 UTC)
10
13
MIT
code-guardian
Code Analysis Developer Tools
xueca
A
license
Not graded
quality
B
maintenance
An MCP server that provides code quality checks for AI coding assistants, including file size limits, ESLint, architecture compliance, anti-pattern scanning, and comment compliance.
Updated a month ago (2026-08-10 11:51 UTC)
11
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/AlanNiew/code-review-mcp'

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

ai-code-review-mcp

特性

安装

使用教程

一、OpenCode（推荐）

步骤 1：安装 MCP 服务器

步骤 2：配置 OpenCode

步骤 3：安装配套 Skill（可选，推荐）

步骤 4：开始使用

二、Claude Desktop

步骤 1：安装 MCP 服务器

步骤 2：编辑配置文件

步骤 3：重启 Claude Desktop

三、Cursor

步骤 1：安装 MCP 服务器

步骤 2：配置 Cursor

四、使用 uvx 运行（无需 pip install）

五、从源码运行（开发者）

提供的工具

1. analyze_file — 分析单个文件

2. review_diff — 审查 git 变更

3. check_project — 扫描项目概况

4. list_rules — 查询规则清单（v0.2.0 新增）

规则参考

安全规则（SEC001-SEC012）

复杂度规则（COMPLEX001-005）

风格规则（STYLE001-004）

配置文件（v0.2.0 新增）

行级豁免（v0.2.0 新增）

质量评分算法

多维评分（v0.2.0 新增）

严重级别权重

支持的语言

项目结构

常见问题

Q: 启动时报错 "command not found: ai-code-review-mcp"

Q: MCP 工具没有出现在 AI 助手中

Q: 只想用 MCP，不想装 Skill 可以吗？

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

flyto-indexerofficial

Latest Blog Posts

MCP directory API

1. `analyze_file` — 分析单个文件

2. `review_diff` — 审查 git 变更

3. `check_project` — 扫描项目概况

4. `list_rules` — 查询规则清单（v0.2.0 新增）