iT邦幫忙

2025 iThome 鐵人賽

DAY 17
0
Software Development

AI 驅動的 Code Review:MCP 與 n8n 自動化實踐系列 第 17

[Day17] n8n + AI + MCP 整合流程 - Part 7 最終篇:自建 MCP Server 讓 MCP Client 連線

  • 分享至 

  • xImage
  •  

n8n + AI + MCP 整合流程 - Part 7 最終篇:自建 MCP Server 實現完整工具鏈整合

前言

在上一篇文章中,我們透過 HTTP Request Tool 成功讓 AI Agent 存取 GitLab 資料進行 Code Review。今天我們將更進一步,建立專屬的 MCP Server 並讓 MCP Client 連線,實現更完整且彈性的工具整合方案。

步驟 1:部署 GitLab MCP Server

我們將使用與 Day 5 VSCode 版本相同的方式,採用 zereight 開發的 GitLab MCP Server。不過這次我們使用 streamable-http 模式,並透過 Docker 來啟動服務,確保部署的一致性和可靠性。

Docker 服務啟動

執行以下指令來啟動 MCP Server:

docker run -i --rm \
  -e GITLAB_PERSONAL_ACCESS_TOKEN=your_gitlab_token \
  -e GITLAB_API_URL="https://gitlab.com/api/v4" \
  -e STREAMABLE_HTTP=true \
  -p 3333:3002 \
  iwakitakuma/gitlab-mcp

💡 提醒:請記得將 your_gitlab_token 替換為您的實際 GitLab Personal Access Token。

步驟 2:在 AI Agent 中選擇 MCP Client Tool

在 n8n 的 AI Agent 節點中,選擇 MCP Client Tool 作為我們的主要整合工具:

MCP Client Tool 選擇

步驟 3:詳細配置 MCP Client Tool

接下來進行 MCP Client 的詳細設定,確保與我們的 MCP Server 能夠正常通訊:

核心設定參數

  • Endpointhttp://{輸入你的 host}:3333/mcp
  • Server Transport:選擇 Http Streamable
  • Authentication:選擇 None(因為我們未設定額外驗證)
  • Tools To Include:建議選擇 Selected

工具選擇策略

我們建議選擇 Selected 而非 All 的原因:

  • 精準控制:Code Review 流程只需要特定幾個工具
  • 避免誤操作:防止 AI Agent 執行非預期的動作
  • 提升效能:減少不必要的工具載入

針對 Code Review 需求,我們選擇以下三個核心工具:

  1. 獲取差異資訊
  2. 進行程式碼分析
  3. 建立審查留言

MCP Client Tool 配置

步驟 4:測試 GitLab MCP Tool 連線狀態

在正式使用前,我們需要驗證 MCP Tool 是否能正常運作:

測試步驟

  1. 執行測試:點選 Execute Step 按鈕
  2. 選擇工具:點選 get_merge_request_diffs 工具

測試 MCP Tool

  1. 參數設定:輸入 get_merge_request_diffs 所需的參數

根據前面章節提到的 Webhook 資訊,設定以下參數:

  • project_id:專案 ID
  • merge_request_iid:Merge Request 的內部 ID
  • source_branch:要進行差異比較的分支
  • view:設定為 "parallel"(平行檢視模式)

參數設定

  1. 驗證結果:點選測試彈窗中的 Execute Step,確認能夠成功獲取 diff 資訊

https://ithelp.ithome.com.tw/upload/images/20250916/20121499Utf3vmVhBn.png

步驟 5:調整 AI Agent Prompt 並執行

現在我們需要更新 AI Agent 的 Prompt,讓它能夠正確使用 GitLab-MCP 工具而非原本的 HTTP Request Tool。

調整後的完整 Prompt

## 自動化 Code Review 執行流程

### 第一步:獲取 Merge Request 差異資料
請使用 `GitLab-MCP:get_merge_request_diffs` 工具取得合併請求的詳細差異,參數設定如下:

- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- source_branch: {{ $json.body.object_attributes.source_branch }}
- view: "parallel"

### 第二步:進行全面性程式碼審查
讀取第一步的結果陣列,每筆資料代表一個檔案的 diff 資訊。請扮演資深軟體工程師的角色,針對每個檔案進行全面性的 Code Review。

#### 審查維度(必須涵蓋以下五個面向):

1. **✅ 邏輯正確性**:程式邏輯是否正確、是否有潛在錯誤或邊界條件未處理
2. **🧹 程式碼品質**:是否符合慣用寫法,例如錯誤處理、命名風格、簡潔性
3. **🔒 安全性考量**:是否有安全性問題,例如硬編碼、未處理的錯誤、資源洩漏等
4. **🚀 效能最佳化**:是否有效能瓶頸,例如不必要的記憶體分配、重複運算、goroutine 使用不當
5. **📚 可維護性**:是否具備良好的可讀性與可維護性,包括註解、結構清晰度、模組化程度

#### 評估流程(請嚴格遵循以下步驟):

1. **逐項分析**:針對每個面向分析問題,並列出具體證據
2. **風險評估**:綜合所有問題,決定 severity 等級
3. **證據導向**:只在有明確證據時提升 severity,避免過度評估

#### 風險等級定義(必須嚴格遵守):

- **high(高風險)**:問題可能導致系統崩潰、安全漏洞、資料洩漏、嚴重效能衰退,或在生產環境造成重大損失
  - 例如:未處理的 nil 指標、SQL 注入風險、無限迴圈

- **medium(中風險)**:問題可能引起偶發錯誤、非最佳實踐,但不立即危險
  - 例如:未優化的迴圈、缺少錯誤檢查、輕微資源浪費

- **low(低風險)**:小問題,不影響功能或效能
  - 例如:命名不一致、缺少註解、多餘空白

- **no problem(無問題)**:所有面向皆符合最佳實踐,無任何可改進點
  - 例如:測試程式碼中的 `req, _ := http.NewRequest("GET", "/ping", nil)` 使用底線是可接受的
  - **注意**:此等級不需執行第四步留言動作

### 第三步:獲取 Merge Request 基本資訊
請使用 `GitLab-MCP:get_merge_request` 取得 commit SHA 相關資訊:

參數設定:
- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- source_branch: {{ $json.body.object_attributes.source_branch }}

目標欄位:
- **base_sha**:來源分支的 base commit SHA
- **head_sha**:來源分支的 HEAD commit SHA  
- **start_sha**:來源分支的 start commit SHA

### 第四步:建立審查留言
僅對 medium 和 high 風險的問題使用 `GitLab-MCP:create_merge_request_thread` 建立留言:

參數設定:
- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- body: 第二步的詳細 Code Review 內容
- position: 包含以下必填欄位
  - base_sha: 來自第三步的資料
  - head_sha: 來自第三步的資料
  - start_sha: 來自第三步的資料
  - position_type: 'text'
  - new_path: 來自第一步的檔案路徑資料
  - old_path: 來自第一步的檔案路徑資料
  - new_line: 根據第一步的 diff 計算特定行號
  - old_line: 根據第一步的 diff 計算特定行號

步驟 6:執行驗證與結果確認

分階段測試建議

由於 create_merge_request_thread 工具需要較多參數,有一定的失敗機率,建議採用以下分階段測試策略:

  1. 第一階段:先測試 Prompt 的第 1-2 點,確認資料獲取和分析功能正常
  2. 第二階段:功能驗證無誤後,再加入 Prompt 的第 3-4 點進行完整測試

執行結果展示

執行過程

最終結果

本篇小結

經過 Part 1 到 Part 7 共七個章節的完整實作,我們成功建立了 AI Agent + MCP 的完整資料流。透過先前 VSCode MCP Tool 的體驗,以及這幾篇 GitLab MCP Tool 的深度整合,相信您對 MCP(Model Context Protocol)有了更深刻的理解和實際應用經驗。

成果回顧

我們已經完成了方法二的實作,但在使用 MCP Tool 執行 Code Review 的過程中,我發現了一些可以進一步優化改善的地方。基於這些發現,後續我開發了方法三的解決方案。

整合架構總覽

關鍵收穫

  • MCP 架構理解:從理論到實踐,掌握 MCP 的核心概念
  • 工具整合經驗:學會如何將不同工具透過 MCP 協議進行整合
  • AI Agent 設計:了解如何設計有效的 AI Agent Prompt 和工作流程
  • 問題解決思維:在實際應用中發現問題並持續優化的迭代思維

下一篇預告: 我們將分享在實際使用過程中發現的問題,以及如何透過方法三來解決這些挑戰,打造更加穩定且高效的自動化 Code Review 系統。


上一篇
[Day16] n8n + AI + MCP 整合流程 - Part 6:透過 HTTP Request Tool 實現 GitLab 自動化 Code Review
下一篇
[Day18] 為什麼我改用 API 打造 Code Review 自動化,取代 MCP Tool?
系列文
AI 驅動的 Code Review:MCP 與 n8n 自動化實踐22
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言