嗨，我是 Lena。第一次試著向別人解釋 MCP 時，我隱約覺得哪裡不太對。
我一直說「它把 AI 接到工具上」——技術上沒錯，但沒說清楚底層到底發生了什麼。對方點點頭，接著問：「所以就像外掛？」我頓了一下。因為也不完全是那樣。
那種落差——介於「我知道它能用」和「我懂它怎麼運作」之間——正是我想在這裡多待一會兒的原因。不是要寫成正式的技術拆解，而是慢慢走過我觀察到的、MCP Server 實際上如何行為。
MCP 想解決的問題
為什麼過去每接一次模型與工具都要客製
在 MCP 出現之前，把語言模型接到外部工具，往往意味著每次都要寫一套客製整合。GitHub 有自己的格式。 資料庫有各自的。每個 API 都像獨立專案。
難點不在於單一整合有多難，而是累積起來——彼此無法互通，模型也沒有標準方式能問「在這裡我能做什麼？」每條連線都是手縫的。
Model Context Protocol 是 Anthropic 對此的回應。2024 年 11 月開源後，它引入了一種共用語言——標準化的 client-server 協定，讓任何 AI 應用都能接到任何工具提供者，而不必再拉一堆客製線路。到 2025 年中，OpenAI 與 Google DeepMind 也已採用。後來它併入 Agentic AI Foundation，成為 Linux Foundation 底下的一個專案。
那一步有點意義。它不再只是某家公司的標準，而開始變得更像共用基礎建設。我還不確定實務上會因此改變什麼，但我一直注意到這件事。
MCP 架構：三個動起來的環節
當有人問 MCP Server 怎麼運作，我覺得最清楚的切入點是三段式結構。每一塊職責不同，混淆多半來自把它們糊成一團。
MCP Host（AI 應用程式）
Host 就是你實際在用的應用——Cursor、Claude Desktop、裝了 AI 擴充的 VS Code。使用者看到、互動的就是它。
Host 是安全中介。 它管理模型的 context window、決定哪些工具可用，並控制什麼內容會回傳給 LLM。它自己不執行工具呼叫——只負責治理存取。多數開發者不會寫 host 邏輯，除非在打造自訂的 Agent 平台；但理解它很重要，因為是 host 決定模型能碰、不能碰什麼。
MCP Client（內建在 host 裡）
Client 由 host 建立。它坐在 host 與各個 MCP Server 之間，管理連線。通常 一個 MCP Server 對應一個 MCP client——各自維持專屬 session。
Client 負責能力協商、往返轉送訊息，並抽象掉傳輸細節。Host 不必知道某個 server 是跑在 stdio 還是 HTTP 上。那是 client 的事。
MCP Server（工具提供者）
Server 才是真正承載能力的地方。它暴露 tools、resources、prompts——依設計提供什麼就是什麼。GitHub MCP Server 暴露儲存庫操作；Postgres server 暴露查詢函式。每個 server 通常專注在一個整合領域。
我看得更細之後有點意外：server 就只是程式。它可以跟 host 跑在同一台機器本機，也可以遠端在網路上的某處。協定不變——變的只有傳輸方式。
工具呼叫實際上怎麼發生
這段我以前在腦中一直稍微搞錯，直到一步一步畫出來才對上。
步驟一：Server 宣告可用工具
Client 第一次連上 server 時會握手。Client 送出 initialize 請求。Server 回傳協定版本與能力清單——提供哪些工具、名稱、輸入 schema、描述。這叫做 capability negotiation。
接著 client 把這些工具定義嵌進模型的 system prompt。LLM 就是這樣知道有什麼可用。不是魔法——只是結構化的脈絡。
步驟二：模型決定使用工具
模型處理請求並判斷適合呼叫工具時，會輸出結構化呼叫：工具名稱與要傳入的引數。模型不會直接呼叫工具。 它輸出結構化指示，由 host 解讀。
步驟三：Client 把呼叫送給 server
Client 接過那個結構化呼叫，透過 JSON-RPC 2.0 以 tools/call 請求轉給正確的 server。這是線路格式——帶方法名、參數，以及用來對應的唯一 ID。
步驟四：Server 執行並回傳結果
Server 跑實際函式——資料庫查詢、API 呼叫、讀檔，依設計而定。它回傳結構化回應。若出錯，會回傳型別化的錯誤，而不是丟生例外。寫得好的 server 會回傳對模型真的有用的錯誤訊息——這對後續恢復很重要。
步驟五：模型納入結果
結果經由 client、host 流回模型的脈絡。模型把它當對話的一部分讀取，再從那裡繼續。
……好，我好像看懂它在幹嘛了。每一步刻意分開。模型從不直接碰工具。中間永遠隔一層。
傳輸層：Server 與 Client 如何溝通
stdio（本機）對上 HTTP／SSE（遠端）
Stdio transport 使用標準輸入與輸出串流。當 host 把本機 MCP Server 當子程序啟動——例如執行 npx my-mcp-server——client 與 server 透過讀寫那些串流溝通。不經網路。沒有額外延遲。快，因為只是同一台機器上的行程對行程通訊。
Streamable HTTP transport（遠端 server 目前的標準，見 2025 年 3 月協定更新）用 HTTP POST 送 client 到 server 的訊息，並可選用 Server-Sent Events 串流回應。遠端 server 就是這樣用——架在 Cloudflare、Vercel 這類平台上，同時服務許多 client。
還有一種較舊的 HTTP+SSE 格式（2024 年 11 月規格），需要兩個端點。較新的 Streamable HTTP 規格把它收斂成單一端點。若你在讀較舊文件，值得知道——模式已經變過。
對延遲與安全代表什麼
本機 stdio server 較快，攻擊面也較小。只有 host 能與它通訊。遠端 server 會帶來網路延遲，也需要驗證。2025 年 7 月的研究發現，近兩千個暴露在網路上的 MCP Server 完全沒有驗證——任何人都能存取它們的工具列表。2025 年 6 月的規格更新把部分問題納入處理，將 MCP Server 歸類為 OAuth Resource Server，但實作仍不一致。
那個細節我一直記著。協定能定義安全模式，但無法強制執行。官方 MCP 安全文件 涵蓋建議做法——在部署任何會處理敏感資料的東西之前，值得一讀。
多數開發者會漏掉的那一層
成功的工具呼叫之後發生什麼
這段曾讓我困惑一陣：一次成功的工具呼叫本身不會持久保存任何東西。
結果會回到該次 session 的模型脈絡裡。模型用它、產生回應、繼續往下。但「曾經呼叫過工具」這件事——模型走過的路徑、選的輸入、拿到的結果——只存在對話視窗裡。Session 結束就沒了。
MCP Server 不會累積知識。不會因為過去的 session 變得更會回應。每次新連線都從同一個初始狀態開始——握手、能力清單、乾淨白板。
為什麼連線 ≠ 能力持續性
我說「連線不是能力持續性」指的就是這個。
接上 MCP Server 只代表模型能用到那項工具。不代表模型記得以前怎麼用、什麼有效、什麼失敗。Server 在每個 session 暴露的仍是同一套能力，與先前發生過什麼無關。
我一直在想這件事。不完全是缺陷——比較像設計邊界。協定處理通訊與執行。執行輸出之後要存起來、從中學習、帶到下一步——那是完全不同的一層。
……這裡可能還有更多可說的。我會繼續想。
FAQ
- MCP Server 到底是什麼？
MCP Server 是一個輕量程式，透過 Model Context Protocol 向 AI Agent 暴露 tools、resources 與 prompts。它把來自語言模型的結構化請求轉成實際操作——資料庫查詢、API 呼叫、讀檔——並以標準化格式回傳結果。它可以跟 AI 應用跑在同一台機器本機，也可以透過 HTTP 遠端運作。
- MCP 使用哪些傳輸協定？
MCP 支援兩種傳輸機制。Stdio 用標準輸入／輸出串流做本機、同機通訊——快、沒有網路開銷。Streamable HTTP（遠端 server 目前的標準）使用 HTTP POST，並可選用 Server-Sent Events 做串流。無論哪種傳輸，底層訊息格式都是 JSON-RPC 2.0。
- MCP Server 能呼叫另一個 MCP Server 嗎？
協定允許這樣做。一個 MCP client 可以同時維持與多個 server 的連線——一個給資料庫、一個給檔案、一個給外部 API，同一個 session 裡都行。較少見、在目前實作中也較少清楚定義的，是 server 再當成 client 去連另一個 server。那種模式存在，但會增加複雜度，安全邊界也更難想清楚。
協定仍在成形。從 2024 年 11 月版、2025 年 3 月更新，到現在實際在用的內容，規格意義已經變過幾次。再過一兩個版本架構會長什麼樣——我誠實說不確定。但我會繼續多了解它。
