Model Context Protocol （MCP） – MCP Protocol 部落格

掌握MCP工具開發：讓AI智慧體發揮最大潛力

Thu, 12 Sep 2024 00:00:00 +0000

在AI智慧體快速發展的今天，工具的品質直接決定了智慧體的能力邊界。一個精心設計的工具可以讓智慧體事半功倍，而糟糕的工具設計則可能讓最強大的AI模型也束手無策。

那麼，如何為AI智慧體編寫真正有效的工具呢？基於Anthropic團隊在大規模MCP工具開發中的實務經驗，我們總結出了一套系統化的方法論。

重新思考工具設計理念

傳統軟體開發中，我們習慣於為確定性系統編寫程式碼 —— 相同輸入必然產生相同輸出。但AI智慧體是非確定性的，它們面對同樣的問題可能選擇不同的解決路徑。

這種本質差異要求我們從根本上重新思考工具設計：

傳統API設計：為開發者優化，注重功能完整性
智慧體工具設計：為AI優化，注重認知友好性

例如，一個返回所有聯絡人的list_contacts工具對程式來說很正常，但對智慧體而言卻是災難 —— 它需要逐token處理每個聯絡人，浪費寶貴的上下文空間。更好的選擇是search_contacts工具，讓智慧體能直接定位到相關資訊。

系統化的工具開發流程

1. 快速原型驗證

不要試圖一步到位設計完美工具。從簡單原型開始：

# 快速原型範例
@mcp_tool
def schedule_meeting(attendee_email: str, duration_minutes: int = 30):
 """為智慧體設計的會議安排工具"""
 # 整合多個步驟：查找可用時間 + 建立會議 + 發送邀請
 available_slots = find_availability(attendee_email)
 meeting = create_meeting(available_slots[0], duration_minutes)
 send_invitation(meeting, attendee_email)
 return f"已安排與{attendee_email}的{duration_minutes}分鐘會議"

2. 建構評估體系

這是決定工具品質的關鍵步驟。建立基於真實場景的評估任務：

優秀的評估任務範例：

“客戶ID 9182報告重複扣費，請查找相關記錄並確定是否有其他客戶受影響”
“為Sarah Chen準備留存方案，分析她的離開原因和最佳挽留策略”

避免的簡單任務：

“查詢客戶ID 9182的資訊”
“搜尋支付記錄”

3. 智慧體協作優化

利用AI來優化AI工具 —— 這聽起來很meta，但非常有效：

讓Claude分析工具使用記錄
識別常見的失敗模式
自動優化工具描述和參數
驗證改進效果

五個核心設計原則

原則1：選擇正確的抽象層次

# ❌ 過於底層
def list_users() -> List[User]: pass
def list_events() -> List[Event]: pass
def create_event(user_ids, time): pass

# ✅ 合適的抽象
def schedule_event(participants: str, topic: str) -> str:
 """找到參與者共同空閒時間並建立會議"""
 pass

原則2：智慧命名空間

使用前綴清晰區分不同服務和資源：

asana_search_projects vs jira_search_issues
slack_send_message vs email_send_message

原則3：返回有意義的上下文

# ❌ 技術細節過多
{
 "user_uuid": "a1b2c3d4-e5f6-7890",
 "avatar_256px_url": "https://...",
 "mime_type": "image/jpeg"
}

# ✅ 智慧體友好
{
 "name": "張三",
 "role": "產品經理",
 "avatar_url": "https://...",
 "status": "線上"
}

原則4：Token效率優化

支援分頁和過濾
提供簡潔/詳細兩種回應模式
智慧截斷長內容
清晰的錯誤提示

原則5：精確的工具描述

工具描述是智慧體理解工具用途的唯一途徑，必須：

明確說明工具的作用和適用場景
詳細描述參數含義和格式要求
提供使用範例和注意事項
避免歧義和技術術語

實戰建議

開發工作流程

原型測試 → 2. 使用者測試 → 3. 評估設計 → 4. 效能測試 → 5. 智慧體分析 → 6. 迭代優化

常見陷阱

為每個API端點建立對應工具（過度細分）
返回過多技術細節（認知負擔）
工具功能重疊（選擇困難）
忽視工具描述品質（理解偏差）

效能指標

除了準確率，還要關注：

工具呼叫次數和效率
Token消耗量
任務完成時間
錯誤率和類型

未來展望

隨著AI模型能力的快速提升，工具開發也必須與時俱進。透過系統化的評估驅動開發方法，我們能確保工具品質跟上AI能力的發展步伐。

記住：有效的工具不是技術的簡單包裝，而是為智慧體認知特性專門設計的介面。

想深入瞭解MCP工具開發？查看我們的完整教學，獲取更多實務指導和程式碼範例。

加入MCP中文社群
關注 mcpcn.com 獲取最新的MCP開發資訊和最佳實務分享。

MCP協議下一版本發布計劃更新

Fri, 26 Sep 2025 10:00:00 -0800

發布時間表

Model Context Protocol規範的下一版本將於 2025年11月25日 正式發布，候選版本(RC)將於 2025年11月11日 推出。

我們設置了14天的RC驗證窗口期，以便客戶端實現者和SDK維護者充分測試協議變更。這種方法既給我們提供了完成關鍵改進所需的專注時間，也讓我們在實踐中應用新的治理模型。

今年夏天的進展

我們上一個規範版本於2025年6月18日發布，重點關注結構化工具輸出、基於OAuth的授權機制、服務器發起的用戶交互激發(elicitation)，以及改進的安全最佳實踐。

此後，我們專注於為MCP生態系統建立更多基礎：

正式治理結構

我們建立了MCP正式治理模型，包括定義的角色和決策機制。還開發了規範增強提案(SEP)流程，為貢獻規範變更提供明確指導。

我們的目標是透明化——讓決策程序對所有人清晰可見。像任何服務於快速發展社區的新系統一樣，我們的治理模型仍在完善中。隨著協議和社區的持續發展，我們正在積極優化它。

工作組

我們啟動了工作組和興趣組以促進社區協作。這些組織服務於多個目的：

為新貢獻者提供清晰的切入點
賦能社區成員在其專業領域主導項目
在生態系統中分佈所有權，而不是集中在核心維護者中

我們正在開發治理結構，賦予這些組織在決策和實施方面更大的自主權。這種分佈式方法確保協議能夠滿足社區需求，同時在不同領域保持質量和一致性。

Registry開發

9月，我們發布了MCP Registry預覽版——一個用於索引和發現MCP服務器的開放目錄和API。Registry作為可用MCP服務器的單一真實來源，支持組織可根據特定需求定製的公共和私有子註冊表。

構建MCP Registry是真正的社區努力成果。任何MCP客戶端都可以通過原生API或第三方註冊表聚合器使用registry內容，讓用戶更容易發現MCP服務器並將其集成到AI工作流中。

下一版本的優先領域

隨著治理和基礎設施基礎的到位，我們專注於工作組確定的五個關鍵協議改進。

異步操作

目前，MCP主要基於同步操作構建——當你調用一個工具時，一切停下來等它完成。這對快速任務很好用，但需要幾分鐘或幾小時的操作呢？

Agents工作組正在添加異步支持，允許服務器啟動長時間運行的任務，客戶端可以稍後回來查看結果。你可以在SEP-1391跟進進度。

無狀態和可擴展性

隨著組織在企業規模部署MCP服務器，新的需求不斷湧現。當前實現通常需要在請求之間記住信息，這使得在多個服務器實例間橫向擴展變得困難。

雖然可流式HTTP傳輸提供了一些無狀態支持，但服務器啟動和會話處理方面仍存在痛點。Transport工作組正在解決這些粗糙邊緣，讓MCP服務器更容易在生產環境中運行，同時為想要更複雜有狀態功能的團隊保持簡單的升級路徑。

服務器身份標識

目前，如果你想知道MCP服務器能做什麼，必須先連接到它。這讓客戶端難以瀏覽可用服務器，或讓我們的registry等系統自動編目功能。

我們通過讓服務器通過.well-known URL發布自己來解決這個問題——這是提供元數據的既定標準。可以把它想像成服務器的名片，任何人無需先敲門就能閱讀。這將讓每個MCP消費者的發現體驗更加直觀。

官方擴展

隨著MCP的發展，我們注意到針對特定行業和用例的模式不斷湧現——有價值的實現不一定屬於核心協議規範。

我們正在官方認可和記錄最流行的協議擴展，而不是讓每個人都重新發明輪子。這個經過驗證的模式精選集將為構建醫療保健、金融或教育等專業領域的開發者提供堅實的起點，而不是從頭構建每個自定義集成。

SDK支持標準化

今天選擇MCP SDK可能具有挑戰性——很難衡量你將獲得的支持水平或規範合規性。一些SDK更新速度很快，而其他SDK在功能方面可能滯後。

我們正在為SDK引入清晰的分層系統。在承諾依賴之前，你將確切知道你正在簽約什麼，基於規範合規速度、維護響應能力和功能完整性等因素。

徵集貢獻者

MCP的強大隻因其背後的社區。無論你是熱衷於構建SDK的個人開發者，還是希望投資生態系統的公司，我們在幾個關鍵領域需要你的幫助。

SDK維護

TypeScript SDK - 需要更多維護者進行功能開發和bug修復
Swift SDK - 需要關注以支持Apple生態系統
其他語言SDK歡迎持續貢獻

工具開發

Inspector - 為MCP服務器開發者開發和維護調試工具
Registry - 後端API和CLI開發；特別歡迎Go專業知識

來自客戶端開發者的反饋

我們經常談論MCP服務器，但客戶端同樣重要——它們是連接用戶與整個MCP生態系統的橋樑。如果你正在構建MCP客戶端，你從獨特角度看待協議，我們需要這種視角嵌入協議設計中。

你在實現挑戰、性能瓶頸和用戶需求方面的實戰經驗直接影響協議下一步應該走向何方。無論是對現有功能的反饋還是簡化開發者體驗的想法，我們都想聽到你的聲音。

加入官方MCP Discord的#client-implementors工作組頻道。

展望未來

隨著治理結構和工作組的到位，我們更有能力高效處理重大協議改進，同時確保每個人在流程中都有發言權。今年夏天完成的基礎工作為我們提供了堅實的構建基礎。

11月即將推出的改進——異步操作、更好的可擴展性、服務器發現和標準化擴展——將幫助MCP成為生產AI集成的更強大支柱。但我們無法獨自完成。

MCP的力量一直在於它是由社區為社區構建的開放協議。我們很高興繼續一起構建它。

感謝你的持續支持，期待很快分享更多內容。

Chrome DevTools MCP：讓AI編程助手告別盲目編程，實現可視化除錯

Wed, 24 Sep 2025 00:00:00 +0000

2024年9月23日，Google Chrome團隊發布了一個令開發者社群振奮的消息：Chrome DevTools MCP伺服器正式發布公開預覽版。這個基於Model Context Protocol的創新工具，讓AI編程助手終於能夠「看見」程式碼在瀏覽器中的真實表現，徹底改變了AI輔助開發的體驗。

AI編程的「盲點」：看不見的執行效果

正如Chrome團隊在官方部落格中指出的：編程代理面臨一個根本問題——它們無法看到生成的程式碼在瀏覽器中的實際效果，本質上是在矇眼編程。無論是Claude、Copilot還是Cursor，都面臨這個核心挑戰。

傳統AI編程的「盲區」現狀

想像這樣一個場景：你要求AI助手修復一個CSS版面問題。傳統流程如下：

開發者: "修復這個按鈕的對齊問題"
AI助手: "試試這個CSS程式碼..."
開發者: [複製貼上 → 重新整理瀏覽器 → 檢查效果]
結果: 仍然有問題，需要多輪迭代

核心問題分析：

純文字互動：AI只能基於程式碼本身進行分析和建議
無法驗證效果：生成的樣式、版面程式碼需要人工測試
效能盲區：無法分析頁面載入速度、Core Web Vitals指標
除錯困難：無法檢查控制檯錯誤、網路請求失敗
使用者體驗脫節：無法模擬真實的使用者互動流程

根據GitHub統計，開發者在AI生成程式碼後的驗證和除錯環節，通常要花費生成時間的3-5倍。這種「生成-測試-修改」的低效循環，嚴重製約了AI輔助開發的價值發揮。

Chrome DevTools MCP：AI的「眼睛」

Chrome DevTools MCP伺服器的出現，為AI助手裝上了一雙「眼睛」。透過Model Context Protocol，AI能夠：

🔍 即時程式碼驗證

使用者：修復這個按鈕樣式問題
AI：已生成修復程式碼，正在瀏覽器中驗證... ✅ 確認按鈕樣式已正確套用

📊 自動化效能分析

AI可以啟動Chrome、開啟網站、記錄效能追蹤，然後分析結果並提出最佳化建議：

使用者：這個頁面載入很慢，幫我最佳化
AI：檢測到LCP為3.2秒，主要問題是圖片未壓縮，建議使用WebP格式...

🐛 智能錯誤診斷

AI能夠檢查控制檯日誌、分析網路請求，快速定位問題根源：

使用者：登入功能不工作
AI：檢測到CORS錯誤，API請求被阻止，需要在伺服器端新增跨域標頭...

快速上手指南

1. 配置MCP用戶端

在支援MCP的AI用戶端中新增配置：

{
 "mcpServers": {
 "chrome-devtools": {
 "command": "npx",
 "args": ["chrome-devtools-mcp@latest"]
 }
 }
}

2. 支援的AI用戶端

Chrome DevTools MCP已獲得主流AI開發工具的官方支援：

Claude Desktop - Anthropic官方原生支援，配置最簡單
Cursor - 提供一鍵安裝按鈕，開發者體驗最佳
Cline - VS Code生態擴充功能，編輯器內整合
Copilot / VS Code - 微軟官方支援，與GitHub深度整合
Gemini CLI - Google官方工具，多語言支援

3. 首次測試

Chrome官方推薦的驗證提示詞：

測試提示: "Please check the LCP of web.dev."
中文版本: "請檢查web.dev的LCP效能"
預期執行流程:
1. AI自動啟動Chrome瀏覽器 🚀
2. 造訪https://web.dev 🌐
3. 開始效能追蹤記錄 📊
4. 分析LCP (Largest Contentful Paint) 指標 ⚡
5. 返回詳細效能報告和最佳化建議 📝

總結

Chrome DevTools MCP的推出，徹底解決了AI編程助手長期存在的「視覺盲區」問題。透過賦予AI「看見」程式碼執行效果的能力，它將Web開發的AI輔助體驗提升到了前所未有的高度。

核心價值總結：

效率革命：除錯時間從小時級別降至分鐘級別
品質提升：自動化效能分析和使用者體驗檢測
門檻降低：初學者也能完成複雜的Web開發任務
生態繁榮：開放標準促進整個AI開發工具生態發展

對於開發者而言，這不僅意味著更高的開發效率，更代表著一種全新的編程範式——AI不再只是程式碼生成器，而是真正能夠理解、驗證、最佳化Web應用的智能夥伴。

🚀 立即開始

30秒快速配置：

選擇支援MCP的AI用戶端（推薦Cursor或Claude Desktop）
新增配置："chrome-devtools": {"command": "npx", "args": ["chrome-devtools-mcp@latest"]}
測試提示：「檢查https://mcpcn.com的效能並提供最佳化建議」
觀察AI如何自動化完成整個除錯分析流程

Chrome DevTools MCP —— 讓AI編程從「盲目」走向「智能」，開啟Web開發新紀元。

模型上下文協議（MCP）：AI應用與外部數據集成的新標準

Sat, 01 Mar 2025 00:00:00 +0000

Claude 在 2024 年末推出的**模型上下文協議（Model Context Protocol，簡稱 MCP）**迅速獲得了開發者和社區的廣泛關注與認可。作為一名曾在過去一年中參與過多個小型 AI 項目開發的開發者，我深刻體會到將 AI 模型集成到現有系統或第三方服務中的種種困難。

MCP 的出現恰逢其時，它不僅解決了這些痛點，還帶來了一個開放、標準化的生態願景。下面，我將從開發者視角出發，結合 MCP 的工作原理和優勢，分析它為何能被廣泛接受。

一、AI 集成開發的痛點：為什麼需要 MCP？

在 AI 項目開發中，將模型與外部系統對接往往是一大挑戰。以我個人的經驗為例，無論是連接本地數據庫還是調用第三方 API，整個過程都充滿了複雜性和不確定性。市面上雖然有一些工具和框架試圖解決這個問題，但效果卻不盡如人意：

LangChain 和 LlamaIndex
這兩個開源項目主打"幾行代碼實現 AI 功能"的理念，在展示 Demo 時確實方便。然而，一旦業務需求變得複雜，它們的短板就暴露無遺：
- 代碼抽象過高：高層次封裝雖然降低了入門門檻，但在實際開發中，這種設計導致代碼難以調試和擴展，編程體驗極差。
- 生態混亂：項目過於追求商業化，忽視了社區生態的長期建設，文檔和更新常常跟不上實際需求。
Vercel AI SDK
相比之下，Vercel AI SDK 的代碼抽象做得更優雅，尤其在前端 UI 集成和部分 AI 功能封裝上表現不錯。但它的侷限也很明顯：
- 綁定 Next.js：與 Next.js 框架深度耦合，對其他框架或語言的支持不足，限制了適用範圍。

這些工具雖然各有亮點，但都無法提供一個統一的、靈活的解決方案。開發者仍然需要在不同項目中重複造輪子，浪費大量時間和精力。

二、MCP 的推出：恰逢其時，優勢突出

Claude 推出 MCP 的時機可謂恰到好處，它抓住了開發者對標準化和開放性的迫切需求。以下是 MCP 受到歡迎的幾個關鍵原因：

1. Claude 的品牌影響力

Claude Sonnet 3.5 作為一款性能卓越的語言模型，已在開發者群體中建立了良好口碑。這種信任為 MCP 的推廣奠定了基礎。開發者願意嘗試一個由 Anthropic（Claude 的開發公司）背書的協議，因為他們相信 Claude 團隊能持續輸出高質量的技術方案。

2. 開放標準的吸引力

MCP 是一個開放協議，不綁定任何特定模型或框架。這種開放性吸引了眾多公司和社區的參與。相比之下，傳統的 AI 集成方案往往受限於特定平臺，而 MCP 提供了一個通用的橋樑，讓服務商和開發者都能從中受益：

對服務商：可以基於 MCP 開放自己的 API 和功能，融入更大的生態。
對開發者：無需從頭構建集成邏輯，直接利用現成的 MCP 服務即可增強 AI Agent 的能力。

3. 解決重複造輪子的問題

MCP 的標準化設計讓開發者可以複用社區貢獻的資源。例如，一個支持 GitHub 操作的 MCP 服務器一旦開發完成，其他開發者就能直接調用，而無需重複實現。這種"一次開發，多次使用"的模式極大提升了效率。

三、MCP 如何工作？——從架構到實例

要理解 MCP 為何受歡迎，我們需要看看它的工作原理。MCP 的設計並不複雜，但卻非常實用。它通過一個清晰的架構，將 AI 模型與外部世界連接起來。

MCP 的核心架構

MCP 分為五個主要組件：

MCP Hosts：運行 AI 模型的應用程序，例如 Claude Desktop 或 Cursor。
MCP Clients：在 Hosts 內負責與服務器通信的模塊。
MCP Servers：核心部分，通過標準化協議為 Clients 提供工具、數據和上下文。
Local Data Sources：本地文件、數據庫等直接可訪問的數據。
Remote Services：外部 API 或服務，例如 GitHub 或 Slack。

其中，MCP Server 是整個協議的靈魂。它就像一個"中介"，告訴 AI Agent 當前有哪些可用服務和數據，AI Agent 再通過函數調用（Function Calling）執行具體任務。

從 AI Chat 到 AI Agent 的進化

MCP 的價值還體現在它推動了 AI 的自動化進程：

AI Chat：僅提供建議，用戶需手動操作（例如複製粘貼）。
AI Composer：能自動修改代碼，但仍需人工確認，且功能有限。
AI Agent：完全自動化，能獨立完成複雜任務，例如讀取 Figma 設計稿、生成代碼、調試並提交到 GitHub。

MCP Server 的作用是為 AI Agent 提供支持，讓它知道"能做什麼"和"怎麼做"。

一個簡單的例子：GitHub MCP Server

假設我們要讓 AI Agent 自動完成以下任務：搜索 GitHub 倉庫、查找 Issues、判斷是否為已知 Bug 並決定是否提交新 Issue。我們可以創建一個 GitHub MCP Server，提供以下能力：

search_repositories：搜索倉庫。
search_issues：搜索 Issues。
create_issue：創建新 Issue。

代碼實現如下（簡化版）：

const server = new Server({ name: "github-mcp-server" });

server.setRequestHandler("listTools", async () => ({
 tools: [
 { name: "search_repositories", description: "Search GitHub repositories" },
 { name: "search_issues", description: "Search issues in repositories" },
 { name: "create_issue", description: "Create a new issue" },
 ],
}));

server.setRequestHandler("callTool", async (request) => {
 switch (request.params.name) {
 case "search_repositories":
 return await searchRepositories(request.params.arguments.query);
 case "search_issues":
 return await searchIssues(request.params.arguments);
 case "create_issue":
 return await createIssue(request.params.arguments);
 }
});

async function searchRepositories(query) {
 const url = `https://api.github.com/search/repositories?q=${query}`;
 const response = await fetch(url);
 return await response.json();
}

這個服務器通過描述工具（description）和參數需求（inputSchema），讓 AI Agent 明白如何與 GitHub 交互。最終，Agent 可以根據任務需求自主調用這些功能。

四、MCP 的生態價值：更強大的 AI Agent

MCP 的真正潛力在於它能支持更復雜的 AI Agent。以一個實際場景為例：用戶輸入"查詢本地錯誤日誌，將相關 Issues 發送到 Slack"。AI Agent 需要：

調用 Local Log Server 讀取日誌。
調用 GitHub Server 搜索相關 Issues。
調用 Slack Server 發送消息。

MCP 的標準化協議讓這些服務器無縫協作，AI Agent 可以根據返回結果動態決定下一步操作。這種模塊化設計不僅提升了靈活性，也降低了開發成本。

五、總結：MCP 為何贏得青睞？

Claude 推出 MCP 之所以被廣泛接受，歸根結底在於它抓住了開發者的核心需求：

解決了痛點：簡化了 AI 與外部系統的集成過程。
開放生態：通過標準化吸引了社區和企業的參與。
實用性強：從簡單工具到複雜 Agent，MCP 提供了清晰的實現路徑。

對於開發者而言，MCP 不僅是一個技術協議，更是一個解放生產力的工具。未來，隨著更多 MCP 服務器的開發和生態的完善，它有望成為 AI 集成領域的行業標準。如果你也對 AI 開發感興趣，不妨試試 MCP，也許它會成為你下一個項目的秘密武器！

一文讀懂MCP協議：大模型AI-Agent的USB-C接口

Tue, 19 Mar 2024 15:20:00 +0800

MCP協議分層架構示意圖

在AI重構傳媒行業價值鏈的時代，內容生產、分發與用戶觸達的效能，正從單點效率升級為算法驅動的全局智能協同。然而，海量數據孤島、多平臺接口的煙囪式開發等瓶頸，仍在制約技術資源的AI化融合。

本文深入拆解MCP協議，從技術架構到行業場景化實踐，為您揭示如何用"一次連接，全局調用"的下一代接口標準，釋放傳媒數據資產的真正潛能——讓技術資源不再成為創意與效率的枷鎖，而是驅動增長的新引擎。

【本文由@bexzhang主筆， @osli修訂，來源：騰訊雲智慧傳媒】

一、MCP起源

背景與痛點

AI應用進入深水區後，模型與外部數據/工具的集成呈現"煙囪式開發"（每個模型需單獨對接不同數據源），導致開發成本高、安全性差、擴展困難。AI 模型和已有系統集成發展緩慢，一方面是企業級的數據很敏感，大多數企業都要很長的時間和流程來動；另一個方面是缺少一個開放的、通用的、有共識的協議標準。

市面上雖然有一些框架支持 Agent 開發，例如 LangChain Tools, LlamaIndex 或者是 Vercel AI SDK，需編寫大量定製代碼，難以規模化。

LangChain 和 LlamaIndex 整體發展混亂，代碼的抽象層次過高，在實際開發中，只要業務一旦開始複雜，糟糕的代碼設計帶來了非常糟糕的編程體驗。項目過於追求商業化了，忽略了整體生態的建設。

Vercel AI SDK 代碼抽象的比較好，但是也只是對於前端 UI 結合和部分 AI 功能的封裝還不錯，最大的問題是和 Nextjs 綁定太深了，對其它的框架和語言支持度不夠。

誕生與目標

提出者：Anthropic公司（Claude的開發者）於2024年11月底發佈並開源。https://www.anthropic.com/news/model-context-protocol

核心目標：建立類似USB-C的標準化協議，統一AI模型與外部資源的交互接口，實現"一次集成，處處運行"。解決當前 AI 模型因數據孤島限制而無法充分發揮潛力的難題，MCP 使得 AI 應用能夠安全地訪問和操作本地及遠程數據，為 AI 應用提供了連接萬物的接口。

MCP對比圖

技術演進時間線：

時間	階段	關鍵事件
2023年前	原始階段	每個AI需獨立開發Function Call接口
2023年	萌芽期	LangChain等框架嘗試通用化工具調用
2024年11月	協議誕生	Anthropic開源MCP 1.0版本
2025年Q1	生態爆發	GitHub出現200+第三方MCP服務器實現

二、MCP的概念和優勢

MCP定義

MCP是一種開放協議，通過標準化語言和接口，實現AI模型與外部數據源/工具的無縫交互，核心功能包括：

統一翻譯器：將不同數據源的API轉換為模型可理解的標準化請求。
安全連接層：支持本地與遠程資源訪問，數據無需上傳至雲端。

這個協議的發佈最好機會應該是屬於 OpenAI 的，如果 OpenAI 剛發佈 GPT 時就推動協議，相信大家都不會拒絕，但是 OpenAI 變成了 CloseAI，只發布了一個封閉的 GPTs，這種需要主導和共識的標準協議一般很難社區自發形成，一般由行業巨頭來主導。

通俗類比概念

“萬能遙控器"比喻

想象每個企業系統都是不同品牌的智能家電（電視、空調、音響），原本每個設備都需要專屬遙控器（定製接口）。MCP就像一個預置了所有家電協議的萬能遙控器：AI助手拿著這個遙控器，既能讓"電視"播放監控視頻（調用安防系統），也能讓"空調"調節數據溫度（調整服務器負載），還能讓"音響"播報業務報告（觸發語音合成）——所有操作都通過統一按鍵（標準化指令）完成，無需再為每個設備尋找專用遙控器。

“AI的USB-C接口"比喻

官方將MCP比作AI領域的USB-C接口。類比來看，不同的AI助手就像不同的電子設備，以前每個設備需要不同的數據線連不同的外設（比如老式手機數據線各不相同），而MCP提供了一個統一的細窄接口，讓AI能夠即插即用各種外設。例如，通過MCP，一個AI助手今天可以連U盤（數據庫），明天插打印機（郵件系統），後天接顯示器（報告生成）——接口都一樣，只是功能不同。就像USB-C讓我們少了無數轉換頭和線纜，MCP也讓AI集成少了無數專有API和腳本。對於終端用戶來說，這意味著AI助手將變得更加多才多藝且使用方便，因為背後複雜的連接都被這個看不見的"USB-C"標準屏蔽掉了。

AI的USB-C接口

MCP的優勢

MCP（Model Context Protocol）是專為大語言模型（LLMs）應用設計的上下文協議，針對LLM應用中常見的數據孤島與工具集成痛點，MCP提供以下關鍵能力：

生態-MCP 提供很多現成的插件， AI 可以直接使用。
統一性-不限制於特定的 AI 模型，任何支持 MCP 的模型都可以靈活切換。
數據安全-可以自行設計接口確定傳輸哪些數據。

MCP 與 Function Calling 的區別

MCP（Model Context Protocol），模型上下文協議	Function Calling，函數調用
這兩種技術都旨在增強 AI 模型與外部數據的交互能力，但 MCP 不止可以增強 AI 模型，還可以是其他的應用系統。
MCP的"原語”（Prompts/Resources/Tools）設計支持更復雜的交互流程，而傳統Function Calling僅為單向請求。
MCP並非"不限制於特定AI模型”，而是需模型支持MCP協議。Function Callling同樣以來模型的特性支持。

MCP與Function Calling對比

三、MCP的核心原理和技術架構

核心架構

MCP採用客戶端-服務器的分佈式架構，它將 LLM 與資源之間的通信劃分為三個主要部分：客戶端、服務器和資源。客戶端負責發送請求給 MCP 服務器，服務器則將這些請求轉發給相應的資源。這種分層的設計使得 MCP 協議能夠更好地控制訪問權限，確保只有經過授權的用戶才能訪問特定的資源。官方架構圖如下：

MCP核心架構

MCP Host（主機應用）：Hosts 是指 LLM 啟動連接的應用程序，像Cursor、Claude、Desktop、Cline 這樣的應用程序。
MCP Client（客戶端）：客戶端是用來在 Hosts 應用程序內維護與 Server 之間 1:1 連接。一個主機應用中可以運行多個MCP客戶端，從而同時連接多個不同的服務器。
MCP Server（服務器）：獨立運行的輕量程序，通過標準化的協議，為客戶端提供上下文、工具和提示，是MCP服務的核心。
本地數據源：本地的文件、數據庫和 API。
遠程服務：外部的文件、數據庫和 API。

這種架構下，AI主機通過MCP客戶端同時連接多個MCP服務器，每個服務器各司其職，提供對一種數據源或應用的標準化接入。這樣設計有幾個好處：一是模塊化，增加或移除某個數據源只需啟用或停用對應的服務器，不影響AI主體或其他部分；二是解耦，AI模型與具體數據源實現隔離開，通過協議交互，不直接依賴數據源的內部細節；三是雙向通信，不僅AI可以請求數據源，某些情況下數據源也能要求AI執行操作或生成內容，從而支持更復雜的交互流程。

工作流程

MCP工作流程

初始化連接：客戶端向服務器發送連接請求，建立通信通道。
發送請求：客戶端根據需求構建請求消息，併發送給服務器。
處理請求：服務器接收到請求後，解析請求內容，執行相應的操作（如查詢數據庫、讀取文件等）。
返回結果：服務器將處理結果封裝成響應消息，發送回客戶端。
斷開連接：任務完成後，客戶端可以主動關閉連接或等待服務器超時關閉。

通信方式

MCP定義了一套基於JSON-RPC 2.0的消息通信協議。核心特點如下：

傳輸靈活：原生支持兩種傳輸方式——進程管道的STDIO（本地場景）和SSE+HTTP POST（網絡通信），同時允許開發者自定義其他傳輸通道。
消息透明：採用純JSON格式封裝三種消息類型——請求（帶唯一ID）、響應（含結果/錯誤）和通知（無回覆）。每條消息包含方法名和參數，類似函數調用，直觀表達"執行操作/獲取數據"等行為。
開發友好：相比二進制協議（如gRPC），JSON消息可人工閱讀，配合結構化日誌更易調試。協議層自動處理請求響應匹配、錯誤傳遞和併發管理，開發者只需關注業務邏輯。

關鍵機制 – “Primitives”（原語）概念：MCP將AI與外部系統交互的內容抽象為幾類原語，以此規範客戶端和服務器各自能提供的功能。

MCP服務器可以提供三種原語：

Prompts（提示）：預先編寫的提示詞或模板，相當於一段指導性文字片段，可以插入到模型的輸入中去影響其行為。例如服務器可以提供一個"代碼審查提示模板"，供模型在閱讀代碼時使用。
Resources（資源）：結構化的數據或文檔內容，可供客戶端讀取並提供給模型作為上下文。例如從數據庫查詢到的一條記錄、用戶的筆記文檔內容等，都是資源類型。資源類似於"只讀文件"，模型可以請求某個資源，服務器會返回相應的數據內容。
Tools（工具）：可以被模型調用的可執行操作或函數。這是MCP最強大也最具互動性的部分，模型可以要求服務器執行某個工具函數來獲取信息或改變外部狀態，比如調用"發送郵件"工具發送一封郵件，調用"查詢天氣"工具獲取天氣數據等。由於工具調用可能帶來副作用和安全風險，MCP規定模型調用工具必須經由用戶批准後才執行。換言之，工具就像模型可用的"按鍵"，但每次按鍵需要真人確認，避免模型濫用外部操作權限。

MCP客戶端提供兩種原語能力用於輔助服務器完成複雜任務：

Roots（根）：這是一種由客戶端提供的文件系統入口或句柄。服務器可以通過Root來訪問客戶端這側的本地文件或目錄內容。例如客戶端可以授權服務器讀取某個文件夾（作為Root），那麼服務器就能代表模型瀏覽那個文件夾下的文件內容（通常仍以資源形式提供給模型）。Roots機制確保服務器只能訪問經授權的本地數據範圍，增強安全性。
Sampling（採樣）：這一機制允許服務器向客戶端發起請求，要求客戶端這側的LLM模型生成一段文本（即一次補全/推理）。簡單說，服務器也可以"反過來"調用模型，讓模型基於一些額外提示執行推理。Sampling可以用於構建多輪交互的智能Agent：服務器在執行某工具過程中，發現需要模型進一步推理決定下一步時，就可以用Sampling請求模型產出結果，再繼續後續操作。不過Anthropic也強調應謹慎使用這一機制，始終保持人類在環監督，以避免AI代理失控循環調用模型。Sampling機制並非所有MCP服務器均支持，需依賴客戶端實現。

通過上述原語分類，MCP清晰地定義了模型與外部交互的意圖類型。例如，讓模型獲取一段參考資料應該作為Resource提供，而不是混同於調用Tool；又如要求模型執行某操作就用Tool明確表示。這樣的設計使AI系統的上下文管理更結構化：模型知道某段信息是隻讀資料還是可執行操作，用戶也能對不同類型請求進行針對性地審批或監控。這比起簡單地給模型一個隱式"工具插件"要透明得多。Anthropic的開發者指出，他們最初也考慮過是否把所有交互都當作"工具調用"統一處理，但最終認為Prompt和Resource這兩類原語有其獨特意義，能表達不同用途的功能，因此保留了多元的原語概念。

四、MCP Server分類及應用

MCP Server是MCP服務的核心，主要從官方、第三方以及社區MCP Server三個角度對關注度較高的應用進行細分。

1.官方MCP Server

（由 Model Context Protocol 核心團隊維護，具備標準化協議實現和最佳實踐）

核心基礎設施

modelcontextprotocol/server-filesystem（文件系統）：提供標準化文件訪問接口，支持細粒度權限控制，基礎能力標杆實現。https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

拓展工具

modelcontextprotocol/Google Drive（雲端文件）：與 Google Drive 集成，允許列出、讀取和搜索文件。https://github.com/modelcontextprotocol/servers/tree/main/src/gdrive

AI增強工具

modelcontextprotocol/aws-kb-retrieval-server（向量數據庫）：官方向量檢索方案，支持高維數據存儲與相似性搜索。https://github.com/modelcontextprotocol/servers/tree/main/src/aws-kb-retrieval-server

2.第三方MCP Server

（由專業廠商/團隊維護，具備行業領域深度集成能力）

數據庫服務

Tinybird MCP Server（實時數據分析）：針對時序數據優化，提供低延遲 SQL 查詢接口。https://github.com/tinybirdco/mcp-tinybir

雲服務

Qdrant MCP Server（向量搜索雲服務）：企業級向量檢索雲服務，支持混合搜索和分佈式部署。https://github.com/qdrant/mcp-server-qdrant/

AI服務

LlamaCloud Server（大模型託管平臺）：提供多模態模型調用接口，支持模型微調和推理監控。https://github.com/run-llama/mcp-server-llamacloud

開發工具服務

Neo4j（圖數據庫）：圖數據庫服務，支持Cypher查詢與知識圖譜構建。https://github.com/neo4j-contrib/mcp-neo4j/

拓展工具服務

Firecrawl （網頁爬取）：支持抓取、爬取、搜索、提取、深入研究和批量抓取。https://github.com/mendableai/firecrawl-mcp-server?tab=readme-ov-file#firecrawl-mcp-server

3.社區MCP Server

（由開發者社區貢獻，覆蓋長尾需求和實驗性場景）

本地工具集成

punkpeye/mcp-obsidian（知識管理工具）：支持雙向同步 Obsidian 筆記庫，Markdown 內容解析優化。https://github.com/punkpeye/mcp-obsidian

自動化工具

appcypher/mcp-playwright（瀏覽器自動化）：基於 Playwright 的網頁操作自動化，支持動態 JS 執行。https://github.com/appcypher/awesome-mcp-servers#browser-automation

垂直領域工具

r-huijts/mcp-aoai-web（藝術數據訪問）：可通過自然語言交互訪問荷蘭國立博物館的藏品，提供藝術品元數據檢索。https://github.com/r-huijts/rijksmuseum-mcp

開發者工具

sammcj/mcp-package-version（開發依賴管理）：實時查詢 npm/pypi 包版本，防止幻覺版本建議。https://github.com/sammcj/mcp-package-version

隱私增強工具

hannesrudolph/mcp-ragdocs（本地文檔檢索）：基於本地向量庫的隱私安全文檔檢索方案。https://github.com/hannesrudolph/mcp-ragdocs

4.分類對比

維度	官方 Servers	第三方 Servers	社區 Servers
維護週期	長期維護，版本迭代規律	依賴廠商支持週期	依賴個人開發者活躍度
協議兼容性	100% 符合最新 MCP 規範	通常支持核心規範	可能存在實驗性擴展
安全審計	經過官方安全認證	部分廠商提供商業級審計	無強制審計機制
部署複雜度	提供標準化安裝包和文檔	需要配置廠商專用憑證	常需手動調試依賴項
典型場景	基礎能力/關鍵業務場景	行業垂直領域深度需求	個性化/實驗性需求

補充說明：遠程 MCP 連接的支持

官方文檔中關於傳輸方式的描述可能會讓部分開發者誤解，認為 Remote MCP Connections（遠程 MCP 連接）已經實現。實際上，當前的客戶端和服務端都是在本地運行的。（當前如果需要連接遠程服務器，需要在客戶端-服務端連接後，由本地服務端再次向遠程服務器發起連接）

這一點在官方的 2025 年路線圖中有所提及https://modelcontextprotocol.io/development/roadmap ：

實現 Remote MCP Connections是當前MCP項目組的最高優先級，允許客戶端通過互聯網安全地連接到 MCP 服務端。關鍵舉措包括：

認證與授權 (Authentication & Authorization)：增加標準化的認證能力，特別是專注於 OAuth 2.0 支持。
服務發現 (Service Discovery)：定義客戶端如何發現並連接到遠程 MCP 服務器。
無狀態操作 (Stateless Operations)：探討 MCP 是否可以支持無服務器環境（serverless environments），在這種環境中，操作需要儘可能無狀態。

參考文章：

[1]https://www.anthropic.com/news/model-context-protocol
[2]https://modelcontextprotocol.io/development/roadmap
[3]https://github.com/modelcontextprotocol
[4]https://mcp.so/servers
[5]https://github.com/punkpeye/awesome-mcp-servers
[6]https://github.com/appcypher/awesome-mcp-servers
[7]https://github.com/modelcontextprotocol/python-sdk
[8]https://github.com/punkpeye/awesome-mcp-servers?tab=readme-ov-file#frameworks
[9]‍https://mp.weixin.qq.com/s/Toj2TudFNXx6_Z11zSRb2g