如果應用程式碼已經知道要呼叫哪個操作，就使用 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。