事件處理該用 API 還是 MCP？先把固定流程與調查分開

先分辨你面對的是動作還是問題#

例如「把服務 A 重啟」是動作；「為什麼服務 A 在這次部署後開始逾時」是問題。前者應有一個可審核、可重跑的程序；後者才需要把 log、版本、設定與依賴關係放進同一個調查脈絡。

API 流程要追求可預期，不是更像聊天#

事件處理裡的 API／CLI 自動化，至少應明確記錄：

• 目標資源與環境，例如 production 的哪一個 service。
• 允許的操作集合，而不是任意 shell 指令。
• 操作前條件與停止條件，例如健康檢查已失敗但資料庫 migration 未執行。
• 呼叫者、時間、請求 ID 與回應結果。
• 失敗時要通知誰，以及是否需要人工接手。

這些限制看似降低彈性，卻正是 incident 自動化的價值：同一個輸入可以被同一套 runbook 處理，事後也能說明「當時做了什麼」。如果一個操作需要大量語意判斷才知道怎麼呼叫，它很可能還不適合直接自動化。

MCP 適合縮小未知範圍，但先停在唯讀#

MCP 的 tools 定義包含名稱、說明與 input schema；官方規格也提醒 client 不應因為 tool annotation 就無條件信任 server。這很符合調查工作的需求：把可用資料來源明確列出，再讓 agent 依目前證據提出下一個查詢。

一個低風險的 MCP 調查任務可以像這樣：

1
只讀取指定 production service 在過去 30 分鐘的：
2
1. 健康檢查結果；2. 部署版本；3. 錯誤率；4. 最近一次設定變更。
3

4
不要重啟服務、不要修改設定、不要查詢其他專案。
5
輸出每項來源、時間範圍與仍無法確定的假設。

輸出要求裡的「來源、時間範圍、假設」很重要。它讓人可以判斷 agent 是真正找到訊號，還是只是把相關名詞湊成一個可能原因。

連 MCP 前，先定義事件處理的權限邊界#

MCP 官方 security best practices 特別指出本機 server 的程式碼執行、資料外洩與權限問題，也建議採取最小 scope、逐步提升權限。用在事件處理時，我會採用三層邊界：

這也處理了一個常見誤解：即使 MCP host 的本機 sandbox 設得很窄，MCP server 與外部服務仍有自己的控制面。不要把「agent 是唯讀」推論成「所有接上的工具也沒有寫入能力」。

一個適合交接的處理順序#

1
告警觸發
2
  -> API／runbook 取得固定健康訊號
3
  -> MCP 僅讀取跨來源線索，列出假設與證據
4
  -> 人工選擇已核准的修復操作
5
  -> API 執行單一修復動作並驗證
6
  -> 記錄結果、時間範圍與待追查事項

把 MCP 留在「調查與摘要」，把寫入動作留給有輸入驗證、權限範圍與 audit log 的 API 流程，能讓兩種工具各自做擅長的事。即使調查結果錯了，也不會直接把錯誤推論放大成正式環境的變更。

這次要記住的事#

事件處理不是選 API 或 MCP 的二選一。固定、可重跑、影響明確的操作，應收斂為受控 API／runbook；跨來源、仍有未知的問題，才交給 MCP 協助唯讀探索。先把兩條路分開，之後要加速自動化才不會把調查能力誤當成執行權限。

常見問題#