你的 LLM 應用真的需要 MCP 嗎？MCP、CLI 與函式呼叫取捨 - Toolsify AI Blog

開發者社群裡越來越常見一個問題：我做了一個 LLM 功能，需要讓模型查資料庫、讀 repo 或跑部署命令，是不是應該馬上寫一個 MCP server？有時答案是肯定的，但更多時候，更誠實的答案是：還不必。

MCP（Model Context Protocol）的價值很真實。官方文件把它定義為連接 AI 應用與外部系統的開放標準，Anthropic 發布 MCP 時也強調，它希望減少一次性整合，讓工具、資源和提示能用統一協議暴露給 AI 用戶端。但標準協議不等於所有場景都該優先使用。

先看整合面，而不是看熱度

函式呼叫、CLI 和 MCP 都在解決同一個問題：模型需要安全、結構化的能力，才能真正做事。差別在於契約放在哪裡。

原生函式呼叫把契約放在你的應用裡。你定義 schema，模型選擇工具和參數，你的服務端執行動作並返回結果。它直接、可除錯，也最容易進入生產。

CLI 把契約放在可執行命令裡。測試、型別檢查、套件管理、資料庫遷移、部署預覽、程式碼生成腳本，本來就是命令形態。正確做法不是讓模型隨便跑 shell，而是做一個窄命令 broker：白名單、固定工作目錄、逾時、參數驗證、輸出截斷和脫敏。

MCP 則把契約放在 MCP client 與 MCP server 之間。Server 暴露工具、資源和提示，client 發現並呼叫這些能力。它最擅長的不是替代每一次 tool call，而是讓能力跨用戶端、跨團隊、跨模型 runtime 複用。

大多數 LLM 應用第一版都應該從函式呼叫開始。認證、日誌、限流、重試、租戶隔離和事故回應都還在你已經營運的應用邊界裡。工具失敗時，你能在同一個地方看到使用者、請求、模型輸出和後端 trace。

如果工具是產品特定的，函式呼叫通常更合適。客服助手查訂單、起草退款、總結帳戶歷史，這些操作深度綁定權限和業務邏輯。太早抽成 MCP 可能只是增加協議邊界。

對 coding agent 和基礎設施工作流來說，CLI 往往是最誠實的介面：可以本地重現，繼承專案約定，輸出人類看得懂的日誌，並用退出碼表達失敗。

如果流程已經是命令原生的，先封裝 CLI，而不是急著重寫成 MCP 工具。命令 broker 可以把原始日誌留給人類，把結構化摘要給模型。它適合測試、建置、遷移、部署預覽和 repo 搜尋。

當同一能力需要進入多個 AI 環境時，MCP 才真正值回複雜度。知識庫搜尋、repo context、設計系統、資料庫 metadata、稽核日誌查詢，這類平台能力很適合做成 MCP server，讓聊天助手、IDE agent、支援 copilots 和內部自動化共同使用。

MCP 也適合分散式所有權。資料平台團隊維護 analytics server，開發體驗團隊維護 repository server，安全團隊維護 audit-log server，應用團隊只消費能力，不複製業務邏輯。生產側可以參考我們的 MCP 生產整合模式。

但 MCP 不是免費抽象。認證、授權、密鑰管理、限流、遙測、schema 版本、錯誤訊息安全，仍然都要你設計。

先問：這個工具會被幾個用戶端使用？只有一個產品介面，就從函式呼叫開始；多個助手、IDE 或 agent runtime 需要共用，再認真考慮 MCP。

再問：工具現在在哪裡？如果它已經是人類穩定使用的命令，先封裝 CLI。如果它是應用內部業務邏輯，函式呼叫更乾淨。如果它是平台團隊擁有的共享能力，MCP 可能是更合適的邊界。

第三問：動作有多敏感？只讀搜尋和刪除資料、部署生產不是同一個風險等級。高風險工具更需要審批、scope token、稽核日誌、dry-run 和人類可見 diff。

第一版產品功能用函式呼叫。當第二個用戶端需要同一能力時，把實作抽到內部服務邊界。當第三個用戶端出現，再升級成 MCP server。

命令原生工作流則從安全 CLI broker 開始。多個 AI 用戶端都需要同一命令面時，在 broker 前面加 MCP server。也就是：MCP 負責發現與互操作，CLI 負責執行。

最好的架構不是最新的，而是在安全、可觀測和未來複用之間，邊界最少的那一個。等互操作性真的成為需求，再引入 MCP。