Model Context Protocol（MCP）是一種通訊層，它為 Claude 提供上下文和工具，而不需要您撰寫大量繁瑣的整合程式碼。可以將它視為一種將工具定義和執行的負擔從您的伺服器轉移到專門的 MCP 伺服器的方式。
當您第一次接觸 MCP 時，您會看到展示基本架構的圖表：一個 MCP 客戶端（您的伺服器）連接到包含工具、提示和資源的 MCP 伺服器。每個 MCP 伺服器都充當某個外部服務的介面。
MCP 解決的問題
假設您正在建立一個聊天介面，使用者可以向 Claude 詢問他們的 GitHub 資料。使用者可能會問「我所有儲存庫中有哪些開放的 pull request？」為了處理這個問題，Claude 需要工具來存取 GitHub 的 API。
GitHub 擁有龐大的功能——儲存庫、pull request、issue、專案，還有更多。如果沒有 MCP，您需要建立大量的工具架構和函式來處理 GitHub 的所有功能。
這意味著您需要自己撰寫、測試並維護所有這些整合程式碼。這是一項巨大的工作量和持續的維護負擔。
MCP 如何運作
MCP 透過將工具定義和執行從您的伺服器轉移到專用的 MCP 伺服器來分擔這個負擔。您不需要自己撰寫所有那些 GitHub 工具，而是由一個 GitHub 的 MCP 伺服器來處理。
MCP 伺服器將大量與 GitHub 相關的功能包裝起來，並以標準化的工具集合形式公開。您的應用程式連接到這個 MCP 伺服器，而不是從頭開始實作所有功能。
MCP 伺服器說明
MCP 伺服器提供對外部服務所實作的資料或功能的存取。它們充當專門的介面，以標準化的方式公開工具、提示和資源。
在我們的 GitHub 範例中，GitHub 的 MCP 伺服器包含像 get_repos() 這樣的工具，並直接連接到 GitHub 的 API。您的伺服器與 MCP 伺服器通訊，後者處理所有 GitHub 特定的實作細節。
常見問題
誰來撰寫 MCP 伺服器？
任何人都可以建立 MCP 伺服器的實作。通常，服務提供商自己會製作他們自己的官方 MCP 實作。例如，AWS 可能會為其各種服務發布一個包含工具的官方 MCP 伺服器。
這與直接呼叫 API 有什麼不同？
MCP 伺服器提供已經為您定義好的工具架構和函式。如果您想直接呼叫 API，您將需要自己撰寫那些工具定義。MCP 為您節省了這項實作工作。
MCP 不就是和工具使用一樣嗎？
這是一個常見的誤解。MCP 伺服器和工具使用是互補但不同的概念。MCP 伺服器提供已經為您定義好的工具架構和函式，而工具使用則是關於 Claude 實際如何呼叫這些工具。關鍵的區別在於誰來做這項工作——使用 MCP 時，其他人已經為您實作好了這些工具。
好處很明顯：您不需要自己維護一套複雜的整合，而是可以利用 MCP 伺服器來處理連接外部服務的繁重工作。