# 伺服器寫好了卻沒人會連？客戶端才是另一半工程 伺服器那一半做完了，工具也通過檢查器了，然後呢？如果沒有客戶端把它連起來、把能力交給應用程式，那台伺服器就… · @swordBluesy · TwKit

@swordBluesy

# 伺服器寫好了卻沒人會連？客戶端才是另一半工程 伺服器那一半做完了，工具也通過檢查器了，然後呢？如果沒有客戶端把它連起來、把能力交給應用程式，那台伺服器就只是一段躺在硬碟裡的程式碼。很多人學 MCP 只學一半，伺服器寫得頭頭是道，客戶端卻從來沒動手寫過，這一半不補起來，整個應用永遠拼不完整。 ## 先講清楚：真實專案裡通常只做一邊 課裡先打了一個預防針：在大多數真實專案裡，你通常只會實作 MCP 客戶端或 MCP 伺服器其中之一，不會兩邊都做。這個專案兩邊都做，只是為了讓你看清它們是怎麼協同工作的。不要學完就以為每個專案都要兩邊全寫，那是教學安排，不是工程常態。 ## 客戶端由哪兩件東西組成 第一件是你自己寫的 MCP Client 類，它讓會話更好用。第二件是 SDK 裡的 Client Session，也就是真正到伺服器的連接。會話需要妥善的資源管理，用完要清理連接，所以才用自己的類把清理自動處理掉，而不是每次都手動收尾。 在應用裡，客戶端在兩個關鍵點上起作用：用客戶端取可用工具清單發給 Claude，以及 Claude 要求時用客戶端執行工具。整個應用能不能跑，就看這兩個點通不通。 ## 兩個核心函式，程式碼就這麼短 取工具的函式： async def list_tools(self) -> list[types.Tool]: result = await self.session().list_tools() return http://result.tools 執行工具的函式： async def call_tool( self, tool_name: str, tool_input: dict ) -> types.CallToolResult | None: return await self.session().call_tool(tool_name, tool_input) 取工具就是訪問會話、調內置的 list_tools、把結果裡的工具返回；執行工具就是把 Claude 給的工具名與參數送到伺服器、把結果返回。就這麼簡單，複雜的不是函式本身，是前面的會話與清理要包對。 ## 測試照課裡的兩條命令走 先測客戶端本身，跑： uv run mcp_client.py 它會連上你的 MCP 伺服器，印出可用工具，你應該能看到工具定義，包括描述與輸入綱要。再測完整流程，跑： uv run http://main.py 然後試著問：「What is the contents of the report.pdf document?」背後走的是：應用用客戶端取工具，工具發給 Claude，Claude 決定用 read_doc_contents，應用用客戶端執行它，結果回到 Claude，Claude 再回答你。客戶端就是應用邏輯與 MCP 伺服器功能之間的橋。 ## S1哥觀點 客戶端這課的重點不是程式碼有多長，而是你終於把 MCP 的另一半補上了：伺服器提供能力，客戶端使用能力，兩邊合起來才是一個能跑的應用。只會寫伺服器的人，做出來的是零件；兩邊都會的人，做出來的才是產品。 爭論點就在這裡：很多人覺得客戶端只是幾行樣板程式碼，照抄就好。但真相是，會話、清理、取工具、執行工具這幾件事，有一件沒包對，應用在真實環境裡遲早會在某個深夜出問題。先把客戶端當成正式工程來寫，再談應用做得多漂亮，這個順序不能倒。 原文連結：https://anthropic.skilljar.com/introduction-to-model-context-protocol/296696 原文：Anthropic Academy（由 S1哥 編譯）

曝光 379 · 评论 5 · 点赞 5 · 书签 1