先寫出任務缺口，而不是先找 server#

把想做的事改寫成可檢查的句子。

如果答案仍是「先裝看看」，就還沒到連線階段。先用目前已有的工具完成一次最小流程，才能知道缺的是資料來源、認證方式，還是只是 prompt 與完成條件不清楚。

用三層盤點判斷 MCP 是否必要#

我會把每個候選 server 放進下表，而不是直接照 README 安裝。

例如「讀取本機專案的測試結果」通常不需要為此新增遠端 MCP server；但「在同一個受控工作流查詢公司內部系統，並且該系統只提供核准的 MCP 入口」就可能是合理理由。關鍵在於能力是否不可替代，而不是 MCP 是否流行。

一旦要接，就先把 scope 寫小#

官方 MCP security best practices 提醒：server 應以最小權限執行，限制檔案系統、網路與其他系統資源；處理授權時也應使用最小權限 scopes。這些不是 server 作者才需要關心的細節，使用者在選擇與設定 server 時同樣該問。

連線前至少確認：

• 這個 server 會讀哪些目錄、網域或第三方帳號。
• 它提供的是只讀查詢、可寫入操作，還是能執行 shell／部署等高影響動作。
• token 存在哪裡、是否能縮小 scope、撤銷與輪替方式是什麼。
• 是否有官方文件、原始碼或可追溯的維護者；不清楚就不要把它接到重要工作區。

遠端 MCP 特別要留意 OAuth 同意畫面。MCP 的授權文件建議使用短效 token、驗證 token、避免萬用 scope，也不要把憑證寫進 log 或版本控制。看到「一次授權全部功能」時，應先停下來檢查 scope 是否超過這次任務。

把 MCP 當成一個獨立的變更#

不要把「新增 MCP」和「讓 agent 幫我完成任務」綁成同一步。較容易稽核的順序是：

1
1. 先用現有能力完成唯讀探索。
2
2. 明確寫出無法完成的外部能力。
3
3. 選一個具官方來源、scope 可縮小的 server。
4
4. 在非正式資料與最小權限下測一個只讀動作。
5
5. 驗證輸出與 audit log，再決定是否開放寫入動作。

這也能讓故障更好排查。若 workflow 失敗，你能分辨是模型判斷、MCP 連線、授權 scope、第三方 API，還是原本任務設計出了問題。

一個不必安裝 MCP 的起點#

先讓 agent 對既有專案做一個沒有外部副作用的任務：

1
只讀取目前 repository。
2
列出：1. 可用的測試指令；2. 現有環境變數名稱；
3
3. 哪些需求需要連到 repository 以外的系統。
4
不要修改檔案、不要安裝套件、不要連線外部服務。

若這一步已能回答問題，就先不要新增 MCP。若它明確指出需要某個外部系統的受控資料，再為那個缺口設計單一 server 與最小 scope。

這次要記住的事#

MCP 的價值在於提供原本拿不到、而且可被清楚界定的能力；它不是 workflow 複雜度的預設解法。先盤點內建能力與官方入口，再為唯一的外部缺口接 server，能讓 agent 工作流更容易維護，也比較不會把資料與權限邊界交給不必要的整合。

常見問題#