您唯一需要的模型上下文協議 (MCP) 指南

大型語言模型 (LLM)，例如 Anthropic 的 Claude，已經解鎖了海量上下文視窗（Claude 4 中高達 20 萬個 token），使其能夠一次性處理整個文件或程式碼庫。然而，有效地為這些模型提供相關上下文仍然是一項挑戰。傳統上，開發人員依賴於複雜的提示工程或檢索管道，將外部資訊輸入到 LLM 的提示中。Anthropic 的模型上下文協議 (MCP) 是一項新的開放標準，它簡化並標準化了這一流程。

您可以將 MCP 視為“AI 應用程式的 USB-C”——一個通用聯結器，讓您的 LLM 能夠無縫訪問外部資料、工具和系統。在本文中，我們將解釋什麼是 MCP，它對長上下文 LLM 的重要性，它與傳統提示工程的比較，並演示如何使用 Python 構建一個簡單的 MCP 相容上下文伺服器。我們還將討論實際用例（例如檢索增強生成 (RAG) 和代理工具），並提供程式碼示例、圖表和參考資料，幫助您從 MCP 和 Claude 入手。

什麼是MCP？它為何重要？

模型上下文協議 (MCP) 是 Anthropic 於 2024 年底釋出的一項開放協議。它旨在標準化 AI 應用程式向 LLM 提供上下文的方式。本質上，MCP 定義了一種通用的客戶端-伺服器架構，用於將 AI 助手連線到資料所在的位置。這既適用於本地檔案、資料庫、雲服務，也適用於業務應用程式。在 MCP 之前，將 LLM 與每個新資料來源或 API 整合意味著為每個特定案例編寫自定義聯結器或提示邏輯。這導致了整合的組合爆炸式增長：M 個 AI 應用程式乘以 N 個資料來源可能需要 M×N 個定製實現。MCP 透過提供通用介面來解決這個問題。有了它，任何相容的 AI 客戶端都可以與任何相容的資料/服務伺服器通訊。這將問題簡化為 M + N 個積分點。

MCP方法與傳統整合

為什麼 MCP 對長上下文 LLM 尤為重要？像 Claude 4 這樣的模型可以提取數百頁文字。然而，決定將哪些資訊放入這個巨大的上下文視窗並非易事。簡單地將所有潛在相關資料塞進提示框效率低下，有時甚至是不可能的。模型上下文協議 (MCP) 提供了一種更智慧的方法。LLM 或其主機應用程式可以根據需要從外部源動態檢索即時上下文。這無需預先載入所有內容。這意味著您可以充分利用 20 萬個令牌視窗的全部容量，並動態獲取相關資料。例如，只提取與使用者查詢相關的知識庫部分。MCP 提供了一種結構化的即時方法，利用外部知識來維護和擴充模型的上下文。

簡而言之，隨著 AI 助手上下文長度的增長，MCP 可以確保它們不會“被資訊孤島所困”。相反，它們可以訪問最新的事實、檔案和工具，從而更好地響應。

MCP與傳統提示工程

在 MCP 出現之前，開發人員通常使用 RA (Real Aggregation) 流水線或手動提示工程將外部資訊注入 LLM 的提示中。例如，RAG 系統可能會在文件資料庫中進行向量搜尋以查詢相關文字。然後，它可能將這些片段作為上下文插入到提示中。或者，人們可能會設計一個包含說明、示例和附加資料的單片提示。這些方法雖然有效，但它們是臨時的，缺乏標準化。

每個應用程式最終都會重新設計如何為模型獲取和格式化上下文，而整合新的資料來源意味著編寫新的粘合程式碼或提示。

MCP原語

模型上下文協議透過引入結構化上下文管理從根本上改變了這一點。MCP 不再將所有外部資訊視為更多的提示文字，而是將互動分解為三個標準化元件（或“原語”）：

• 資源 – 可以將其視為提供給模型的只讀上下文單元（資料來源）。資源可能是檔案內容、資料庫記錄或模型可以讀取的 API 響應。資源由應用程式控制。託管方或開發人員決定公開哪些資料以及如何公開。重要的是，讀取資源沒有副作用——它類似於僅獲取資料的 GET 請求。資源提供可在需要時注入模型上下文的內容（例如，在問答場景中檢索到的文件）。
• 工具 – 這些是 LLM 可以呼叫以執行操作（例如執行計算或呼叫外部 API）的操作或函式。工具由模型控制。這意味著 AI 決定是否以及何時使用它們（類似於其他框架中的函式呼叫）。例如，工具可以是“send_email(recipient, body)”或“query_database(SQL)”。使用工具可能會產生副作用（傳送資料、修改狀態），並且工具呼叫的結果可以反饋到對話中。
• 提示 – 這些是可重複使用的提示模板或指令，您可以根據需要呼叫。它們由使用者控制或由開發人員預定義。提示可能包含常見任務或指導性工作流程的模板（例如，程式碼審查模板或問答格式）。本質上，它們提供了一種一致地注入特定指令或上下文措辭的方法，而無需將其硬編碼到每個提示中。

不同於傳統的提示工程

這種結構化方法與傳統的提示工程形成對比。在傳統提示工程中，所有上下文（指令、資料、工具提示）可能都集中在一個大的提示中。而使用 MCP，上下文是模組化的。AI 助手可以發現可用的資源和工具，然後靈活地組合它們。因此，MCP 將非結構化的提示轉化為 LLM 與您的資料/工具之間的雙向對話。模型不會被盲目地交給一段文字。相反，它可以透過標準協議主動請求資料或操作。

此外，MCP 使整合具有一致性和可擴充套件性。正如 USB 的類比所示，相容 MCP 的 Google Drive 或 Slack 伺服器可以插入任何支援 MCP 的客戶端（例如 Claude、IDE 外掛等）。開發者無需為每個應用工具組合編寫新的提示邏輯。這種標準化也促進了社羣共享：您可以利用預先構建的 MCP 聯結器，而不必重新開發它們。Anthropic 已經開源了許多適用於常見系統的 MCP 伺服器，包括檔案系統、GitHub、Slack、資料庫等，您可以重複使用或從中學習。總而言之，MCP 提供了一種統一且模組化的方式，為 LLM 提供上下文和功能。

MCP架構和資料流

從高層次來看，模型上下文協議 (MCP) 在 AI 應用中遵循客戶端-伺服器架構。讓我們來分解一下關鍵元件及其互動方式：

MCP 的 USB Type-C 類比圖

主機

主機是與終端使用者互動的主要 AI 應用程式或介面。它可以是聊天機器人 UI（例如，Claude 的聊天應用程式或自定義 Web 應用程式），也可以是 IDE 擴充套件，或任何“AI 助手”環境。主機包含或呼叫 LLM 本身。例如，Claude Desktop 就是一個主機——它是一個 Claude（LLM）與使用者對話的應用程式。

MCP客戶端

MCP 客戶端是執行在主機應用程式中的元件（通常是一個庫）。它管理與一個或多個 MCP 伺服器的連線。您可以將客戶端視為介面卡或中間人。它使用 MCP 協議，處理訊息傳遞、請求和響應。每個 MCP 客戶端通常處理一個伺服器連線。因此，如果主機連線到多個資料來源，它將例項化多個客戶端。實際上，客戶端負責發現伺服器功能。它將 LLM 的請求傳送到伺服器並轉發響應。

MCP伺服器

伺服器是一個外部（或本地）程式，它封裝了 MCP 標準背後的特定資料來源或功能。伺服器根據 MCP 規範“公開”一組工具、資源和提示。例如，伺服器可能會公開您的檔案系統（允許 LLM 將檔案作為資源讀取），或者 CRM 資料庫，或者第三方 API，例如天氣或 Slack。伺服器處理傳入的請求（例如“讀取此資源”或“執行此工具”）。然後，它以客戶端和 LLM 可以理解的格式返回結果。

這些元件透過定義的傳輸層進行通訊。MCP 支援多種傳輸方式。對於本地伺服器，可以使用簡單的 STDIO 管道。同一臺計算機上的客戶端和伺服器透過標準輸入/輸出流進行通訊。對於遠端伺服器，MCP 使用帶有伺服器傳送事件 (SSE) 的 HTTP 來維持持久連線。 MCP 庫抽象了傳輸細節，但瞭解本地整合無需任何網路即可實現這一點很有用。並且遠端整合可以透過 Web 協議進行。

MCP 客戶端伺服器架構

MCP中的資料流

一切設定完成後，使用者與 AI 助手互動時，互動將遵循以下順序：

MCP 中的資料流

1. 初始化與握手——當主機應用程式啟動或新增新伺服器時，MCP 客戶端會與伺服器建立連線。它們會進行握手以驗證協議版本並交換基本資訊。這確保雙方使用相同的 MCP 版本並理解彼此的訊息。
2. 功能發現——連線後，客戶端會詢問伺服器它可以做什麼。伺服器會返回可用工具、資源和提示模板（包括描述、引數架構等）的列表。例如，伺服器可能會報告：“我有一個用於讀取檔案的資源‘file://{path}’，一個用於獲取天氣的工具‘get_weather(lat, lan)’，以及一個提示模板‘summarize(text)’。”主機可以使用這些資訊向使用者呈現選項或告知 LLM 可用的功能。
3. 上下文配置 —— 宿主可以在對話開始時主動獲取一些資源或選擇提示模板來擴充模型的上下文。例如，IDE 可以使用 MCP 伺服器將使用者的當前檔案載入為資源，並自動將其內容包含在 Claude 的上下文中。或者，宿主可以在 LLM 開始生成之前應用提示模板（如特定的系統指令）。在此階段，宿主基本上將來自 MCP 資源/提示的初始上下文注入到 LLM 的輸入中。
4. LLM 呼叫和工具使用 —— 使用者的查詢以及任何初始上下文都會提供給 LLM。當 LLM 處理查詢時，它可以決定根據需要呼叫其中一個可用的 MCP 工具。例如，如果使用者詢問“repo X 中有哪些未解決的問題？”，模型可能會確定它需要呼叫 GitHub MCP 伺服器提供的 get_github_issues(repo) 工具。當模型“決定”使用某個工具時，主機的 MCP 客戶端會收到該函式呼叫請求（這類似於其他 LLM API 中的函式呼叫）。然後，客戶端將呼叫傳送到負責的 MCP 伺服器。
5. 外部操作執行 —— MCP 伺服器接收工具呼叫，透過與外部系統互動（例如，呼叫 GitHub 的 API）進行操作，然後返回結果。在我們的示例中，它可能會返回一個問題標題列表。
6. 響應整合 —— MCP 客戶端接收結果並將其傳回主機/LLM。通常，結果會被整合到 LLM 的上下文中，就像模型“看到”它一樣。繼續這個例子，問題標題列表可以結束對話（通常作為包含工具輸出的系統或助手訊息）。LLM 現在擁有它獲取的資料，並可以使用它來制定最終答案。
7. 最終答案生成 ——利用上下文中的相關外部資料，LLM 生成對使用者的答案。從使用者的角度來看，助手使用即時知識或操作進行回答，但得益於 MCP，整個過程標準化且安全。

至關重要的是，模型上下文協議 (MCP) 在整個流程中強制執行安全性和使用者控制。未經明確許可，任何工具或資源都無法使用。例如，Claude 在 Claude Desktop 中實現的 MCP 要求使用者批准每個伺服器，並可以在某些敏感操作之前提示。大多數 MCP 伺服器預設在本地或使用者的基礎架構中執行，除非您明確允許遠端連線，否則資料將保持私密。所有這些都確保了 LLM 透過 MCP 訪問您的檔案系統或資料庫等資源不會變成混戰；您可以控制其可見內容或操作。

使用Python構建簡單的MCP上下文伺服器（分步指南）

模型上下文協議作為開放標準的一大優勢在於，您可以使用多種語言實現伺服器。Anthropic 和社羣提供了 Python、TypeScript、Java、Kotlin、C# 等語言的 SDK。這裡，我們將重點介紹 Python，並構建一個簡單的 MCP 相容伺服器，以說明如何定義和使用上下文單元（資源）和工具。我們假設您已安裝 Python 3.9 及以上版本。

注意：本教程使用記憶體資料結構來模擬真實世界的行為。示例無需外部資料集。

步驟 1：設定和安裝

首先，您需要一個 MCP 庫。您可以透過 pip 安裝 Anthropic 的官方 Python SDK（mcp 庫）。此外，還有一個名為 FastMCP 的高階輔助庫，它可以幫助您更輕鬆地構建伺服器（它是一個流行的社羣 SDK）。為了簡潔起見，本指南使用 fastmcp。您可以使用以下命令安裝它：

  pip install fastmcp

（或者，您也可以使用官方 SDK，概念相同。）

步驟 2：定義MCP伺服器和上下文單元

MCP 伺服器本質上是一個程式，它宣告一些工具/資源並等待客戶端請求。讓我們建立一個提供兩種功能的簡單伺服器來演示 MCP 的上下文構建：

• 一個資源，透過 ID 提供“文章”的內容——模擬知識庫查詢。這將充當模型可以檢索的上下文單元（一些文字資料）。
• 一個工具，用於將兩個數字相加——這是一個模型可以呼叫的函式的簡單示例（僅用於演示工具用法）。

from fastmcp import FastMCP
# Initialize the MCP server with a name 
mcp = FastMCP("DemoServer")
# Example data source for our resource 
ARTICLES = {
"1": "Anthropic's Claude is an AI assistant with a 100K token context window and advanced reasoning abilities.",
"2": "MCP (Model Context Protocol) is a standard to connect AI models with external tools and data in a unified way.",
}
# Define a Resource (context unit) that provides an article's text by ID @mcp.resource("article://{article_id}")
def get_article(article_id: str) -> str: 
"""Retrieve the content of an article by ID."""
return ARTICLES.get(article_id, "Article not found.")
# Define a Tool (function) that the model can call @mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers and return the result.""" 
return a + b
# (Optional) Define a Prompt template for demonstration @mcp.prompt()
def how_to_use() -> str:
"""A prompt template that instructs the assistant on using this server."""
return "You have access to a DemoServer with an 'article' resource and an 'add' tool."
if name=="main":
# Run the server using standard I/O transport (suitable for local client connection)
mcp.run(transport="stdio")

讓我們分解一下這裡發生的事情：

• 我們建立一個名為“DemoServer”的 FastMCP 伺服器例項。客戶端使用該名稱來引用此伺服器。
• 我們定義一個字典 ARTICLES 來模擬一個小型知識庫。在實際場景中，資料庫查詢或 API 呼叫可以替代它，但目前它只是記憶體資料。
• @mcp.resource(“article://{article_id}”) 裝飾器將 get_article 函式暴露為資源。字串“article://{article_id}”是一個 URI 模板，指示如何訪問此資源。MCP 客戶端將看到此伺服器提供了一個帶有 schema 為 article://… 的資源，並且可以請求例如 article:// 1 這樣的資源。呼叫 get_article 時，它會返回一個字串（文章文字）。該文字是將傳遞給 LLM 的上下文單元。注意，它沒有任何副作用——這是一個只讀的資料檢索。
• @mcp_tool 裝飾器暴露並新增一個工具。它接受兩個整數並返回它們的和。這是一個簡單的例子，僅用於說明一個工具；真正的工具可能類似於呼叫外部 API 或修改某些內容。重要的是，模型的選擇會呼叫這些工具，而這些工具可能會產生副作用。
• 為了完整性，我們還展示了 @mcp_prompt()。它定義了一個 Prompt 模板，可以提供預設指令。在本例中，how_to_use 返回一個固定的指令字串。Prompt 單元可以幫助指導模型（例如，提供使用示例或格式），但它們是可選的。使用者可以在模型執行之前選擇它們。
• 最後，mcprun(transport=”stdio”) 啟動伺服器並等待客戶端連線，透過標準 I/O 進行通訊。如果我們想將其作為獨立的 HTTP 伺服器執行，可以使用其他傳輸方式（例如帶有 SSE 的 HTTP），但 stdio 非常適合本地上下文伺服器，例如，Claude Desktop 可以在您的計算機上啟動它。

步驟 3：執行伺服器並連線客戶端

為了測試我們的模型上下文協議 (MCP) 伺服器，我們需要一個 MCP 客戶端（例如 Claude）。一個簡單的方法是使用 Claude 的桌面應用程式，它開箱即用地支援本地 MCP 伺服器。在 Claude 的設定中，您可以新增一個指向 demo_server.py 的配置。它在 Claude 的配置檔案中看起來如下（虛擬碼用於說明）：

JSON
{
"mcpServers": 
{ "DemoServer": 
{
"command": "python",
"args": ["/path/to/demo_server.py"]
}
}
}

這會指示 Claude Desktop 在啟動時啟動我們的 Python 伺服器（使用給定的命令和指令碼路徑）。執行後，Claude 將執行握手和發現。我們的伺服器會通告它擁有一個 article://{id} 資源、一個新增工具和一個提示模板。

如果您使用的是 Anthropic API 而不是 Claude 的 UI，Anthropic 在其 API 中提供了一個 MCP 聯結器。您可以在此處指定要在對話期間使用的 MCP 伺服器。本質上，您需要配置 API 請求以包含伺服器（或其功能）。這有助於 Claude 瞭解它可以呼叫這些工具或獲取這些資源。

步驟 4：使用上下文單元和工具

現在，伺服器連線好了，它如何在對話中使用？讓我們來看兩個場景：

使用資源（檢索）

假設使用者問 Claude：“Anthropic 的 MCP 簡單來說是什麼？”由於我們擁有可能包含答案的文章資源，Claude（或主機應用程式邏輯）可以獲取該上下文。一種方法是，主機可以主動呼叫（因為我們資料中的第 2 篇文章與 MCP 有關），並將其內容作為上下文提供給 Claude。或者，如果 Claude 已設定為推理可用資源，則它可能會在分析問題後內部請求 article://2。無論哪種情況，DemoServer 都會收到對 article://2 的讀取請求，並返回：“MCP（模型上下文協議）是一種以統一方式將 AI 模型與外部工具和資料連線起來的標準。” 然後，Claude 模型將文字視為附加上下文，並可以使用它為使用者構建簡潔的答案。本質上，文章資源充當了一個上下文單元——在執行時注入到提示中的一段知識，而不是 Claude 固定訓練資料或手動生成的提示的一部分。

使用工具（函式呼叫）

現在，假設使用者問：“2 + 5 等於多少？請解釋一下 MCP。” Claude 當然可以自己計算 (2 + 5)，但由於我們為其提供了一個加法工具，它可能會使用它。在生成過程中，模型會發出一個函式呼叫：add(2, 5)。MCP 客戶端會攔截此呼叫並將其路由到我們的伺服器。add 函式執行（返回 7），並將結果返回。然後，Claude 會獲取結果（在上下文中可能類似於：工具返回：7），並繼續回答問題。這是一個簡單的數學示例，但它展示了 LLM 如何透過 MCP 利用外部工具。在更現實的場景中，工具可以是 search_documents(query) 或 send_email(to, content) 之類的東西，即類似代理的功能。 MCP 允許這些工具乾淨地整合並安全地進行沙盒處理（該工具在我們的伺服器程式碼中執行，而不是在模型內部，因此我們可以完全控制它的功能）。

步驟 5：測試和迭代

在開發您自己的 MCP 伺服器時，測試 LLM 是否能夠按預期使用它非常重要。Anthropic 提供了一個 MCP Inspector 工具來除錯伺服器，並且您可以隨時使用日誌檢視請求/響應流程。例如，直接執行我們的 demo_server.py 可能會等待輸入（因為它需要 MCP 客戶端）。您可以編寫一個小指令碼，使用 MCP 庫的客戶端功能來模擬客戶端請求。但是，如果您有 Claude Desktop，這裡有一個簡單的測試：連線伺服器。然後在 Claude 的聊天中，詢問一些觸發您的資源或工具的問題。檢查 Claude 的對話或日誌，以驗證它是否已獲取資料。

提示：當 Claude Desktop 連線到您的伺服器時，您可以點選“工具”或“資源”面板，檢視 get_article 和 add 功能是否已列出。如果沒有，請仔細檢查您的配置以及伺服器是否已正確啟動。為了進行故障排除，Anthropic 的文件建議在 Claude 中啟用詳細日誌。您甚至可以在桌面應用中使用 Chrome DevTools 檢查 MCP 訊息。這種詳細程度有助於確保您的上下文伺服器平穩執行。

MCP的實際用例

現在我們已經瞭解了模型上下文協議 (MCP) 的工作原理，讓我們討論一些與開發者相關的實際應用：

使用MCP的檢索增強生成 (RAG)

MCP 最明顯的用例之一是利用外部知識（即 RAG）改進 LLM 響應。您可以建立一個與您的知識庫互動的 MCP 伺服器，而無需使用單獨的檢索管道並手動將結果填充到提示中。例如，您可以構建一個“文件伺服器”，連線到您公司的 Confluence 或文件向量資料庫。該伺服器可能公開一個搜尋工具（例如，search_docs(query) –> list[doc_id]）和一個資源（例如，doc://{doc_id} 用於獲取內容）。

當使用者提出問題時，Claude 可以透過 MCP 呼叫 search_docs 來查詢相關文件（或許會使用底層的嵌入），然後呼叫 doc://… 資源來檢索這些頂級文件的全文。這些文字會被輸入到 Claude 的上下文中，Claude 可以使用直接引用或文件中的最新資訊進行回答。所有這些都透過標準化協議進行。這意味著，即使您之後切換到支援 MCP 的其他 LLM，或者使用不同的客戶端介面，您的文件伺服器仍然可以正常工作。

您可以在此處檢視我們關於如何使用 MCP 執行 RAG 的文章。

事實上，許多早期採用者正是這樣做的：連線知識庫和資料儲存。Anthropic 的新聞稿提到，像 Block 這樣的組織以及像 Source graph 和 Replit 這樣的初創公司正在與 MCP 合作，讓 AI 代理從其現有系統中檢索程式碼上下文、文件等資訊。其好處顯而易見：增強模型的上下文感知能力，可以帶來更準確、更相關的答案。您將獲得一個能夠處理長上下文的助手，而不是一個只能感知到訓練截止值（並幻化最新資訊的助手）。例如，它可以從資料庫或使用者的個人資料（經使用者許可）中提取最新的產品規格，從而提供定製化的答案。簡而言之，MCP 增強了長上下文模型的功能。它確保這些模型始終擁有正確的上下文，而不僅僅是大量的上下文。

代理操作和工具使用

除了靜態資料檢索之外，模型上下文協議 (MCP) 還旨在支援代理行為，即 LLM 可以在外部世界中執行操作。使用 MCP 工具，您可以賦予模型執行諸如傳送訊息、建立 GitHub 問題、執行程式碼或控制物聯網裝置等操作的能力（可能性無窮無盡，僅受您公開的工具限制）。關鍵在於 MCP 為此提供了一個安全、結構化的框架。每個工具都有定義好的介面，並且需要使用者選擇加入。這降低了讓人工智慧執行任意操作的風險，因為作為開發者，您可以明確定義哪些操作是允許的。

考慮將一個程式設計助手整合到您的 IDE 中。使用 MCP，它可能會連線到 Git 伺服器和一個測試框架。該助手可能包含一個 run_tests() 工具和另一個 git_commit(message) 工具。當您要求它實現某個功能時，它可以在 IDE 中編寫程式碼，然後決定透過 MCP 呼叫 run_tests() 來執行測試套件，獲取結果，如果一切順利，則呼叫 git_commit() 提交更改。MCP 聯結器簡化了所有這些步驟（適用於測試執行器和 Git）。 IDE（主機）負責協調整個流程，確保您批准。這並非空想——開發人員正在積極開發此類代理整合。例如，Zed（程式碼編輯器）和其他 IDE 外掛背後的團隊一直在與 MCP 合作，以使 AI 助手能夠更好地理解和引導程式設計任務。

另一個例子：客戶支援聊天機器人可以使用工具來重置使用者密碼或檢索訂單狀態（透過連線到內部 API 的 MCP 伺服器）。AI 可以無縫地端到端處理支援請求：查詢訂單（讀取資源）併發起退款（工具操作），同時記錄所有操作。MCP 的標準化日誌記錄和安全模型在這方面發揮了作用——例如，它可以在執行退款等操作之前要求明確確認，並且所有事件都會經過統一的監控管道。

藉助模型上下文協議 (MCP)，代理正規化變得更加健壯，因為任何 AI 代理框架都可以利用同一套工具。值得注意的是，就連 OpenAI 也宣佈了支援 MCP 的計劃，這表明它可能會成為類似外掛功能的跨平臺標準。這意味著，為您的工具或服務構建 MCP 伺服器，可以讓多個 AI 平臺（例如 Claude、潛在的 ChatGPT 等）使用它。LLM 工具生態系統由此趨向於一個共同點，使開發者能夠獲得更高的複用率，併為使用者提供更強大的 AI 助手。

多模態和複雜工作流程

模型上下文協議 (MCP) 不僅限於基於文字的資料。資源也可以是二進位制或其他格式（它們具有 MIME 型別）。您可以透過資源將影像或音訊檔案作為 base64 字串或資料流提供，並讓 LLM 對其進行分析（如果 LLM 具備該功能），或者將它們傳遞給其他模型。例如，MCP 伺服器可以公開使用者的影像集合——模型可以透過檔名檢索照片作為資源，然後使用其他工具將其傳遞給影像字幕服務，並在對話中使用該字幕。

此外，MCP 有一個“提示”的概念（我們在程式碼中簡要新增了它），它允許更復雜的多步驟工作流程。提示模板可以指導模型按特定順序使用某些工具。例如，“文件問答”提示可能會指示模型：“首先，使用 search_docs 工具在文件中搜尋相關資訊。然後使用 doc:// 資源讀取最頂部的結果。

最後，引用該資訊回答問題。” 此提示可以是伺服器提供的模板之一，使用者可以明確呼叫它來執行任務（或者主機根據上下文自動選擇它）。雖然並非絕對必要，但提示單元提供了另一個槓桿，以確保模型有效地使用可用的工具和上下文。

最佳實踐、優勢和後續步驟

使用模型上下文協議 (MCP) 進行開發確實會引入一些初始學習曲線（就像任何新框架一樣）。但它也帶來了顯著的優勢：

• 標準化整合 – 您只需編寫一次聯結器，即可與任何相容 MCP 的 AI 系統協同工作。這減少了重複工作，並使您的上下文/工具易於共享。例如，您無需編寫單獨的程式碼將 Slack 與每個 AI 應用整合，而是可以擁有一個 Slack MCP 伺服器並在任何地方使用。
• 增強的上下文和準確性 – 透過將即時、結構化的上下文引入 LLM 的世界，您可以獲得更準確、更即時的輸出。您不再需要對資料庫中的答案產生幻想 – 模型只需透過 MCP 查詢資料庫即可獲得真實結果。
• 模組化和可維護性 – MCP 鼓勵清晰的關注點分離。您的“上下文邏輯”位於 MCP 伺服器中。您可以獨立開發和測試它，甚至可以為每個工具/資源進行單元測試。您的核心應用程式邏輯仍然清晰。這種模組化設計使得更新某個部分更容易，而不會破壞其他部分。這類似於微服務如何將後端系統模組化。
• 安全與控制 – 由於 MCP 的本地優先設計和明確的許可權模型，您可以嚴格控制 AI 的訪問許可權。您可以在本地執行所有伺服器，將敏感資料保留在內部。每個工具呼叫都可以記錄，甚至可能需要使用者確認。這對於注重資料治理的企業採用至關重要。
• 面向未來 – 隨著 AI 生態系統的發展，擁有開放協議意味著您不會被鎖定在某個供應商的專有外掛系統中。Anthropic 已經開源了 MCP 規範並提供了詳細的文件，並且圍繞它的社羣正在不斷發展壯大。不難想象，MCP（或類似的東西）將成為 AI 代理與世界互動的主流方式。現在加入 MCP，可以讓您領先一步。

關於後續步驟，以下是一些關於 MCP 的建議：

• 檢視官方資源 – 閱讀官方 MCP 規範和文件，深入瞭解所有訊息型別和功能（例如，像取樣機制這樣的高階主題，伺服器可以請求模型完成文字，而我們這裡沒有介紹）。該規範編寫精良，深入介紹了該協議。
• 探索 SDK 和示例 – MCP GitHub 組織擁有 SDK 和示例伺服器庫。例如，您可以找到常見整合（檔案系統、Git、Slack、資料庫聯結器等）的參考實現，以及社羣為許多其他服務貢獻的伺服器。這些非常適合透過示例學習，甚至可以開箱即用。
• 在 MCP 中試用 Claude – 如果您可以訪問 Claude（桌面應用程式或透過 Claude 4 或 Claude-instant 的 API），請嘗試啟用 MCP 伺服器，看看它如何增強您的工作流程。Anthropic 的快速入門指南可以幫助您設定您的第一個伺服器。 Claude 4（尤其是 Claude Code 和 Claude for Work）在設計時就考慮到了這些整合。因此，它是一個非常適合進行實驗的沙盒。
• 構建和共享 – 考慮為您關注的工具或資料來源構建一個小型 MCP 伺服器——例如 Jira 聯結器、Spotify 播放列表閱讀器或 Gmail 電子郵件摘要器。它不必太複雜。即使是將一個簡單的 API 封裝到 MCP 中，也能帶來啟發。而且由於 MCP 是開放的，您可以與他人分享您的創作。誰知道呢，您的 MCP 整合或許能滿足許多開發者的需求。

小結

Anthropic 的模型上下文協議 (MCP) 代表著在使 LLM 以標準化、開發者友好的方式感知上下文並可執行操作方面邁出了重要一步。透過將上下文提供和工具使用分離到一個正式的協議中，MCP 將我們從脆弱的即時駭客攻擊和一次性整合中解放出來。取而代之的是，我們獲得了一個即插即用的生態系統，在這個生態系統中，AI 模型可以像我們的常規軟體一樣流暢地連線到豐富的資料和服務。在上下文視窗越來越長的時代，模型上下文協議 (MCP) 就像管道一樣，能夠傳遞正確的資訊，從而有效地填充這些視窗。

對於開發者來說，這是一個令人興奮的領域，值得深入探索。我們只是透過一個簡單的演示來觸及皮毛，但您可以想象一下，當您將多個 MCP 伺服器組合在一起時，將會有多麼無限的可能性——您的 AI 助手可以同時從文件 Wiki 中提取知識、與您的日曆互動以及控制物聯網裝置，所有這些都只需一次對話即可完成。而且，由於這一切都是標準化的，您可以減少處理提示的時間，而將更多的時間投入到構建酷炫的功能上。

我們鼓勵您嘗試 MCP 和 Claude：試用示例伺服器，構建您自己的伺服器，並將其整合到您的 AI 專案中。作為由大型 AI 實驗室和不斷發展的社羣支援的開放標準，MCP 可能成為我們構建 AI 應用的基石，就像 USB 在裝置連線領域變得無處不在一樣。儘早參與其中，您可以幫助塑造這個生態系統，並確保您的應用始終處於情境感知 AI 的前沿。