總字數：約25000字 | 預計閱讀時長：70分鐘​

一、MCP協議概述​

1.1 什麼是MCP協議​

MCP（Model Context Protocol，模型上下文協議） 是由Anthropic於2024年11月推出的開放標準，定義了AI模型與外部工具、資料來源之間的統一通訊協議。​

如果用一句話概括：MCP是AI世界的USB-C介面。​

過去，每個AI應用都需要為每個外部工具編寫定製程式碼。接入GitHub？寫一套。連線資料庫？再寫一套。切換大模型？全部重來。MCP的出現，讓這種碎片化整合成為歷史——工具開發者只需實現一次MCP伺服器，AI應用只需實現一次MCP客戶端，任意組合即可無縫對接。​

MCP的核心價值：​

​



| 維度 | 說明 |
| --- | --- |
| 標準化 | 統一的JSON-RPC 2.0協議，消除碎片化整合 |
| 雙向通訊 | AI不僅能呼叫工具，還能接收工具的實時反饋 |
| 生態開放 | 任何人都可以開發和釋出MCP伺服器 |
| 動態發現 | AI在執行時自動發現可用工具，無需硬編碼 |



​

截至2026年6月，MCP生態已呈爆發式增長：月度SDK下載量突破9700萬次，GitHub上超過13,000個MCP伺服器實現，Claude Desktop、ChatGPT、Cursor、Windsurf、Visual Studio等主流AI工具均已原生支援MCP。​

參考連結：[MCP (Model Context Protocol): A Developer's Guide for 2026](https://www.marsdevs.com/blog/model-context-protocol-mcp)​

1.2 MCP誕生背景：從M×N到M+N​

在MCP出現之前，AI應用與外部工具的整合面臨一個經典難題——M×N整合地獄。​

假設一個企業有：​

•

M個AI應用：客服機器人、程式碼助手、資料分析Agent、安全運營平臺​

•

N個外部工具：GitHub、Slack、PostgreSQL、Jira、內部CRM、SIEM系統​

在沒有統一協議的情況下，每個AI應用都需要為每個工具編寫獨立的整合程式碼。這意味著M×N個介面卡。每引入一個新工具，所有AI應用都要修改；每切換一個大模型，所有整合邏輯都要重寫。​

MCP將M×N簡化為M+N：​

​



| 對比維度 | 傳統整合（M×N） | MCP標準化（M+N） |
| --- | --- | --- |
| 整合數量 | M × N 個介面卡 | M + N 個介面卡 |
| 新增工具 | 所有AI應用都要改 | 只需開發MCP伺服器 |
| 切換模型 | 所有整合重寫 | MCP客戶端不變 |
| 維護成本 | 指數級增長 | 線性增長 |
| 工具發現 | 靜態硬編碼 | 執行時動態發現 |



​

以10個AI應用、20個工具為例：傳統方式需要200個介面卡，MCP方式只需要30個。這就是標準化的力量。​

一個直觀的比喻：​

想象你去國外旅行。在MCP之前，每個國家的插座標準不同——你得帶一堆轉換頭。MCP就是那個萬能轉換器：不管你去哪個國家（AI應用），用什麼電器（外部工具），一個轉換器搞定。​

1.3 MCP發展歷程與現狀​

MCP的發展速度遠超大多數技術標準。從內部實驗到行業標準，僅用了不到兩年時間。​

​



| 時間 | 里程碑 |
| --- | --- |
| 2024年7月 | Anthropic工程師David Soria Parra和Justin Spahr-Summers在內部構建MCP原型 |
| 2024年11月 | Anthropic正式開源MCP協議，釋出首個規範版本 |
| 2025年初 | Claude Desktop率先原生支援MCP，社群開始大量開發MCP伺服器 |
| 2025年4月 | Google釋出A2A協議，與MCP形成互補的Agent生態 |
| 2025年6月 | SSE傳輸被棄用，Streamable HTTP成為標準遠端傳輸方式 |
| 2025年11月 | MCP一週年，規範更新至2025-11-25版本 |
| 2025年12月 | MCP捐贈給Linux基金會旗下的Agentic AI Foundation（AAIF） |
| 2026年3月 | 2026路線圖釋出，明確四大優先方向 |
| 2026年5月 | OpenAI、Google、Microsoft、AWS等巨頭全面採納MCP |
| 2026年7月 | 2026-07-28規範候選版本釋出，MCP進入無狀態協議時代 |



​

關鍵資料（截至2026年6月）：​

​



| 指標 | 數值 |
| --- | --- |
| 月度SDK下載量 | 9,700萬+ |
| 公開MCP伺服器 | 13,000+ |
| 官方SDK支援語言 | Python、TypeScript、Java、Kotlin、C# |
| 支援的AI平臺 | Claude、ChatGPT、Cursor、Windsurf、VS Code、Visual Studio等 |
| 治理機構 | Linux基金會 → Agentic AI Foundation (AAIF) |



​

參考連結：[The 2026 MCP Roadmap](http://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/)​

二、MCP核心架構​

2.1 Client-Host-Server三層架構​

MCP採用Client-Host-Server三層架構，這是理解整個協議的基礎。​

​

Code block​

Plain Text

┌─────────────────────────────────────────────────────────────┐​

│ Host（宿主應用） │​

​

三層架構的核心邏輯：​

1）Host是使用者直接互動的應用程式，負責管理整個會話生命週期​

2）Client嵌入在Host內部，為每個MCP伺服器維護一個獨立的1:1連線​

3）Server暴露具體的能力（工具、資源、提示詞），供AI呼叫​

為什麼是三層而不是兩層？ 因為Host需要做安全隔離。Client作為中間層，確保AI模型不能繞過Host的許可權控制直接訪問伺服器。這種設計讓Host能夠實施統一的安全策略：哪些工具可用、哪些資料可見、哪些操作需要使用者確認。​

2.2 三大核心角色詳解​

1）Host（宿主）​

Host是使用者直接面對的應用程式。它的職責包括：​

​



| 職責 | 說明 |
| --- | --- |
| 使用者互動 | 提供對話介面，展示AI回覆和工具執行結果 |
| 會話管理 | 控制對話的開始、進行和結束 |
| 許可權控制 | 決定哪些工具可以被AI呼叫，哪些需要使用者確認 |
| 安全邊界 | 隔離不同MCP伺服器之間的訪問 |



​

常見的Host應用：​

​



| Host應用 | 型別 | 典型用途 |
| --- | --- | --- |
| Claude Desktop | 桌面應用 | 通用AI助手 |
| Cursor | IDE | 智慧程式設計助手 |
| Windsurf | IDE | 智慧程式設計助手 |
| VS Code + Copilot | IDE | 智慧程式設計助手 |
| Visual Studio 2022+ | IDE | 智慧程式設計助手 |
| ChatGPT | Web應用 | 通用AI助手 |
| 自研Agent應用 | 定製應用 | 企業級智慧體 |



​

2）Client（客戶端）​

Client是Host內部的協議處理元件。每個Client例項與一個MCP伺服器建立一對一的連線。​

Client的核心職責：​

•

協議握手：與伺服器交換能力列表，協商支援的功能​

•

訊息路由：將Host的請求轉換為MCP協議訊息傳送給伺服器​

•

響應處理：接收伺服器的響應，解析後返回給Host​

•

連線維護：管理連線的生命週期，處理重連和錯誤恢復​

一個Host可以同時執行多個Client例項，連線多個MCP伺服器。例如，Cursor可以同時連線GitHub MCP伺服器、PostgreSQL MCP伺服器和Slack MCP伺服器。​

3）Server（伺服器）​

Server是MCP協議的核心——它暴露具體的能力供AI使用。​

Server可以提供三類能力：​

​



| 能力型別 | 說明 | 示例 |
| --- | --- | --- |
| Tools（工具） | AI可呼叫的可執行函式 | 建立PR、執行SQL、傳送郵件 |
| Resources（資源） | AI可讀取的靜態資料 | 檔案內容、資料庫Schema、配置 |
| Prompts（提示詞） | 預定義的指令模板 | 程式碼審查模板、資料分析模板 |



​

Server的設計哲學：Server對自己的資源擁有完全控制權。它決定暴露哪些工具、需要什麼認證、返回什麼資料。AI模型無法繞過Server的許可權控制。​

2.3 通訊流程與握手機制​

MCP使用JSON-RPC 2.0作為訊息格式。所有通訊都遵循請求-響應模式。​

完整的通訊流程：​

​

Code block​

Plain Text

​

握手訊息示例：​

​

Code block​

JSON

​

能力協商是握手的關鍵環節。Client和Server透過交換capabilities欄位，確認雙方支援哪些功能。如果Client不支援Server需要的某個特性，Server可以優雅地降級處理。​

三、MCP核心原語​

MCP定義了四大核心原語（Primitives），它們是協議的基本構建塊。​

3.1 Tools（工具）​

Tools是MCP最核心的原語。 它代表AI可以呼叫的可執行函式。​

把Tools想象成AI的"手"——沒有Tools，AI只能"說"；有了Tools，AI能"做"。​

Tools的核心特徵：​

​



| 特徵 | 說明 |
| --- | --- |
| 由模型控制 | AI根據上下文自主決定何時呼叫哪個工具 |
| 有明確輸入 | 透過JSON Schema定義引數型別和約束 |
| 有明確輸出 | 返回結構化的執行結果 |
| 可被發現 | AI透過tools/list動態獲取可用工具列表 |



​

工具定義示例：​

​

Code block​

JSON

{​

"name": "query\_database",​

"description": "執行SQL查詢並返回結果",​

"inputSchema": {​

"type": "object",​

"properties": {​

"sql": {​

"type": "string",​

"description": "要執行的SQL查詢語句"​

},​

"database": {​

"type": "string",​

​

Tools的設計最佳實踐：​

1）命名清晰：工具名應直觀表達功能，如create\_pull\_request而非do\_thing​

2）描述詳盡：description欄位是AI決定是否呼叫此工具的關鍵依據​

3）引數最小化：只暴露必要的引數，降低AI的決策複雜度​

4）返回結構化：返回JSON而非純文字，便於AI解析​

3.2 Resources（資源）​

Resources代表AI可以讀取的上下文資料。 它們是隻讀的，不執行任何操作。​

把Resources想象成AI的"眼睛"——它們提供資訊，幫助AI理解當前環境。​

Resources與Tools的核心區別：​

​



| 對比維度 | Resources | Tools |
| --- | --- | --- |
| 操作型別 | 只讀 | 讀寫 |
| 控制方 | 由應用程式控制 | 由AI模型控制 |
| 典型用途 | 提供上下文 | 執行操作 |
| URI模式 | 自定義URI scheme | 函式呼叫 |



​

Resources的兩種型別：​

1）靜態資源：透過固定URI直接訪問​

​

Code block​

JSON

{​

"uri": "config://database/schema",​

"name": "資料庫Schema",​

"description": "當前資料庫的表結構定義",​

"mimeType": "application/json"​

}​

​

2）動態資源模板：透過URI模板動態生成​

​

Code block​

JSON

{​

"uriTemplate": "file:///{path}",​

"name": "檔案內容",​

"description": "讀取指定路徑的檔案內容",​

"mimeType": "text/plain"​

}​

​

Resources的典型應用場景：​

•

提供專案配置檔案內容​

•

暴露資料庫Schema供AI理解表結構​

•

提供API文件供AI參考​

•

共享日誌檔案供AI分析​

3.3 Prompts（提示詞）​

Prompts是預定義的指令模板，幫助使用者快速啟動特定的AI工作流。​

把Prompts想象成"快捷指令"——使用者不需要從零描述需求，選擇一個模板即可開始。​

Prompts的定義示例：​

​

Code block​

JSON

{​

"name": "code\_review",​

"description": "對指定檔案進行程式碼審查",​

"arguments": \[​

{​

"name": "file\_path",​

"description": "要審查的檔案路徑",​

"required": true​

},​

{​

"name": "focus",​

"description": "審查重點：security/performance/style",​

"required": false​

}​

\]​

}​

​

當使用者選擇這個Prompt時，MCP伺服器會返回一組結構化的訊息，指導AI按照特定的方式執行任務。​

Prompts與Tools、Resources的協作：​

​

Code block​

Plain Text

使用者選擇Prompt → AI獲得結構化指令​

→ 指令引用Resources獲取上下文​

​

3.4 Sampling（取樣）​

Sampling是MCP最具特色的原語。 它允許MCP伺服器反向請求AI模型進行推理。​

這是MCP與傳統API協議的根本區別：不僅AI可以呼叫工具，工具也可以呼叫AI。​

Sampling的工作流程：​

​

Code block​

Plain Text

1\. 使用者請求AI執行某個任務​

2\. AI呼叫MCP伺服器的Tool​

3\. Tool在執行過程中需要AI的幫助（如分析文字、生成內容）​

4\. Tool透過Sampling請求Host呼叫AI模型​

5\. Host將請求轉發給AI模型​

6\. AI模型返回推理結果​

7\. Tool繼續執行，最終返回結果給使用者​

​

Sampling的安全設計：​

Sampling是一個強大的功能，但也是一個高風險功能。MCP規範要求：​

•

必須由使用者確認：Host不能靜默地允許伺服器呼叫AI模型​

•

Human-in-the-loop：使用者必須看到Sampling請求的內容並批准​

•

內容稽核：Host可以對Sampling的輸入輸出進行過濾​

注意：在2026年7月釋出的規範候選版本中，Sampling已被標記為棄用（deprecated）。新專案建議使用Tasks擴充套件來處理需要AI參與的複雜工作流。​

四、MCP傳輸方式​

MCP協議的傳輸層負責在Client和Server之間傳遞JSON-RPC訊息。目前支援兩種主要傳輸方式。​

4.1 Stdio本地傳輸​

Stdio（Standard Input/Output） 是MCP最簡單的傳輸方式。它透過程序的標準輸入/輸出流進行通訊。​

工作原理：​

​

Code block​

Plain Text

Host程序 ──spawn──> MCP Server程序​

──stdin──> Server接收訊息​

<─stdout── Server傳送響應​

​

適用場景：​

​



| 場景 | 說明 |
| --- | --- |
| 本地開發 | 開發者在本機執行MCP伺服器進行除錯 |
| CLI工具 | 命令列工具整合AI能力 |
| 桌面應用 | Claude Desktop等桌面應用連線本地工具 |



​

Stdio的優勢與侷限：​

​



| 優勢 | 侷限 |
| --- | --- |
| 零網路配置 | 僅限本地通訊 |
| 無需TLS/認證 | 不支援遠端部署 |
| 啟動簡單 | 每個連線一個程序 |
| 延遲極低 | 不支援水平擴充套件 |



​

Claude Desktop配置示例：​

​

Code block​

JSON

{​

"mcpServers": {​

"filesystem": {​

"command": "npx",​

"args": \["-y", "@modelcontextprotocol/server-filesystem", "/home/user/documents"\]​

},​

"github": {​

"command": "npx",​

"args": \["-y", "@modelcontextprotocol/server-github"\],​

"env": {​

"GITHUB\_PERSONAL\_ACCESS\_TOKEN": "ghp\_xxxxxxxxxxxx"​

}​

}​

}​

}​

​

4.2 Streamable HTTP遠端傳輸​

Streamable HTTP 是MCP的標準遠端傳輸方式，適用於生產環境部署。​

工作原理：​

​

Code block​

Plain Text

Client ──HTTP POST──> MCP Server（單一端點）​

​

核心特性：​

​



| 特性 | 說明 |
| --- | --- |
| 單一端點 | 所有訊息透過一個HTTP端點收發 |
| 雙向通訊 | 支援Server主動推送訊息給Client |
| 認證支援 | 原生支援OAuth 2.1認證 |
| 可擴充套件 | 支援水平擴充套件和負載均衡 |



​

與Stdio的對比：​

​



| 對比維度 | Stdio | Streamable HTTP |
| --- | --- | --- |
| 通訊方式 | 程序間管道 | HTTP + SSE |
| 部署位置 | 僅本地 | 本地/遠端/雲端 |
| 認證 | 無 | OAuth 2.1 |
| 多使用者 | 單使用者 | 多使用者併發 |
| 生產適用 | 開發除錯 | 生產環境 |



​

4.3 2026規範更新：無狀態協議​

2026年7月28日，MCP規範釋出了重大更新——MCP進入無狀態協議時代。​

這是MCP自誕生以來最大的一次協議重構。​

為什麼需要無狀態？​

在之前的版本中，MCP伺服器需要維護會話狀態（透過Mcp-Session-Id）。這帶來了嚴重的問題：​

​



| 問題 | 影響 |
| --- | --- |
| 粘性會話 | 負載均衡器必須將同一會話的請求路由到同一伺服器 |
| 水平擴充套件困難 | 需要共享會話儲存（Redis等），增加架構複雜度 |
| 重啟不友好 | 伺服器重啟導致所有活躍會話中斷 |
| 故障恢復複雜 | 需要會話遷移機制 |



​

無狀態協議的核心變化：​

1）移除握手階段：不再需要initialize/initialized交換​

2）移除會話ID：每個請求獨立攜帶所有必要資訊​

3）可路由、可快取：請求可以透過Mcp-Method頭部路由，tools/list響應可快取​

4）向後相容：舊版本客戶端仍然可以透過相容模式連線​

實際影響：​

​

Code block​

Plain Text

之前的部署：​

客戶端 → 粘性會話 → 固定伺服器例項 → 需要Redis儲存會話​

​

之後的部署：​

客戶端 → 普通輪詢負載均衡 → 任意伺服器例項 → 無狀態處理​

​

擴充套件框架（Extensions）：​

2026規範引入了擴充套件框架，允許協議透過擴充套件演進而不破壞核心：​

​



| 擴充套件 | 說明 |
| --- | --- |
| MCP Apps | 伺服器渲染的使用者介面，支援在Host中嵌入互動式元件 |
| Tasks | 長時間執行任務的生命週期管理，支援非同步執行和進度通知 |
| 認證增強 | 與OAuth和OpenID Connect更緊密對齊 |



​

參考連結：[The 2026-07-28 MCP Specification Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/)​

五、MCP開發實踐​

本章將帶你從零開始構建MCP伺服器和客戶端。我們使用Python和TypeScript兩種語言，提供可直接執行的完整程式碼。​

5.1 開發環境搭建​

1）Python環境​

​

Code block​

Bash

\# 建立專案目錄​

mkdir mcp-server-demo && cd mcp-server-demo​

​

\# 建立虛擬環境​

python -m venv venv​

​

​

2）TypeScript環境​

​

Code block​

Bash

\# 建立專案目錄​

mkdir mcp-server-ts && cd mcp-server-ts​

​

\# 初始化專案​

npm init -y​

​

\# 安裝MCP SDK​

npm install @modelcontextprotocol/sdk​

​

\# 安裝TypeScript依賴​

npm install -D typescript @types/node ts-node​

​

\# 安裝其他依賴​

npm install zod​

​

tsconfig.json配置：​

​

Code block​

JSON

​

5.2 使用Python構建MCP伺服器​

MCP Python SDK提供了FastMCP高層API，極大簡化了開發流程。​

1）最簡MCP伺服器​

​

Code block​

Python

\# server\_simple.py​

​

執行方式：​

​

Code block​

Bash

python server\_simple.py​

​

就是這麼簡單。FastMCP會自動處理：​

•

JSON Schema生成（從函式簽名和docstring推斷）​

•

引數驗證​

•

錯誤處理​

•

協議握手​

2）完整示例：安全日誌分析MCP伺服器​

以下是一個更實用的示例——一個用於安全日誌分析的MCP伺服器：​

​

Code block​

Python

\# security\_log\_server.py​

\# pip install mcp httpx​

​

import re​

import json​

from collections import Counter​

from datetime import datetime​

from pathlib import Path​

from mcp.server.fastmcp import FastMCP​

​

mcp = FastMCP("security-log-analyzer")​

​

\# ==================== Tools ====================​

​

@mcp.tool()​

def analyze\_log\_file(file\_path: str, keyword: str = "ERROR") -> dict:​

"""​

分析日誌檔案，統計指定關鍵字的出現次數和分佈。​

​

Args:​

file\_path: 日誌檔案路徑​

keyword: 要搜尋的關鍵字（預設：ERROR）​

"""​

path = Path(file\_path)​

if not path.exists():​

return {"error": f"檔案不存在：{file\_path}"}​

​

lines = path.read\_text(encoding="utf-8", errors="ignore").splitlines()​

​

{log\_snippet}​

​

Code block​

Plain Text

​

3）使用DeepSeek構建AI增強的MCP伺服器​

以下示例展示如何將大模型能力整合到MCP伺服器中：​

​

Code block​

Python

​

5.3 使用TypeScript構建MCP伺服器​

1）基礎MCP伺服器​

​

Code block​

TypeScript

// src/server.ts​

import { Server } from "@modelcontextprotocol/sdk/server/index.js";​

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";​

import {​

CallToolRequestSchema,​

ListToolsRequestSchema,​

} from "@modelcontextprotocol/sdk/types.js";​

​

const server = new Server(​

{ name: "my-ts-server", version: "1.0.0" },​

{ capabilities: { tools: {} } }​

);​

​

// 定義工具列表​

const tools = \[​

{​

name: "calculate\_hash",​

description: "計算字串的SHA-256雜湊值",​

inputSchema: {​

type: "object" as const,​

properties: {​

input: { type: "string" as const, description: "要計算雜湊的字串" }​

},​

required: \["input"\]​

}​

}​

\];​

​

// 處理工具列表請求​

server.setRequestHandler(ListToolsRequestSchema, async () => ({​

tools​

}));​

​

2）編譯與執行​

​

Code block​

Bash

​

package.json指令碼配置：​

​

Code block​

JSON

{​

"scripts": {​

"build": "tsc",​

"start": "node dist/server.js",​

"dev": "ts-node src/server.ts"​

}​

}​

​

5.4 MCP客戶端整合​

1）Python MCP客戶端​

​

Code block​

Python

\# mcp\_client\_demo.py​

\# pip install mcp​

​

import asyncio​

from mcp.client.session import ClientSession​

from mcp.client.stdio import StdioServerParameters, stdio\_client​

​

async def main():​

​

2）透過配置檔案整合到Host應用​

大多數Host應用（如Claude Desktop、Cursor）透過配置檔案連線MCP伺服器。​

Claude Desktop配置（claude\_desktop\_config.json）：​

​

Code block​

JSON

​

Cursor配置（.cursor/mcp.json）：​

​

Code block​

JSON

​

VS Code配置（.vscode/mcp.json）：​

​

Code block​

JSON

​

六、MCP生態系統​

6.1 官方SDK與工具​

MCP生態的繁榮離不開官方提供的多語言SDK和豐富的工具鏈。​

​



| SDK/工具 | 語言 | 說明 |
| --- | --- | --- |
| @modelcontextprotocol/sdk | TypeScript | 官方TypeScript SDK，最成熟 |
| mcp | Python | 官方Python SDK，支援FastMCP高層API |
| mcp-kotlin | Kotlin | 官方Kotlin SDK，適用於JVM生態 |
| mcp-dotnet | C# | 官方.NET SDK |
| mcp-java-sdk | Java | 官方Java SDK |



​

開發工具：​

​



| 工具 | 說明 |
| --- | --- |
| MCP Inspector | 官方除錯工具，視覺化測試MCP伺服器 |
| MCP CLI | 命令列工具，快速建立和測試MCP伺服器 |
| create-mcp | 專案腳手架，一鍵生成MCP伺服器模板 |



​

MCP Inspector使用：​

​

Code block​

Bash

\# 啟動Inspector進行除錯​

npx @modelcontextprotocol/inspector python server.py​

​

Inspector提供Web介面，可以：​

•

檢視伺服器暴露的工具、資源、提示詞​

•

手動呼叫工具並檢視返回結果​

•

檢視JSON-RPC訊息的完整內容​

•

除錯連線和認證問題​

6.2 主流AI平臺支援情況​

截至2026年6月，幾乎所有主流AI平臺都已原生支援MCP。​

​



| 平臺 | 支援狀態 | 傳輸方式 | 說明 |
| --- | --- | --- | --- |
| Claude Desktop | 完整支援 | Stdio/HTTP | Anthropic官方產品，MCP首發支援 |
| ChatGPT | 完整支援 | HTTP | OpenAI於2025年底接入 |
| Cursor | 完整支援 | Stdio/HTTP | 程式設計IDE，深度整合MCP |
| Windsurf | 完整支援 | Stdio/HTTP | 程式設計IDE |
| VS Code + Copilot | 完整支援 | Stdio/HTTP | 微軟官方支援 |
| Visual Studio 2022+ | 完整支援 | Stdio/HTTP | 微軟官方支援 |
| Zed | 支援 | Stdio | 高效能編輯器 |
| Cline | 支援 | Stdio/HTTP | VS Code擴充套件 |



​

2025-2026年採納時間線：​

​

Code block​

Plain Text

2024.11 ── Anthropic開源MCP​

2025.01 ── Claude Desktop原生支援​

2025.06 ── Cursor、Windsurf支援​

2025.09 ── VS Code Copilot支援​

2025.12 ── OpenAI ChatGPT支援，MCP捐贈給Linux基金會​

​

6.3 MCP伺服器登錄檔與發現​

官方MCP伺服器登錄檔（registry.modelcontextprotocol.io）是發現MCP伺服器的中心化平臺。​

截至2026年6月，登錄檔中已有數千個MCP伺服器，涵蓋以下類別：​

​



| 類別 | 代表伺服器 | 說明 |
| --- | --- | --- |
| 程式碼管理 | GitHub、GitLab、Linear | 倉庫、Issue、PR管理 |
| 通訊協作 | Slack、Discord、Gmail | 訊息傳送、頻道管理 |
| 資料庫 | PostgreSQL、SQLite、MongoDB | 資料庫查詢和管理 |
| 雲服務 | AWS、Cloudflare、Azure | 雲資源管理 |
| Web搜尋 | Brave Search、Fetch | 網頁搜尋和內容獲取 |
| 瀏覽器自動化 | Puppeteer、Browserbase | 瀏覽器操作 |
| 檔案系統 | Filesystem、Google Drive | 檔案讀寫和管理 |
| CRM/銷售 | HubSpot、Salesforce | 客戶關係管理 |
| 支付 | Stripe | 支付處理 |
| 監控 | Sentry、Raygun | 錯誤監控和崩潰報告 |
| 設計 | Figma | 設計工具整合 |
| AI工具 | EverArt、Sequential Thinking | AI能力擴充套件 |



​

如何釋出自己的MCP伺服器：​

1）在[官方登錄檔](https://registry.modelcontextprotocol.io/)提交伺服器資訊​

2）伺服器需遵循MCP規範，實現標準的JSON-RPC介面​

3）提供清晰的工具描述和引數Schema​

4）確保安全性和認證機制​

伺服器發現機制：​

MCP 2026規範引入了MCP Server Cards——一種標準化的後設資料格式，透過.well-known端點暴露伺服器資訊。這意味著登錄檔和客戶端可以在不建立連線的情況下發現伺服器的能力。​

七、MCP應用場景​

7.1 IDE智慧程式設計助手​

MCP在IDE中的應用是最成熟的場景。透過MCP，程式設計助手能夠：​

​



| 能力 | MCP伺服器 | 實際效果 |
| --- | --- | --- |
| 程式碼管理 | GitHub/GitLab MCP | AI直接建立分支、提交程式碼、建立PR |
| 專案管理 | Linear MCP | AI讀取Issue、更新任務狀態 |
| 程式碼搜尋 | 程式碼庫MCP | AI搜尋和理解專案程式碼 |
| 資料庫操作 | PostgreSQL MCP | AI查詢資料庫結構和資料 |
| 錯誤監控 | Sentry MCP | AI分析線上錯誤和崩潰 |



​

典型工作流：​

​

Code block​

Plain Text

使用者："幫我修復GitHub Issue #123描述的bug"​

​

AI Agent透過MCP：​

1\. 呼叫GitHub MCP → 獲取Issue詳情​

2\. 呼叫程式碼庫MCP → 搜尋相關程式碼檔案​

3\. 分析bug原因，編寫修復程式碼​

4\. 呼叫GitHub MCP → 建立修復分支和PR​

5\. 呼叫Linear MCP → 更新Issue狀態為"已修復"​

​

行業案例：​

2026年5月，微軟宣佈Visual Studio 2022正式支援MCP，開發者可以透過.mcp.json配置檔案連線任意MCP伺服器。GitHub Copilot Agent模式深度整合MCP，支援在編碼過程中自動呼叫外部工具完成任務。​

參考連結：[Use MCP servers in Visual Studio](https://learn.microsoft.com/en-us/VisualStudio/ide/mcp-servers)​

7.2 企業知識庫整合​

MCP是連線AI與企業知識庫的理想橋樑。​

架構模式：​

​

Code block​

Plain Text

使用者提問 → AI Agent → MCP Client → 知識庫MCP Server​

├── 文件檢索（RAG）​

├── 資料庫查詢​

└── API呼叫​

​

知識庫MCP伺服器實現思路：​

​

Code block​

Python

\# knowledge\_base\_server.py​

\# pip install mcp httpx chromadb​

​

from mcp.server.fastmcp import FastMCP​

import chromadb​

​

mcp = FastMCP("knowledge-base")​

​

\# 初始化向量資料庫​

client = chromadb.PersistentClient(path="./kb\_data")​

collection = client.get\_or\_create\_collection("documents")​

​

@mcp.tool()​

def search\_documents(query: str, top\_k: int = 5) -> dict:​

"""​

在知識庫中搜尋與查詢相關的文件。​

​

Args:​

query: 搜尋查詢​

top\_k: 返回結果數量（預設：5）​

"""​

results = collection.query(​

query\_texts=\[query\],​

n\_results=top\_k​

)​

​

documents = \[\]​

for i, doc in enumerate(results\["documents"\]\[0\]):​

documents.append({​

"content": doc,​

"score": results\["distances"\]\[0\]\[i\] if results\["distances"\] else None,​

​

7.3 自動化工作流編排​

MCP可以將多個工具串聯成自動化工作流。​

示例：自動化安全報告生成​

​

Code block​

Python

\# workflow\_server.py​

\# pip install mcp httpx​

​

from mcp.server.fastmcp import FastMCP​

import httpx​

import json​

​

mcp = FastMCP("workflow-orchestrator")​

​

@mcp.tool()​

async def generate\_daily\_security\_report(date: str = "today") -> str:​

"""​

自動生成每日安全報告。​

​

Args:​

date: 報告日期（格式：YYYY-MM-DD，預設：today）​

"""​

steps = \[\]​

​

\# 步驟1：收集告警資料​

alerts = await collect\_alerts(date)​

steps.append(f"收集到 {len(alerts)} 條告警")​

​

\# 步驟2：分析威脅趨勢​

analysis = await analyze\_threats(alerts)​

steps.append(f"識別出 {len(analysis\['threats'\])} 個威脅型別")​

​

\# 步驟3：生成報告​

report = await format\_report(date, alerts, analysis)​

steps.append("報告生成完成")​

​

7.4 安全運營場景​

MCP在安全運營（SecOps）領域具有巨大潛力。​

MCP賦能安全運營的典型場景：​

​



| 場景 | MCP伺服器 | AI Agent能力 |
| --- | --- | --- |
| 告警分析 | SIEM MCP | AI自動分析告警，判斷真偽，降低告警疲勞 |
| 漏洞掃描 | 漏洞掃描器MCP | AI排程掃描任務，分析結果，提供修復建議 |
| 威脅情報 | TI平臺MCP | AI查詢IOC，關聯分析，生成情報報告 |
| 應急響應 | SOAR MCP | AI自動執行響應劇本，隔離受感染主機 |
| 配置審計 | 合規檢查MCP | AI檢查安全配置，識別不合規項 |



​

安全運營MCP伺服器示例：​

​

Code block​

Python

\# siem\_mcp\_server.py​

\# pip install mcp httpx​

​

from mcp.server.fastmcp import FastMCP​

import httpx​

import json​

​

mcp = FastMCP("siem-connector")​

​

SIEM\_API\_URL = "https://siem.internal/api"​

SIEM\_API\_KEY = "your\_siem\_api\_key"​

​

@mcp.tool()​

async def query\_siem\_alerts(​

time\_range: str = "24h",​

severity: str = "high",​

limit: int = 100​

) -> dict:​

​

安全運營中的MCP架構：​

​

Code block​

Plain Text

​

這種架構讓安全分析師只需與AI Agent對話，Agent自動協調多個MCP伺服器完成複雜的安全運營任務。​

八、MCP發展趨勢​

8.1 2026規範路線圖​

2026年3月，MCP核心維護團隊釋出了更新後的路線圖，明確了四大優先方向。​

​



| 優先方向 | 核心目標 | 關鍵交付物 |
| --- | --- | --- |
| 傳輸演進與可擴充套件性 | 解決有狀態會話與負載均衡的衝突 | 無狀態協議、Server Cards、會話恢復機制 |
| Agent通訊 | 完善非同步任務管理 | Tasks擴充套件、重試語義、過期策略 |
| 治理成熟 | 建立開放標準的決策機制 | 貢獻者梯度、工作組委派模型 |
| 企業就緒 | 滿足生產環境合規需求 | 審計追蹤、SSO整合、閘道器模式 |



​

2026規範候選版本的關鍵特性：​

1）無狀態協議核心：移除握手和會話ID，支援普通HTTP基礎設施水平擴充套件​

2）擴充套件框架（Extensions）：MCP Apps（伺服器渲染UI）、Tasks（長時間任務）​

3）認證增強：與OAuth和OpenID Connect更緊密對齊​

4）正式棄用策略：Roots、Sampling、Logging被標記為棄用​

5）完整JSON Schema 2020-12支援：工具引數定義更加靈活​

參考連結：[The 2026-07-28 MCP Specification Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/)​

8.2 與A2A協議協同​

2025年4月，Google釋出了A2A（Agent-to-Agent）協議，與MCP形成互補關係。​

MCP與A2A的定位對比：​

​



| 對比維度 | MCP | A2A |
| --- | --- | --- |
| 通訊方向 | 垂直（Agent → 工具） | 水平（Agent ↔ Agent） |
| 核心功能 | 連線AI與外部工具/資料 | 連線不同AI Agent |
| 發現機制 | 工具列表（tools/list） | Agent Card（/.well-known/agent.json） |
| 通訊協議 | JSON-RPC over Stdio/HTTP | HTTP + JSON + SSE |
| 狀態管理 | 無狀態工具呼叫 | 有狀態任務生命週期 |
| 成熟度 | 生產就緒，18個月+生產使用 | 早期採納階段 |



​

MCP + A2A的協同架構：​

​

Code block​

Plain Text

┌─────────────────────────────────────────────┐​

│ A2A協議層（Agent間通訊） │​

│ Agent A ←──── A2A ────→ Agent B │​

│ │ │ │​

│ ├── MCP Client ├── MCP Client │​

│ │ → 工具伺服器1 │ → 工具伺服器3│​

│ │ → 工具伺服器2 │ → 工具伺服器4│​

└─────────────────────────────────────────────┘​

​

協同場景示例：​

想象一個企業安全運營場景：​

•

Agent A（威脅檢測Agent）透過MCP連線SIEM系統，監控告警​

•

Agent B（應急響應Agent）透過MCP連線防火牆和EDR系統​

•

當Agent A發現高危告警時，透過A2A協議通知Agent B​

•

Agent B自動執行應急響應，透過MCP呼叫防火牆封禁惡意IP​

MCP解決的是"Agent如何使用工具"，A2A解決的是"Agent如何與Agent協作"。兩者結合，才能構建真正強大的多Agent系統。​

參考連結：[MCP vs A2A: When to Use Each Protocol (2026)](https://apigene.ai/blog/mcp-vs-a2a-when-to-use-each-protocol)​

8.3 企業級部署挑戰​

MCP從實驗走向生產，企業面臨一系列現實挑戰。​

1）安全挑戰​

​



| 風險 | 說明 | 應對措施 |
| --- | --- | --- |
| 認證缺失 | 許多MCP伺服器缺乏認證機制 | 強制OAuth 2.1，實施最小許可權 |
| 工具投毒 | 惡意工具描述可能誘導AI執行危險操作 | 工具稽核、程式碼審查、來源驗證 |
| 資料洩露 | 工具響應可能包含敏感資料 | 輸出過濾、資料脫敏、訪問控制 |
| 供應鏈攻擊 | MCP伺服器依賴可能被投毒 | 依賴掃描、鎖定版本、安全審計 |



​

關於MCP安全的詳細分析，請參閱《5.4-MCP安全》章節。​

2）運維挑戰​

​



| 挑戰 | 說明 | 解決方案 |
| --- | --- | --- |
| 服務發現 | 如何管理和發現大量MCP伺服器 | MCP Registry + Server Cards |
| 版本管理 | 工具Schema變更可能破壞現有Agent | 語義化版本控制、向後相容策略 |
| 監控告警 | 如何監控MCP伺服器的健康狀態 | 標準化指標、健康檢查端點 |
| 成本控制 | 大量工具呼叫可能產生高額API費用 | 呼叫配額、快取策略、按需載入 |



​

3）治理挑戰​

2025年12月，MCP被捐贈給Linux基金會旗下的\*\*Agentic AI Foundation（AAIF）\*\*進行中立治理。這意味著：​

•

開放治理：不再由單一公司控制協議發展方向​

•

多方參與：Anthropic、OpenAI、Google、Microsoft、AWS等共同參與​

•

標準化推進：透過工作組（Working Groups）和規範增強提案（SEPs）驅動演進​

•

企業信任：中立治理降低了企業採納的顧慮​

企業採納建議：​

1）從核心場景開始：先在IDE智慧助手、知識庫查詢等低風險場景試點​

2）建立安全基線：強制認證、最小許可權、輸入驗證、輸出過濾​

3）逐步擴充套件：驗證價值後，再擴充套件到生產環境的自動化工作流​

4）關注規範演進：2026規範的無狀態特性和擴充套件框架將大幅降低部署門檻​

5）參與社群：透過AAIF參與MCP標準的制定，確保企業需求被納入​

本章小結​

本章全面介紹了MCP（模型上下文協議）——這個正在重塑AI與外部世界互動方式的開放標準。​

核心要點回顧：​

1）MCP的本質：將AI與工具的整合從M×N簡化為M+N的標準化協議，被譽為"AI世界的USB-C"​

2）架構設計：Client-Host-Server三層架構，透過能力協商和安全隔離保障系統的靈活性與安全性​

3）四大原語：Tools（執行操作）、Resources（提供上下文）、Prompts（結構化指令）、Sampling（反向呼叫AI），構成了MCP的能力基座​

4）傳輸演進：從Stdio本地傳輸到Streamable HTTP遠端傳輸，再到2026年的無狀態協議，MCP持續適應生產環境需求​

5）開發現狀：Python和TypeScript雙語言SDK成熟，FastMCP高層API讓伺服器開發極為簡潔​

6）生態繁榮：9700萬+月度SDK下載，13000+公開伺服器，所有主流AI平臺已全面支援​

7）應用場景：從IDE程式設計助手到企業知識庫，從自動化工作流到安全運營，MCP正在滲透到AI應用的每一個角落​

8）未來方向：無狀態協議、MCP Apps、Tasks擴充套件、與A2A協議協同，MCP正在從"工具呼叫協議"進化為"Agent基礎設施"​

MCP不僅僅是一個技術協議——它代表了AI從"聊天時代"邁向"行動時代"的關鍵基礎設施。當AI能夠安全、標準化地連線到現實世界的工具和資料時，真正的智慧體時代才算到來。​

關於MCP協議的安全風險分析與防護實踐，請參閱《5.4-MCP安全》章節。​

​

​

作者：無涯​