Model Context Protocol（MCP）是一個通訊層，它為 Claude 提供上下文和工具，而不需要您撰寫大量繁瑣的整合程式碼。可以將其視為一種將工具定義和執行的負擔從您的伺服器轉移到專門的 MCP 伺服器的方式。
當您第一次接觸 MCP 時，您會看到展示基本架構的圖表：一個 MCP 客戶端（您的伺服器）連接到包含工具、提示和資源的 MCP 伺服器。每個 MCP 伺服器都充當某個外部服務的介面。
透過實際範例理解 MCP
假設您正在建立一個聊天介面，使用者可以向 Claude 詢問他們的 GitHub 資料。使用者可能會問「我所有儲存庫中有哪些開放的 pull request？」為了回答這個問題，Claude 需要工具來存取 GitHub 的 API。
如果沒有 MCP，您需要自己建立所有的 GitHub 整合工具。這意味著要為您想要支援的每一項 GitHub 功能撰寫結構定義（schema）和函式。
工具函式問題
GitHub 擁有龐大的功能——儲存庫、pull request、issue、專案等等。要建立一個完整的 GitHub 聊天機器人，您需要撰寫數量驚人的工具：
每個工具都需要結構定義和函式實作。這代表作為開發者，您必須撰寫、測試和維護大量的程式碼。
MCP 如何解決這個問題
MCP 將工具定義和執行的負擔從您的伺服器轉移到 MCP 伺服器。您不需要自己撰寫所有這些 GitHub 工具，它們是在專用的 MCP 伺服器內撰寫和執行的。
MCP 伺服器充當 GitHub 功能的包裝層，提供您可以直接使用的預建工具，而不必自己實作它們。
MCP 伺服器提供對外部服務所實作的資料或功能的存取。它們將複雜的整合封裝成可重複使用的元件，任何應用程式都可以連接到這些元件。
關於 MCP 的常見問題
誰撰寫 MCP 伺服器？
任何人都可以建立 MCP 伺服器實作。通常，服務提供商自己會製作他們自己的官方 MCP 實作。例如，AWS 可能會為其各種服務發布一個包含工具的官方 MCP 伺服器。
MCP 與直接呼叫 API 有何不同？
MCP 伺服器提供已經為您定義好的工具結構定義和函式。如果您直接呼叫 API，您需要自己負責撰寫這些工具定義。MCP 為您節省了這項實作工作。
MCP 不就是工具使用嗎？
這是一個常見的誤解。MCP 伺服器和工具使用是互補但不同的概念。MCP 關乎的是由誰來完成建立和維護工具的工作。使用 MCP 時，其他人已經為您撰寫好了工具函式和結構定義——它們被封裝在 MCP 伺服器內。
關鍵的洞見是，MCP 伺服器提供已經為您定義好的工具結構定義和函式，讓您不需要自己建立和維護複雜的整合。