如果應用程式碼已經知道要調用哪個操作，就使用 API 或 SDK；如果模型需要在執行期探索並選擇能力，則使用 MCP。大多數生產環境的 MCP 工具底層仍會調用現有 API，因此兩種介面通常互相配合。
MCP 增加了探索機制和面向模型的合約，但不會取代後端 API、授權、數據模型，或 MCP 伺服器周圍的身份驗證邊界。
分別在於由誰選擇操作
固定程式碼可以調用 POST /refunds，因為開發者已選好端點並完成欄位對應。代理調查客戶服務案件時，可能要先閱讀證據，再從 get_invoice、explain_charge、request_refund 和 escalate_case 中作出選擇。MCP 會向模型提供這些工作的目前清單和結構描述。
MCP 工具規格將工具探索與調用納入協定。OpenAPI 可以描述 HTTP API，但它本身不會決定哪些端點應該成為代理工作。
並列比較 API、SDK 與 MCP
| 問題 | API 或 SDK | MCP 伺服器 |
|---|---|---|
| 主要調用者 | 路徑已知的應用程式碼 | 在執行期間選擇能力的模型 |
| 探索 | 開發期間使用文件、類型或 OpenAPI | 執行期使用 tools/list、資源和協商後的能力 |
| 合約形式 | 端點或方法的輸入和輸出 | 工具意圖，以及輸入和選用輸出結構描述 |
| 身份驗證 | 按照 API 而定 | MCP 傳輸授權，加上可能獨立存在的上游驗證 |
| 授權 | 由後端執行 | 仍由後端執行 |
| 最適合 | 確定性的工作流程和內部服務調用 | 動態工具選擇和可移植的代理客戶端 |
| 主要失敗方式 | 整合程式碼錯誤地調用 API | 模型選擇含糊或範圍過大的工具 |
在這項決策中，GraphQL 屬於 API。結構描述自我檢查能夠協助開發者或客戶端建立查詢，但不受限制的 graph 很少會是良好的代理工具集。
何時直接調用 API 更清楚
以下情況直接使用 API：
- 調用永遠發生在工作流程的同一個位置；
- 程式碼已經具備必要值；
- 操作對延遲敏感，而多一層協定不會增加決策價值；
- 整合需要 MCP 未提供的供應商特定功能；
- 小型、設有類型的 SDK 已提供應用程式所需的合約。
例如，結帳處理函式應透過審查過的應用程式碼調用付款 API。用戶送出確定性的結帳表格後，不應再由模型決定是否建立扣款。
何時應該使用 MCP
以下情況使用 MCP：
- 模型必須從多種能力中選擇；
- 工具需要跨多個相容的代理客戶端運作；
- 工具清單或可用資源可能在工作階段中變更；
- 用戶需要透過標準代理流程連接自己的帳戶；
- 客戶端能夠從結構化內容、資源連結或伺服器提供的提示中獲益。
REST 轉 MCP 教學從一項工作開始，再把 API 包在後方，以避免常見的每個端點各做一項工具的轉換方式。
MCP 不是安全邊界
從 tools/list 隱藏 API 端點，並不會撤銷背後的憑證。MCP 伺服器必須驗證客戶端身份、授權其代表的用戶，並使用專供目標 API 的上游憑證。接着，後端還要再次對資源執行授權。
MCP 授權規格也禁止 token passthrough。為 MCP 伺服器簽發的權杖不應轉傳給下游服務。
避免機械式包裝
為每個 REST 端點生成一項 MCP 工具，往往會產生重疊選項並暴露內部實作詳情。應從用戶工作開始：
User task: "Where is order 1842?"
Weak toolset:
get_order_row
get_shipment_row
translate_status_code
Better tool:
get_order_status
伺服器可以在內部調用多個 API，再傳回最精簡而且有用的結果。除非內部數據合併真的需要代理判斷，否則模型不應負責協調這些連接。
審計永遠不變的步驟
列出一項工作流程中的每次 MCP 調用。如果應用程式碼總是選擇同一工具、使用相同的參數對應，除非 MCP 另有具體效益，否則應改用設有類型的 API 或 SDK 調用。
下方提示會找出這些不必要的包裝層，並只在模型確實需要作出選擇的位置保留 MCP。