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 需要在應用程式內進行個別設定才能存取新功能
缺點	複雜任務通常需要付出高昂的 Token 成本；對於定義明確且重複的資料任務而言，資源消耗過大	具備複雜整合之應用程式的維護成本極高；無法保證能存取最新功能
好處	通用標準，能夠處理複雜的工作流程，對工具的存取權限更大，設定後無需人工干預	對於 AI 工具中固定且高量的工作流程，Token 消耗較少

讓我們來看一個簡單的範例，說明 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 代理程式或應用程式公開相同的功能，從而減少重複的整合工作。

你需要擷取結構化資料：如果你的 AI 工具在使用者工作流程的特定階段擷取可預測的結構化資訊（例如送貨狀態或客戶支援工單編號），標準 API 要求的 Token 和時間消耗會較少。
你的工作流程組織成固定的順序：如果你的工作流程遵循嚴格且可重複的順序，並具有精確的 API 和確切的結果，則無需使用 MCP。
你的應用程式會執行高量工作流程：對於高量任務，Token 的使用量可能會特別高而構成阻礙。如果複雜的工作流程需要結合推理進行疊代式的高量輸入或輸出，則最好混合使用 MCP 與 API 呼叫。
AI 推理沒有帶來任何好處：如果一般的應用程式邏輯就能充分完成任務，那麼直接呼叫 API 通常更簡單且資源消耗更少。

MCP 與 API 的問題主要牽涉到使用 AI 功能開發應用程式的開發者。不過，你可能也想知道在選定的 AI 工具中進行專業工作流程時，是否該使用 MCP。

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

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

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

MCP 的核心優勢在於動態發現與降低 API 維護負擔。透過將你的應用程式連線至 MCP server，你可以存取所選供應商（或你的本機系統）所提供的所有最新工具、資料和提示詞。

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

MCP 與 API：主要區別為何？

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

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

使用情境、好處與缺點

MCP 與 API 的實際圖解

如何在 MCP 與 API 之間做出選擇

何時使用 MCP

何時使用直接 API

在 Perplexity 中使用 MCP 連接器

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