MCP vs Function Calling：AI Agent 工具調用有什麼區別？JSON Schema、API 與 Tool Calling 全面對比

兩個核心事實：Function Calling 負責讓模型提出工具呼叫；MCP 負責讓應用以標準協定發現與連線工具。 因此，單一應用只接少量工具時，直接使用 Function Calling 通常更合理；當同一組工具要被多個 Agent、IDE 或桌面客戶端共用，再把 MCP 加到工具連線層，而不是把它當成模型能力的替代品。

這篇適合三類讀者：單一應用開發者，想避免為了「標準化」而過度設計；多模型平台團隊，需要統一工具事件與 Schema；以及負責 MCP 改造的人員，需要劃定遷移邊界、權限層與部署方式。

先把兩者放回正確的架構層

在典型 AI Agent 流程中，Function Calling 位於模型互動層。應用程式把工具名稱、用途與參數 Schema 傳給模型，模型回傳「要呼叫哪一個工具」以及符合 JSON Schema 的參數；真正的 API 請求、資料庫操作或檔案寫入，仍由應用程式執行。官方文件也明確指出，模型只產生函式呼叫資訊，工具程式碼必須由應用自行處理。(ai.google.dev)

MCP 則是工具連線與能力發佈層。它採用 Host、Client、Server 架構：Host 管理應用與權限，Client 維持與特定 Server 的連線，Server 對外暴露 tools、resources 或 prompts。換句話說，MCP 解決的是「工具如何被發現、描述、連線與組合」，不是「模型能否理解任務」。(modelcontextprotocol.io)

架構問題	Function Calling	MCP
模型如何表達意圖	回傳工具名稱與參數	通常由客戶端把 MCP 工具整理後提供給模型
工具如何執行	應用程式自行執行函式或 API	MCP Client 將呼叫轉送給 MCP Server
JSON Schema 的位置	工具參數定義常直接放在模型 API 請求中	MCP tool 以 `inputSchema` 描述輸入，也可提供 `outputSchema`
工具發現	通常由應用預先註冊	Server 可列出可用工具與能力
多客戶端共用	每個客戶端通常各寫一套整合	可透過同一套 MCP Server 重用
權限與審計	由應用與業務 API 自行處理	可在 Host、Client、Server 及業務 API 分層處理
最適合的起點	單一 Agent、少量內部工具	多客戶端、共享工具、遠端工具治理

MCP 規範中的 tool 定義要求輸入 Schema 是有效的 JSON Schema 物件；目前文件以 JSON Schema 2020-12 作為沒有指定 $schema 時的預設版本。工具名稱建議維持在 1 至 128 個字元，這些都屬於協定層約束，不代表任何模型一定支援所有 Schema 關鍵字。(modelcontextprotocol.io)

單一 Agent 不一定需要 MCP

如果只有一個 Agent，工具數量不多，而且工具只服務同一個後端，直接採用 Function Calling 往往能減少連線生命週期、程序管理、版本協商與錯誤轉換。此時，MCP 並不會自動提升模型判斷品質，反而可能增加需要維護的邊界。

常見的直接方案是：

在應用程式內建立工具登錄表。
將工具名稱、說明與 JSON Schema 傳給模型。
驗證模型回傳的工具名稱與參數。
由白名單對應到實際函式或 API Client。
將執行結果重新送回模型，完成下一輪回應。

這條路線的隱性成本較低，但仍有三個限制。第一，工具註冊邏輯會與 Agent 應用綁在一起；第二，未來加入另一個客戶端時，可能要重寫連線程式；第三，工具說明與 Schema 若沒有版本管理，後端 API 修改後很容易出現「模型仍傳舊欄位、執行層已換新規則」的錯誤。

因此，只有一個 Agent 時不必急著導入 MCP，但不代表可以把工具介面寫死。較穩妥的做法，是先把內部工具事件固定下來，例如：

{
  "tool_name": "customer.lookup",
  "schema_version": "v2",
  "arguments": {
    "customer_id": "C-1024"
  },
  "trace_id": "..."
}

其中 tool_name、schema_version、arguments 與 trace_id 應由內部介面管理。未來若需要接 MCP，只需增加 MCP Adapter，不必讓所有模型端程式重新改寫。

直接函式呼叫與 MCP 的早期成本評分

以下分數是架構判斷工具，不是效能實測；分數越高代表該路線在該場景的相對適合度越高。

場景	只用 Function Calling	Function Calling＋內部適配層	Function Calling＋MCP
單一 Agent、少量工具	5/5	4/5	2/5
需要切換多個模型 API	2/5	5/5	4/5
多個 Agent 共用工具	2/5	4/5	5/5
IDE、桌面客戶端也要連線	1/5	3/5	5/5
遠端工具與團隊治理	2/5	4/5	5/5
高風險寫入操作	3/5	5/5	5/5

這張表的重點不是替某個協定加總排名，而是找出觸發條件：客戶端數量、模型數量與治理需求，比工具功能多寡更能決定是否值得加入 MCP。

多模型團隊先建立內部適配層

MCP 和 Tool Calling 分別在哪一層？簡單說，Tool Calling 是模型與應用之間的呼叫事件；MCP 是應用與工具服務之間的標準連線方式。兩者可以串接，但不能假設 MCP 會消除所有模型 API 差異。

不同模型平台可能使用不同欄位名稱、訊息角色、工具選擇參數、平行呼叫規則與錯誤回傳格式。某些 API 使用 function_call，某些使用 tool_use 或其他內容區塊；即使都使用 JSON Schema，對 enum、嚴格物件、額外欄位和輸出驗證的支援也應按實際 API 版本核查。相關官方文件可參考模型工具呼叫的 API 說明、Function Tool 與 Schema 介面及工具輸入 Schema 與結果處理文件。

建議在模型層與工具層之間設計一個統一事件：

ModelAdapter
  └─ ToolCallEvent
       ├─ name
       ├─ arguments
       ├─ call_id
       ├─ schema_version
       └─ approval_required

模型適配器只負責把各家回應轉成 ToolCallEvent；執行器再負責 Schema 驗證、權限判斷、重試、逾時與 API 呼叫。這樣即使日後把工具從內部函式改成 MCP Server，Agent 主流程仍然不必知道底層傳輸細節。

MCP 會不會取代 Function Calling

通常不會。MCP Server 可以暴露工具，但模型仍需要透過某個客戶端或 Agent Runtime 取得工具清單，並以模型可理解的格式決定是否呼叫。MCP 規範把 tools 定義為可執行能力，工具可對應 API POST、檔案寫入或其他動作；它沒有取代模型端的決策流程，也不會自動替業務 API 完成授權。(modelcontextprotocol.io)

因此，最常見的組合架構是：

使用者請求
   ↓
模型＋Function Calling
   ↓
Agent Runtime／MCP Client
   ↓
MCP Server
   ↓
業務 API、資料庫、檔案或 macOS 工具

在這個流程中，Function Calling 決定「想叫什麼工具」；MCP 決定「到哪裡找工具、如何連線與取得工具描述」；執行層則決定「是否真的允許執行」。

多客戶端共享工具時，MCP 才開始產生明顯價值

當同一套工具要同時提供給多個 Agent、IDE、桌面客戶端或自動化工作流，直接在每個應用內註冊工具會造成重複程式碼。每個客戶端都要處理工具名稱、Schema、連線、錯誤格式與版本相容，工具一改就需要同步發佈多個應用。

MCP 的價值在於把這些能力集中到 Server。官方架構將每個 Client 與特定 Server 建立一對一的隔離連線，Host 可管理多個 Client，並控制連線權限與生命週期。(modelcontextprotocol.io)

但導入 MCP 後，治理責任也會集中出現：

Server 必須維護工具名稱與 Schema 的向後相容。
客戶端需要處理工具清單更新與能力協商。
共享工具要有明確的租戶、使用者與工作區邊界。
工具失敗不能只回傳一段模型可讀文字，還要保留可觀測的錯誤碼與追蹤識別碼。
工具描述本身不能視為可信權限來源，尤其是由第三方或遠端 Server 提供的工具。

MCP 的標準傳輸目前包括 stdio 與 Streamable HTTP；stdio 通常由客戶端啟動 Server 子程序，HTTP 則適合獨立部署與遠端連線。這代表「本機工具」與「遠端工具」可以沿用同一種協定思路，但部署、認證與可用性要求並不相同。(modelcontextprotocol.io)

遠端 MCP 與 macOS 工具要分開看待

MCP 可以連線遠端工具，但遠端化不等於已經完成生產環境部署。實際上至少要補上五個執行條件：

第一步，為每個 Server 定義身份與認證方式，避免只靠一組長期固定金鑰。
第二步，限制可連線的網路範圍，並為 HTTP 端點設定逾時、重試與斷線恢復。
第三步，記錄每次工具發現、呼叫、參數驗證、授權判斷與結果狀態。
第四步，對工具設定併發上限，防止模型一次產生大量呼叫造成 API 或主機過載。
第五步，為 Server 做版本標記與回退方案，確保 Schema 更新後仍能處理舊客戶端。

如果工具依賴 macOS 的檔案權限、簽署環境、Xcode 工具鏈或圖形化工作階段，可以把它部署到受控的遠端 Mac；但這是基礎設施選擇，不是 MCP 協定本身的要求。需要遠端 macOS 執行環境時，可先閱讀遠端 Mac 與 VDI 的部署方式，再評估是否將 MCP Server 與工具執行程序放在同一個隔離環境。

高風險操作必須採用三層防線

MCP 是否可以直接執行業務 API？可以作為轉接與工具暴露層，但不應讓「工具可見」直接等同於「操作已獲授權」。對刪除資料、付款、發佈程式、修改生產環境或讀取敏感檔案等動作，至少要設計三層控制：

模型層：限制可選工具，要求工具描述清楚列出副作用，必要時禁止平行呼叫。
Agent／MCP 執行層：驗證 JSON Schema、檢查使用者身份、工作區、資源範圍與是否需要人工確認。
業務 API 層：重新執行最終授權、資料狀態檢查、冪等性控制與審計記錄。

任何一層的 Schema 合規，都不能取代使用者確認。Schema 只能說明資料形狀是否正確，不能證明「這位使用者有權操作這筆資料」，也不能保證模型對業務後果理解正確。MCP 官方安全文件同樣要求實作者建立使用者同意、資料保護與工具安全流程，並指出協定本身不能單獨強制完成所有安全原則。(modelcontextprotocol.io)

在遷移前，建議以同一個工具做兩組最小樣例：一組直接 Function Calling，另一組由 MCP Server 暴露。逐項比較工具註冊位置、Schema 驗證、權限判斷、逾時、錯誤回傳與人工確認點；當模型 API 或 MCP 規範更新後，再重跑這組樣例，而不是只依賴整合測試的成功率。

最後用三條路線決定架構

觸發條件	建議路線	必須保留的設計
一個 Agent、少量工具、單一後端	只用 Function Calling	內部工具介面、Schema 版本、權限與錯誤事件
多模型、但工具仍由同一平台管理	Function Calling＋內部適配層	統一 ToolCallEvent、模型轉換器、執行器與審計
多個 Agent／IDE／桌面客戶端共享工具	Function Calling＋MCP	MCP Server 治理、認證、版本相容、工具發現與隔離

決策時可採用以下順序：先數客戶端，再確認是否需要遠端部署，最後才看工具數量。如果只有一個 Agent，即使工具種類不少，也未必需要 MCP；如果有多個客戶端，即使每個客戶端只用少量工具，MCP 也可能比複製多套連線程式更容易治理。

當前方案若是把所有工具直接寫進單一應用，常見缺點是模型切換時要重做格式適配、不同客戶端要重複維護連線程式，以及遠端 macOS 工具的認證、審計與回收不容易集中管理。若決策表已顯示團隊需要共享 macOS 工具或長時間運作的遠端 MCP Server，與其把權限、工作區和工具程序混在開發者本機，不如評估可隔離、可回收的遠端 Mac 環境；雲端 Mac 租用方案較適合先做短期驗證、團隊共用或需要受控執行環境的情況。若是長期穩定重負載、必須直接連接特殊硬體，則自購 Mac 或固定本地主機仍可能更合適。