MCP 與 API：定義、區別與使用情境

MCP 全稱為 Model Context Protocol（模型上下文協議），是一個開放標準，供 AI 代理程式用於存取外部系統：應用程式功能（工具）、資源（包含資料庫）以及提示詞。

與透過設定的端點和參數連接兩個應用程式的 API 不同，MCP 允許 LLM 在執行階段發現最新的工具。MCP 還可以大幅減少整合維護所需的時間。

MCP 與 API 並非對立的技術。MCP 旨在讓基於 AI 的應用程式能夠全面存取外部功能和資訊，同時減少對客製化 API 設定的需求。通常，MCP 請求會觸發伺服端 API 呼叫，且在某些重要的開發者使用情境中，API 仍然比 MCP 更受青睞。

MCP 是一個開源協議（一組規則），允許 AI 工具安全且自主地呼叫諸如資料庫、軟體功能和提示詞等工具。
與預先設定的 API 相比，MCP 允許 LLM 根據任務需求選擇當前的外部功能，而不會使其上下文視窗膨脹。
對於傳統軟體整合以及某些固定且疊代的 LLM 工作流程，API 較為理想。
如果你的應用程式中的 AI 功能正在擴展、你管理大量的整合，或者供應商功能經常變更，那麼 MCP 無疑是更好的選擇。
在開發者領域之外，個人在主流 AI 聊天機器人（Claude、ChatGPT、Perplexity 等）中使用 MCP 連接器並不需要任何複雜的程式設計知識。大多數都提供一鍵整合功能。

MCP 是一種廣泛使用的協議，用於 AI 模型與 MCP 伺服器之間的通訊。該協議讓 MCP 客戶端能夠呼叫 MCP 伺服器上可用的任何工具與資源。

構成 MCP 工作流程的三個元件為：

主機：終端使用者觸發動作或輸入自然語言提示（例如「告訴我倫敦的天氣」）的包裝應用程式（例如 Perplexity）。主機向 LLM 提供可用工具清單，LLM 決定哪種工具最適合完成任務。
客戶端：使用 MCP 協議連接到 MCP 伺服器的協議處理常式（內建於主機中）。
伺服器：接收 MCP 請求並提供或「公開」其可存取之各種功能的應用程式。

值得注意的是，MCP 伺服器經常使用 API 來與工具進行通訊。例如，如果你將 Perplexity 連接到 Slack MCP，客戶端將與 MCP 伺服器對話，然後該伺服器將使用 Slack API 來發出原始 MCP 請求中詳細說明的請求。

API 是兩個應用程式之間的介面。與 MCP 一樣，它定義了某個系統如何向另一個系統請求資料或操作的規則。客戶端使用供應商指定的參數發送請求，而伺服器則傳回響應。

以下是 API 請求和響應各個元素的簡要介紹：

端點：你向其發送請求的 URL。
方法：你希望伺服器應用程式採取的動作。
參數：你發送供伺服器處理的輸入。
標頭：諸如授權和響應格式等附加資訊。
請求主體：執行請求所需的資料（這些有時為選填）。
響應：伺服器傳回的資訊或成功/失敗狀態。

從宏觀來看，API 所做的一切幾乎都歸結為與系統交換資料或請求系統執行操作。

表面上，這看起來可能與 MCP 連接器的功能相似。然而，關鍵的區別在於，使用基於 API 的方法時，不同的任務需要不同的端點、方法和參數，所有這些都必須在客戶端進行維護。MCP 伺服器使其所有可用功能或資料對 LLM 可見，而無需進行任何客戶端更新。

	MCP	API
主要應用程式	基於 LLM 的工具內的工作流程	軟體平台之間定義明確的請求
它們如何運作	根據 LLM 推理存取多個工具；所有功能都是最新的，因為供應商控制著 MCP 伺服器	軟體使用預先定義的端點、方法和參數發送服務特定的請求
發現	LLM 可以看到並使用伺服器公開的所有工具，包括新工具	軟體只能發送已經過預先設定的 API 請求
主要使用情境	基於 AI 與代理程式的工作流程；根據自然語言提示進行動態工具選擇；AI 工具的供應商整合	高用量資料傳輸；固定、可重複的工作流程；傳統軟體整合
其他使用情境	具備多檔案和儲存庫存取權限的程式輔助工具；對企業系統的自然語言存取；AI 工具的內部可重複使用整合	自訂整合；線上交易；排程資料擷取；針對未啟用 MCP 之 AI 工具的供應商整合
設定時間	建立 MCP 連線後即可降至最低	需要在應用程式內個別設定 API 才能存取新功能
缺點	複雜任務通常具有高昂的權杖成本；對於定義明確、重複性的資料任務而言資源消耗過大	具有複雜整合的應用程式維護成本極高；不保證能夠存取目前的功能
優勢	通用標準，能夠處理複雜的工作流程，對工具的存取權限更大，設定完成後無需人工干預	對於 AI 工具中的固定和高用量工作流程，權杖消耗較少

讓我們來看一個說明 MCP 與 API 之間區別的簡單範例。在這種情況下，該請求實際上更適合使用 API（它很簡單且不需要上下文）。然而，這兩個範例清楚地展示了 MCP 如何非常適合多階段的 LLM 工作流程。

以下是用 Python 編寫的指令碼，使用 Open-Meteo API 發送天氣資訊的 API 請求：

python

import requests
url = "https://api.open-meteo.com/v1/forecast"
params = {    "latitude": 51.5072,    "longitude": -0.1276,    "current": "temperature_2m"}
response = requests.get(url, params=params)
data = response.json()
temperature = data["current"]["temperature_2m"]
print(f"Temperature in London: {temperature}°C")

此範例使用精確的請求格式透過 HTTPS 查詢 Open-Meteo，以取得緯度 51.5072 和經度 -0.1276（倫敦）當前的 2 公尺氣溫。

相反地，MCP 客戶端可以向能夠存取天氣資料庫的伺服器發送如下的 tools/call JSON-RPC 請求：

json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "London"
    }
  }
}

在這個虛構的範例中，客戶端正在要求伺服器在其登錄檔中使用特定的工具 (get-weather) 來執行任務（描述倫敦的天氣）。

關鍵區別在於，這項功能將是 MCP 伺服器提供的眾多功能之一。MCP 客戶端不需要知道特定的端點、參數、響應結構或驗證方法來產生請求。LLM 可以檢視登錄檔中的工具描述，以挑選它認為最適合完成以自然語言描述的任務的工具。

MCP 與 API 並非對立面。MCP 旨在實現更輕鬆的整合發現與維護。因此，對於非 AI 軟體連線以及依賴特定穩定 API 群組的固定 LLM 任務與工作流程，API 通常是最佳選擇。

你需要管理大型或不斷增長的工具集：MCP 客戶端可以在執行階段發現供應商伺服器公開的所有工具，隨著你的工具集增長，減少個別的 API 設定負擔。
工具選擇取決於使用者請求：當任務步驟無法預先決定時（例如使用者向聊天機器人發送各種各樣的請求），MCP 非常有用。LLM 可以檢查可用的工具名稱、描述和綱要，然後選擇最適合某個任務的工具。
供應商功能經常變更：當供應商在其應用程式中新增功能時，可以透過 MCP 立即使用。你不需要新增新的 API 或重新設定現有的 API。
你希望在多個 AI 應用程式中使用相同的整合：一個 MCP 伺服器可以向多個代理程式或應用程式公開相同的能力，從而減少重複的整合工作。

你正在擷取結構化資料：如果你的 AI 工具在使用者工作流程的特定階段擷取可預測的結構化資訊（例如出貨狀態或客戶支援工單號碼），標準的 API 請求會消耗較少權杖且耗時較短。
你的工作流程組織為固定的序列：如果你的工作流程遵循嚴格、可重複的序列，且具有精確的 API 和確切的結果，則無需使用 MCP。
你的應用程式執行高用量工作流程：權杖用量對於高用量任務而言可能會造成嚴重的限制。如果複雜的工作流程需要結合推理進行疊代式的高用量輸入或輸出，建議混用 MCP 和 API 呼叫。
AI 推理沒有帶來任何好處：如果普通的應用程式邏輯就能充分完成任務，直接進行 API 呼叫通常更簡單且資源消耗更少。

MCP 與 API 的問題主要涉及建構具備 AI 功能之應用程式的開發者。不過，你可能也想知道是否要在選定的 AI 工具中，將 MCP 用於你的專業工作流程。

同樣的一般規則適用：如果你想要以廣泛的覆蓋範圍隨時存取第三方應用程式功能，MCP 是最佳選擇。對於例行且高用量的任務，簡單的 API 設定將消耗較少的權杖。

大多數 AI 工具（包括 Perplexity）允許使用者無需編寫任何程式碼即可設定和使用 MCP 連接器。這使得在不離開聊天介面的情況下編排多步驟工作流程成為可能。例如，只需點擊幾下即可與 Gmail、HubSpot 和 Supabase 等平台進行整合。

Perplexity 的連接器目錄顯示包含 Gmail、Outlook、HubSpot、Monday.com、Supabase 和 Vercel 的整合。

MCP 的核心優勢在於動態發現和減少 API 維護負擔。透過將你的應用程式連接到 MCP 伺服器，你可以存取你所選供應商（或你的本地系統）所提供的所有最新工具、資料和提示詞。

然而，API 仍然至關重要。它們構成了應用程式互聯性的底層架構。MCP 充當應用程式與外部功能之間的中間層。它允許 AI 代理程式以適合複雜工作流程的格式存取盡可能廣泛的工具集。

MCP 與 API：主要的區別是什麼？

什麼是模型上下文協議 (MCP)？

什麼是應用程式介面 (API)？

使用情境、優勢與缺點

MCP 與 API 的實際說明

如何在 MCP 與 API 之間進行選擇

何時使用 MCP

何時使用直接 API

在 Perplexity 中使用 MCP 連接器

為什麼 MCP 讓基於 LLM 的應用程式更強大