MCP PR审查优化器
MCP(模型上下文协议)服务器,通过跟踪PR老化、测量审查响应时间、分析批准模式以及根据专业知识和可用性智能建议审查员来优化拉取请求审查流程。
特性
- 🔍 陈旧性PR检测:根据年龄确定需要紧急关注的PR
- 📊 审查指标:分析团队评审绩效和响应时间
- 👥 负载管理:跟踪审阅者能力和当前任务
- 🎯 聪明的审稿人建议:基于人工智能的审稿人建议基于:
- 代码专业知识(文件/目录/语言知识) - 当前可用性和工作负载 - 历史回顾速度
- 🚨 瓶颈分析:识别审查流程瓶颈,并获得可操作的建议
- 📈 综合报告:生成具有趋势和见解的详细审查健康报告
- ⏱️ 公关时间线跟踪:获取个人PR的详细历史记录和指标
建筑
此服务器实现 MCP流式HTTP传输,提供:
- 用于双向通信的单个HTTP端点
- 用于实时流响应的服务器发送事件(SSE)
- 状态会话管理
- 与基于web的MCP客户端和Claude Desktop兼容
安装
先决条件
- Node.js>=18.0.0
- npm或纱线
- GitHub个人访问令牌具有以下作用域:
- repo (完全访问存储库) - read:org (读取组织数据)
设置
- 克隆存储库:
git clone
cd mcp-pr-review-optimizer- 安装依赖项:
npm install- 配置环境变量:
cp .env.example .env编辑 .env 并添加您的配置:
# GitHub Configuration (Required)
GITHUB_TOKEN=ghp_your_github_personal_access_token
GITHUB_ORG=your-organization-name
# Optional: Specific repositories to monitor
GITHUB_REPOS=backend-api,frontend-app,mobile-app
# Optional: Team members to track
GITHUB_REVIEWERS=alice,bob,charlie,diana,eve
# Optional: Thresholds
STALE_PR_THRESHOLD_HOURS=72
CRITICAL_PR_THRESHOLD_HOURS=168
HIGH_WORKLOAD_THRESHOLD=6
# Optional: Expertise calculation
EXPERTISE_COMMIT_WEIGHT=0.6
EXPERTISE_REVIEW_WEIGHT=0.4
EXPERTISE_LOOKBACK_DAYS=90
# Server Configuration
PORT=3000
HOST=localhost- 构建项目:
npm run build- 启动服务器:
npm start服务器将在以下时间可用 http://localhost:3000/mcp
发展
对于自动重建的开发:
npm run dev与Claude一起使用
Claude桌面配置
添加到您的Claude Desktop配置文件中:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json 视窗: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"pr-review-optimizer": {
"url": "http://localhost:3000/mcp",
"transport": "streamable-http"
}
}
}对话示例
1.检查是否有过期的PR
User: What PRs need my attention today?
Claude: [uses get_stale_prs tool]
You have 5 PRs that need attention:
Critical (>7 days):
- PR #1234: "Add user authentication" by alice - waiting 7 days
- PR #1256: "Update payment flow" by frank - waiting 8 days
Stale (3-7 days):
- PR #1289: "Fix login bug" by bob - waiting 4 days
...2.获取审稿人建议
User: Who should review PR #1267 in backend-api?
Claude: [uses suggest_reviewers tool]
For PR #1267 "Refactor authentication module", I recommend:
1. bob (Score: 92%) - Best choice
- High expertise in authentication code
- Fast response time (avg 4.5 hours)
- Currently available (3 PRs assigned)
2. diana (Score: 88%) - Great alternative
- Moderate auth expertise
- Very available (only 1 PR assigned)3.分析瓶颈
User: Why are our reviews taking so long lately?
Claude: [uses analyze_review_bottlenecks tool]
I've identified 3 main bottlenecks:
1. charlie is overloaded (High Severity)
- Has 8 PRs assigned vs team average of 3
- Response time increased to 36.5 hours
2. backend-api has large PRs (Medium Severity)
- Average PR size: 650 lines
- Review time: 48 hours vs 18 hour average
Recommendation: Redistribute some of charlie's PRs to diana and bob4.生成周报
User: Generate my weekly review report
Claude: [uses generate_review_report tool]
# PR Review Health Report
**Period**: 2025-01-13 - 2025-01-20
**Repositories**: All repositories
**Generated**: 2025-01-20 10:30:00 UTC
## 📊 Overview
- Total Open PRs: 23
- Stale PRs (>3 days): 5
- Critical PRs (>7 days): 2
- Average Review Time: 18.4 hours
- Team Capacity: 60% (Moderate pressure)
...可用工具
1. get_stale_prs
查找因年龄而需要关注的拉取请求。
参数:
repositories(可选):存储库名称列表age_threshold_hours(可选):年龄阈值,默认值72exclude_draft(可选):排除草稿,默认为trueexclude_wip(可选):排除WIP PR,默认为true
2. get_review_metrics
分析评审响应时间和模式。
参数:
repositories(可选):存储库名称列表start_date(可选):ISO日期,默认7天前end_date(可选):ISO日期,默认为今天group_by(可选):“审阅者”|“存储库”|“作者”
3. get_reviewer_workload
检查团队成员的当前审核能力。
参数:
reviewers(可选):GitHub用户名列表repositories(可选):存储库名称列表include_draft(可选):包括PR草案,默认为false
4. suggest_reviewers
为PR推荐最佳审阅者。
参数 (必填):
pr_number:拉取请求号repository:存储库名称count(可选):建议数,默认为3prioritize(可选):“专业知识”|“可用性”|“速度”|“平衡”
5. analyze_review_bottlenecks
找出评论陷入困境的地方。
参数:
repositories(可选):存储库名称列表days_back(可选):分析天数,默认14天min_prs(可选):所需的最小PR,默认值为5
6. get_pr_review_history
获取特定PR的详细审核时间表。
参数 (必填):
pr_number:拉取请求号repository:存储库名称
7. generate_review_report
在Markdown中生成全面的审查健康报告。
参数:
repositories(可选):存储库名称列表days_back(可选):分析天数,默认为7天include_recommendations(可选):包括建议,默认为true
运作原理
专业计算
服务器分析Git历史以构建专业知识图:
- 承诺 (60%权重):文件已修改,行已更改
- 评论 (40%权重):审查文件,发表评论
- 回顾期:过去90天(可配置)
专业知识得分:
- 0.0-0.3:专业水平低
- 0.3-0.6:中等专业水平
- 0.6-0.9:高专业水平
- 0.9-1.0:专家
可用性计算
容量得分基于:
- 当前分配的PR(40%权重)
- 过去7天审查的PR(30%权重)
- 平均并发PR计数(30%权重)
状态类别:
- 可用:容量得分>0.6
- 中等负荷:容量得分0.3-0.6
- 全部开工:容量得分\<0.3
- 不在办公室:最近没有活动
缓存策略
- 专业地图:24小时
- 工作量数据:1小时
- PR数据:15分钟
- 实时查询:无缓存
配置选项
阈值
STALE_PR_THRESHOLD_HOURS:当PR被认为过时时(默认值:72)CRITICAL_PR_THRESHOLD_HOURS:当PR至关重要时(默认值:168)HIGH_WORKLOAD_THRESHOLD:每位审阅者的最大PR(默认值:6)
专业设置
EXPERTISE_COMMIT_WEIGHT:专业知识中的提交权重(默认值:0.6)EXPERTISE_REVIEW_WEIGHT:专业评论权重(默认值:0.4)EXPERTISE_LOOKBACK_DAYS:回顾专业知识的天数(默认值:90)
API速率限制
服务器使用GitHub API,该API具有以下限制:
- 经过身份验证的请求:5000个请求/小时
- 服务器实现缓存以最小化API调用
- 指数退避用于速率限制错误
故障排除
“GITHUB_TOKEN环境变量是必需的”
确保您已创建 .env 使用您的GitHub令牌的文件:
cp .env.example .env
# Edit .env and add your GITHUB_TOKEN“超过API费率限制”
服务器可能发出过多的GitHub API请求。尝试:
- 减少被监控的存储库数量
- 增加缓存TTL(修改
src/cache.ts) - 等待速率限制重置(每小时重置一次)
结果为空或不完整
- 确保您的GitHub令牌具有正确的作用域(
repo,read:org) - 验证组织名称和存储库名称是否正确
- 检查您是否有权访问正在查询的存储库
安全考虑
- 永远不要承诺你的
.env文件 -它包含敏感令牌 - 使用具有最低所需权限的GitHub令牌
- 仅分析您有权访问的存储库
- 服务器尊重私有存储库权限
- 考虑在安全的专用网络中运行服务器
未来的增强功能
- \[\]通知的Slack集成
- \[\]用于自动分配审阅者的GitHub操作
- \[\]用于改进建议的机器学习
- \[\]审查质量指标
- \[\]跨存储库专业知识见解
- \[\]可视化仪表板
- \[\]PR尺寸执行
- \[\]SLA跟踪
- \[\]PTO的日历集成
贡献
欢迎投稿!拜托:
- 分叉存储库
- 创建要素分支
- 进行更改
- 如果适用,添加测试
- 提交拉取请求
许可证
MIT许可证-有关详细信息,请参阅许可证文件
支持
对于问题、疑问或贡献,请在GitHub上打开问题。
______________________________________________________________________
与 模型上下文协议
