shield_lock
JinDaGe
← Back to MCP directory
publicPublicdnsLocal runtime

mcp-server

GitHub代码审查助手MCP服务器，提供智能工具分析PR代码模式、提出改进建议、检查团队标准合规性，支持完整的代码审查工作流程。

article

README

🚀 GitHub代码审查助手MCP服务器

这是一个全面的MCP（模型上下文协议）服务器，为GitHub拉取请求（PR）的代码审查提供智能工具。该服务器使AI助手能够分析PR、提出改进建议、检查代码模式，并确保与团队标准保持一致。

🚀 快速开始

本服务器提供一系列工具，帮助你更高效地进行GitHub代码审查。阅读以下内容，了解如何安装和使用这些工具。

✨ 主要特性

  • 全面的PR分析：分析代码模式、复杂度和潜在问题。
  • 审查管理：创建评论、提交审查并管理反馈。
  • 智能建议：基于最佳实践，由AI提供审查建议。
  • 标准合规性检查：根据团队编码标准检查PR。
  • 文件与差异分析：详细检查代码更改及其影响。
  • 工作流集成：专为完整的审查工作流设计的工具。

📦 安装指南

前提条件

  • Python 3.8或更高版本
  • 具有repo权限范围的GitHub个人访问令牌
  • 兼容MCP的客户端（例如Claude Desktop或任何MCP客户端）

安装步骤

  1. 安装依赖项：
pip install mcp httpx pydantic
  1. 设置GitHub令牌：
    • 转到GitHub设置 → 开发者设置 → 个人访问令牌。
    • 生成一个具有repo权限范围的新令牌。
    • 安全地保存该令牌。
  2. 运行服务器：
python github_code_review_mcp.py

Claude Desktop配置

在Claude Desktop配置文件中添加以下内容：

{
  "mcpServers": {
    "github-code-review": {
      "command": "python",
      "args": ["/path/to/server.py"]
    }
  }
}

📚 详细文档

可用工具

1. github_list_pull_requests

列出仓库中的拉取请求，并提供全面的过滤选项。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | state | 按状态过滤（open/closed/all） | | sort | 排序依据（created/updated/popularity/long-running） | | direction | 排序方向（asc/desc） | | base | 按基础分支过滤 | | head | 按头部分支过滤 | | limit | 最大结果数（1 - 100） | | page | 分页页码 | | response_format | 输出格式（markdown/json） |

示例用法：

列出facebook/react仓库中所有打开的PR

2. github_get_pr_details

获取特定拉取请求的详细信息。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | include_reviews | 是否包含审查信息（默认：true） | | include_checks | 是否包含状态检查（默认：true） | | response_format | 输出格式（markdown/json） |

示例用法：

获取编号为123的PR的详细信息，包括审查和检查信息

3. github_get_pr_files

列出拉取请求中所有更改的文件，并提供统计信息。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | limit | 每页最大结果数 | | page | 页码 | | response_format | 输出格式（markdown/json） |

示例用法：

显示编号为456的PR中所有更改的文件

4. github_get_pr_diff

获取拉取请求的统一差异。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | file_path | 过滤特定文件（可选） | | context_lines | 上下文行数（0 - 10） |

示例用法：

获取编号为789的PR中src/main.js文件的差异

5. github_analyze_pr

对拉取请求进行全面的代码质量分析。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | check_patterns | 是否检查代码模式（默认：true） | | check_complexity | 是否分析复杂度（默认：true） | | check_security | 是否进行基本安全检查（默认：true） | | response_format | 输出格式（markdown/json） |

示例用法：

分析编号为234的PR的代码模式、复杂度和安全问题

6. github_get_pr_comments

获取拉取请求上的所有评论。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | comment_type | 评论类型（all/issue/review） | | limit | 最大结果数 | | page | 页码 | | response_format | 输出格式（markdown/json） |

示例用法：

获取编号为567的PR的所有审查评论

7. github_create_review_comment

在拉取请求上创建评论（一般评论或内联评论）。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | body | 支持markdown格式的评论内容（必需） | | commit_id | 要评论的提交的SHA值（可选） | | path | 内联评论的文件路径（可选） | | line | 内联评论的行号（可选） | | side | 差异的一侧（LEFT/RIGHT） |

示例用法：

在src/utils.js文件的第42行添加一条建议性能改进的评论

8. github_create_pr_review

提交对拉取请求的正式审查。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | body | 审查摘要文本（可选） | | event | 审查操作（APPROVE/REQUEST_CHANGES/COMMENT） | | comments | 内联审查评论数组（可选） |

示例用法：

批准编号为890的PR，并附带一条关于测试覆盖率良好的评论

9. github_get_review_suggestions

为拉取请求生成由AI提供的审查建议。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | focus_areas | 关注领域（performance/security/readability/tests/documentation） | | response_format | 输出格式（markdown/json） |

示例用法：

为编号为345的PR生成关注安全和性能的审查建议

10. github_check_team_standards

检查拉取请求是否符合团队编码标准。 参数： | 属性 | 详情 | |------|------| | owner | 仓库所有者（必需） | | repo | 仓库名称（必需） | | github_token | GitHub访问令牌（必需） | | pr_number | 拉取请求编号（必需） | | standards_file | 仓库中标准文件的路径（默认：.github/CODING_STANDARDS.md） | | response_format | 输出格式（markdown/json） |

示例用法：

检查编号为678的PR是否符合我们团队的编码标准

💻 使用示例

示例1：完整的PR审查工作流

# 1. 列出打开的PR以查找需要审查的PR
github_list_pull_requests(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    state="open",
    sort="created"
)

# 2. 获取特定PR的详细信息
github_get_pr_details(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=123
)

# 3. 分析PR中的问题
github_analyze_pr(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=123
)

# 4. 获取AI建议
github_get_review_suggestions(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=123,
    focus_areas=["security", "performance"]
)

# 5. 检查团队标准
github_check_team_standards(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=123
)

# 6. 提交带有评论的审查
github_create_pr_review(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=123,
    body="Great work! A few suggestions for improvement...",
    event="APPROVE"
)

示例2：专注的代码模式分析

# 获取更改的文件
files = github_get_pr_files(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=456
)

# 获取特定分析的差异
diff = github_get_pr_diff(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=456,
    file_path="src/api/handler.js"
)

# 分析代码模式
analysis = github_analyze_pr(
    owner="myorg",
    repo="myrepo",
    github_token="ghp_xxx",
    pr_number=456,
    check_patterns=True,
    check_security=True
)

🔧 技术细节

最佳实践

审查人员

  1. 从概述开始：使用github_get_pr_details了解PR的上下文。
  2. 先分析：在手动审查之前运行github_analyze_pr。
  3. 检查标准：使用github_check_team_standards确保一致性。
  4. 获取建议：使用github_get_review_suggestions获得全面反馈。
  5. 建设性评论：创建评论时要具体，并提出改进建议。

PR作者

  1. 自我审查：在请求审查之前，在自己的PR上使用分析工具。
  2. 符合标准：在提交之前检查是否符合标准。
  3. 保持PR聚焦：分析工具在较小、聚焦的更改上效果更好。
  4. 包含测试：工具会检查测试覆盖率。
  5. 编写良好的描述：工具会分析PR描述以获取上下文。

安全考虑

  1. 令牌安全：切勿硬编码GitHub令牌。使用环境变量或安全的凭证存储。
  2. 权限：确保令牌具有适当的权限范围（通常repo就足够了）。
  3. 速率限制：GitHub API有速率限制。工具会优雅地处理这些限制，但要注意限制。
  4. 私有仓库：如果需要，确保令牌可以访问私有仓库。

模式检测

分析工具可以检测各种代码模式，包括：

  • 安全问题：硬编码的秘密、SQL注入风险、XSS漏洞。
  • 性能问题：嵌套循环、SELECT *、异步代码中的同步操作。
  • 代码质量：控制台日志、注释掉的代码、空的catch块。
  • 最佳实践：缺少测试、大文件、缺少文档。

团队标准集成

在仓库中创建一个.github/CODING_STANDARDS.md文件，包含团队的标准。工具将自动使用该文件进行合规性检查。示例格式如下：

# 编码标准

## 通用规则
- max_file_length: 500
- max_pr_size: 1000
- require_tests: true
- require_documentation: true

## 分支命名
- 模式: (feature|bugfix|hotfix|release)/description

## 提交消息
- 格式: type(scope): description
- 类型: feat, fix, docs, style, refactor, test, chore

故障排除

常见问题

  1. 身份验证失败
    • 验证你的GitHub令牌是否有效。
    • 检查令牌是否具有所需的权限范围。
    • 确保令牌未过期。
  2. 速率限制
    • GitHub对经过身份验证的请求的API调用限制为每小时5000次。
    • 工具会报告速率限制错误。
    • 考虑为频繁访问的数据实现缓存。
  3. 大型PR
    • 非常大的PR可能会达到响应大小限制。
    • 使用分页参数。
    • 尽可能过滤到特定文件。
  4. 网络错误
    • 检查互联网连接。
    • 验证GitHub API是否可访问。
    • 检查代理/防火墙问题。

贡献

欢迎贡献！可以改进的方面包括：

  • 额外的模式检测规则
  • 支持GitLab/Bitbucket
  • 增强的安全扫描
  • 与更多CI/CD系统集成
  • 自定义规则定义
  • 用于提高性能的缓存层

📄 许可证

本项目采用MIT许可证，详情请参阅LICENSE文件。

致谢

本项目基于以下技术构建：

支持

如果你有问题、疑问或建议，可以：

  • 在GitHub上提交问题
  • 查看文档
  • 参考故障排除指南

⚠️ 重要提示

本工具旨在协助代码审查，但不能替代人工判断。在审查代码时，请始终结合上下文和领域知识。

help

Runtime guide

cloud

Hosted runtime

Hosted servers run from a provider-managed environment. You usually connect the MCP client to the hosted endpoint or follow the provider's authorization flow, without keeping a local process alive

  1. Open provider connection page
  2. Authorize or copy endpoint
  3. Connect from your MCP client
terminal

Local runtime / other methods

Local servers run on your own machine or infrastructure. You normally copy the server_config into your MCP client, install the required package, and provide env variables from env_schema when needed

  1. Copy server_config
  2. Install required package
  3. Fill env variables and restart client