简介
GitLab MCP 是社区维护的 GitLab 集成服务器。在 GitHub MCP 进阶 中我们讲了 GitHub 的高级用法，本文聚焦 GitLab 平台的 AI 集成。
GitLab 与 GitHub 的关键差异在于 CI/CD 一体化——GitLab 内置了 Pipeline、Runner、环境管理，MCP 可以直接操作这些 DevOps 资源。
核心能力
| 工具类别 | 工具名 | 用途 |
|---|---|---|
| Project | list_projects / get_project | 项目管理 |
| Issue | create_issue / list_issues / get_issue | Issue 管理 |
| MR | create_merge_request / list_merge_requests | Merge Request 管理 |
| Pipeline | list_pipelines / get_pipeline | CI/CD 流水线 |
| Job | get_job / get_job_logs | 构建任务 |
| Branch | list_branches / create_branch | 分支管理 |
| File | get_file_contents / create_file | 文件操作 |
| Wiki | get_wiki_page / create_wiki_page | Wiki 文档 |
| User | get_current_user / list_users | 用户信息 |
与 GitHub MCP 的对比
| 维度 | GitHub MCP | GitLab MCP |
|---|---|---|
| 仓库托管 | GitHub | GitLab（自部署/SaaS） |
| Issue | ✅ | ✅ |
| PR/MR | Pull Request | Merge Request |
| CI/CD | Actions（有限） | ✅ 原生 Pipeline |
| Pipeline 查询 | ❌ | ✅ |
| Job 日志 | ❌ | ✅ |
| Wiki | ❌ | ✅ |
| 自部署支持 | ❌ | ✅ |
| 生态成熟度 | 高 | 中 |
关键差异：GitLab MCP 能直接查询 CI/CD Pipeline 状态与构建日志，这是 GitHub MCP 不具备的。
各客户端配置示例
Claude Code
编辑 ~/.claude/claude_desktop_config.json：
{
"mcpServers": {
"gitlab": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-gitlab"],
"env": {
"GITLAB_PERSONAL_ACCESS_TOKEN": "glpat-xxxxxxxxxxxx",
"GITLAB_API_URL": "https://gitlab.example.com/api/v4"
}
}
}
}
自部署 GitLab
{
"mcpServers": {
"gitlab": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-gitlab"],
"env": {
"GITLAB_PERSONAL_ACCESS_TOKEN": "glpat-xxxxxxxxxxxx",
"GITLAB_API_URL": "https://gitlab.yourcompany.com/api/v4"
}
}
}
}
Cursor
编辑 ~/.cursor/mcp.json，结构同 Claude Desktop。
Token 申请
GitLab Personal Access Token
- 登录 GitLab → User Settings → Access Tokens
- 创建 Token，勾选权限：
api（完整 API 访问）read_repository（读仓库）write_repository（写仓库）
- 复制 Token（
glpat-开头）
权限说明
| 权限 | 用途 |
|---|---|
api | 完整 API 访问（含 Issue/MR/Pipeline） |
read_repository | 只读仓库 |
write_repository | 读写仓库 |
read_registry | 读容器镜像 |
建议：只授予必要权限，开发用 api，只读用 read_repository。
实战场景
场景 1：查询 CI/CD Pipeline 状态
查询 mygroup/myproject 最近的 Pipeline 状态：
1. 最近 10 次 Pipeline 的状态（成功/失败/运行中）
2. 失败的 Pipeline 的失败原因
3. 构建 duration 趋势
Claude Code 会调用 list_pipelines → get_pipeline（失败的）→ get_job_logs（失败 Job）→ 分析失败原因。
场景 2：自动化 MR Review
Review 以下 Merge Request：
1. 获取 MR 的改动文件
2. 分析代码质量
3. 检查是否需更新测试
4. 检查是否影响 CI/CD
5. 在 MR 中评论
场景 3：Pipeline 失败诊断
最近的 Pipeline 失败了，帮我诊断：
1. 哪个 Job 失败了？
2. 失败的日志是什么？
3. 可能的原因？
4. 修复建议？
Claude Code 会调用 get_pipeline → get_job → get_job_logs → 分析错误 → 给出修复建议。这是 GitHub MCP 做不到的。
场景 4：批量 Issue 管理
整理 mygroup/myproject 的所有 open issue：
1. 按标签分组
2. 按"未响应天数"排序
3. 标记超过 7 天未响应的为"stale"
4. 自动评论"即将关闭"
场景 5：Wiki 文档管理
把以下 API 文档更新到 GitLab Wiki：
1. 读取当前 Wiki 内容
2. 对比新增内容
3. 更新 Wiki 页面
4. 记录变更日志
CI/CD 深度集成
GitLab MCP 最大的优势是 CI/CD 可观测性：
Pipeline 健康度分析
分析 mygroup/myproject 过去 30 天的 Pipeline：
1. 成功率
2. 平均 duration
3. 最常失败的 Job
4. 失败原因分类
5. 优化建议
构建日志分析
分析以下失败 Job 的日志：
{job_logs}
分析：
1. 错误类型（编译/测试/部署）
2. 根本原因
3. 是否为偶发错误
4. 修复方案
5. 预防措施
环境管理
查询当前各环境（dev/staging/prod）的部署状态：
1. 最近部署时间
2. 部署版本
3. 部署人
4. 当前状态
注意事项
- API Rate Limit：GitLab API 有限率限制，批量操作需控制频率。
- 权限范围：Token 权限决定可操作范围，注意最小权限原则。
- 自部署版本：需指定
GITLAB_API_URL，且服务器需可访问。 - Pipeline 日志大小：大日志可能超出 LLM 上下文，需截取关键部分。
- 私有项目：Token 需有私有项目访问权限。
- Webhook vs MCP：MCP 是"按需查询"，Webhook 是"事件推送"，两者互补。
- 并发写入：多客户端同时操作 MR/Issue 可能冲突。
- 审计日志：GitLab 会记录 API 操作，注意审计合规。
安全最佳实践
- Token 保密：Token 不写入代码，用环境变量
- 最小权限：只授予必要权限
- 定期轮换：Token 定期更换
- 审计日志：记录所有自动操作
- 人工确认：高风险操作（合并 MR、删除分支）需确认
- 沙箱测试：先在测试项目验证自动化流程
与其他 MCP 的协同
| 组合 | 场景 |
|---|---|
| GitLab MCP + Filesystem MCP | 读取本地代码 + 提交到 GitLab |
| GitLab MCP + Slack MCP | Pipeline 失败通知到 Slack |
| GitLab MCP + Postgres MCP | 分析 Issue 数据存入数据库 |
| GitLab MCP + GitHub MCP | 跨平台代码协作 |
迁移：GitHub → GitLab
1. 用 GitHub MCP 导出 Issues/PRs
2. 用 GitLab MCP 创建对应 Issues/MRs
3. 迁移代码与分支
4. 重建 CI/CD Pipeline
5. 迁移 Wiki
小结
GitLab MCP 是 GitLab 用户的 AI 集成入口，核心优势是 CI/CD 可观测性——查询 Pipeline 状态、分析构建日志、诊断失败原因。对于使用 GitLab 做 DevOps 的团队，这是比 GitHub MCP 更契合的选择。
MCP 进阶 II 系列下一篇将讲 Slack MCP 进阶：让 LLM 深度参与团队沟通的进阶用法。