MCP協議6600萬次下載背后：Anthropic埋了3年的US

6600萬次npm下載，27000個依賴包——這是MCP TypeScript SDK截至2026年4月的成績單。但數字背后有個更狠的事實：AI模型干了這么多年，居然到今天才用上"通用接口"。

以前每接一個新數據源，你都要手寫一套橋接代碼。Anthropic 2023年憋出來的MCP（Model Context Protocol，模型上下文協議），本質上就是給AI造了個USB口：插上去就能用，拔下來就能換。現在谷歌、OpenAI都進場了，這協議從"Anthropic私貨"變成了行業基建。

本文基于官方TypeScript SDK文檔，把架構、工具、資源、提示詞這些核心模塊拆清楚。不聊概念，只聊你怎么用。

兩層架構：McpServer和Server到底啥區別

SDK藏了個容易踩的坑——它有兩套API。

Server是底層原語：手動處理JSON-RPC消息、協議版本協商、能力聲明。適合你要完全控制通信流程的場景，比如自定義傳輸層或者調試協議細節。

McpServer是高層封裝：工具注冊、資源暴露、提示詞管理，全部鏈式API搞定。99%的生產代碼應該用這個。

打個比方：Server像TCP套接字，McpServer像Express框架。除非你在寫框架本身，否則別碰底層。

初始化McpServer只需要三行：

const server = new McpServer({ name: "weather-server", version: "1.0.0" });

server.tool("getForecast", { city: z.string() }, async ({ city }) => { ... });

const transport = new StdioServerTransport(); await server.connect(transport);

工具定義用Zod做運行時校驗，類型推導直接打通。你寫一遍schema，TypeScript和運行時都認。

工具、資源、提示詞：SDK的三板斧

MCP協議把AI能調用的東西分成三類，SDK的API設計完全對應這個分類。

工具（Tools）：讓AI執行動作。查天氣、調API、寫文件，都算。關鍵特性是Zod校驗 + 結構化錯誤。你的工具拋錯時，可以返回isError: true和具體message，AI會據此決定重試還是換策略。

工具還能加annotations（注解），告訴AI這個操作是"只讀"還是"破壞性"的。比如刪除操作標記destructiveHint: true，模型會自動多問用戶一句確認。

資源（Resources）：給AI提供上下文。分靜態URI和動態模板兩種。靜態的像file:///config.json，動態的像file:///logs/{date}.txt。模板用URI Template語法，參數自動提取。

提示詞（Prompts）：預置的可復用指令模板?？梢詭?，比如/summarize?style=brief?？蛻舳税l現這些提示詞后，用戶一鍵就能觸發復雜工作流。

這三類在SDK里是平行API：server.tool()、server.resource()、server.prompt()。設計意圖很明顯——協議層面一視同仁，但你的業務邏輯自己拆清楚。

Sampling：服務器主動調用LLM的野路子

大部分MCP交互是"客戶端請求→服務器響應"的單向模式。但有個高級功能打破了這規矩：sampling（采樣）。

場景是這樣的：你的MCP服務器收到一個復雜查詢，需要LLM幫忙拆解或者生成中間內容。這時候服務器可以反向調用客戶端提供的LLM能力，拿到結果再繼續執行。

流程變成：用戶提問 → 服務器發現需要推理 → 發sampling請求給客戶端 → 客戶端調LLM → 結果返回服務器 → 服務器完成最終響應。

這個設計很微妙。它讓MCP服務器不再是" dumb工具"，而是能自主決策、自主調用AI的agent節點。但代價是復雜度：你需要處理異步采樣請求、上下文窗口管理、可能的循環調用。

SDK的sampling API長這樣：

const result = await server.requestSampling({ messages: [...], maxTokens: 500 });

客戶端必須顯式聲明supportsSampling: true才會響應。這是個安全閘門——服務器不能隨便燒用戶的token。

傳輸層選型：stdio還是HTTP

SDK內置兩種傳輸實現，選錯會直接影響部署架構。

StdioTransport：標準輸入輸出，進程間通信。適合本地CLI工具、桌面應用內嵌、或者任何"服務器和客戶端跑在同一臺機器"的場景。簡單、無網絡依賴、調試直接打console。

StreamableHTTP：HTTP長連接，支持SSE（Server-Sent Events）流式響應。適合遠程部署、多客戶端并發、或者需要穿越防火墻的場景。2025年3月協議更新后，這個傳輸支持真正的無狀態擴展——每個請求獨立鑒權，服務端可以隨便水平擴容。

有個細節容易忽略：HTTP傳輸的path配置。默認是/mcp，但你可以改。如果你把多個MCP服務器掛在同一個域名下，用path區分比開多個端口干凈。

生產環境建議直接上StreamableHTTP + 反向代理。stdio看著省事，但跨機器部署時你會重新寫一遍網絡層。

自動補全與結構化日志：被低估的生產力

SDK有兩塊功能文檔沒強調，但實際開發很香。

Completions（自動補全）：工具參數、資源URI、提示詞參數，都可以注冊補全回調。用戶在客戶端輸入時，實時拿到建議列表。實現方式類似LSP的completionProvider：

server.setCompletionHandler("resource", "file", async (uri) => { return { values: await listFiles(uri) }; });

Structured Logging：SDK內置JSON格式日志，級別從debug到error。關鍵是可以附加任意metadata，比如請求ID、用戶ID、工具名。接入ELK或者Datadog時，過濾和聚合直接可用。

這兩塊屬于"用上就回不去"的基礎設施。補全降低用戶犯錯率，結構化日志降低你排查問題的血壓。

Agentic AI Foundation現在接手維護MCP， Anthropic、Google、OpenAI都在委員會里。但協議的真正考驗才剛開始：當各家的大模型都想擴展這個協議時，標準會不會膨脹到失控？

SDK的下一個大版本據說要支持工具鏈（chained tools）和更細粒度的權限模型。但現在的問題是：你的MCP服務器，準備好從"demo玩具"變成"生產負載"了嗎？