我一定要自己寫 Server 嗎,有沒有現成的可以用?
很多常見服務(雲端硬碟、專案管理、通訊工具)已經有官方或社群做好的 MCP Server,能直接接,不必自己寫。你該自己寫的情況是:要連的是『你公司內部、外面沒有現成方案』的系統,例如自家資料庫、內部 API、私有工具。
判斷原則:標準化的外部服務,優先找現成的,省時又經過驗證;只有當你的需求夠特殊、現成的接不上時,才值得自己動手寫。別為了一個現成方案能解決的問題重造輪子。
stdio 和 SSE/HTTP 兩種傳輸,我該選哪個?
簡單分:Server 跟 Claude 跑在同一台機器(例如你本機的桌面 App),用 stdio;Server 在別的地方、要透過網路連(例如部署在雲端、給團隊共用),用 SSE/HTTP。
判斷重點是『誰要用、從哪裡連』。自己一個人本機開發測試,stdio 最簡單,不用處理網路和認證。要給整個團隊用、或讓遠端的 Claude 連得到,就得走 HTTP,這時也別忘了加上認證,因為一旦上網,任何能連到的人都可能呼叫你的 Server,權限和身分驗證就更重要。
權限控管,除了把工具設成唯讀,還有哪些該注意?
唯讀是第一道,但不夠。還有幾層該想:一是『資料範圍』,就算唯讀,也該限制能查到的範圍——例如只給查某個部門的資料,而不是整個資料庫全開。二是『輸入驗證』,別假設 Claude 帶來的參數一定乾淨,該像對待任何外部輸入一樣檢查、過濾。
三是『稽核紀錄』,把誰、什麼時候、呼叫了哪個工具、查了什麼都記下來,萬一出事才查得到。把這幾層疊起來,核心觀念都一樣:你的 Server 要假設請求可能是錯的或有惡意的,而不是預設它都善良。
進階:工具說明該怎麼寫,Claude 才會正確呼叫?
這是決定 Server 好不好用的隱形關鍵,常被低估。Claude 要靠你寫的工具說明來判斷『何時用、帶什麼參數』。說明寫得含糊,它就猜;猜錯了,就出現『工具被呼叫但參數怪怪的』那類問題。
寫好工具說明有三個要點:一是把工具的用途和適用情境講清楚,讓 Claude 知道什麼時候該選它;二是每個參數都註明是什麼、什麼格式、必填還是選填,別讓它瞎填;三是如果參數有限制(例如日期格式、數值範圍),在說明裡直接寫明。
一個實用心法:把工具說明當成『寫給一個看不到你內部系統的人』的 API 文件。他只能靠你的文字理解這個工具,你寫得多清楚,Claude 就用得多準。
當你想讓 Claude 不只是聊天,而是真的查到你公司內部的資料——例如客戶資料庫、內部 API、私有文件——你需要的就是一個 MCP Server。它是 Claude 和你內部工具之間的翻譯官兼守門員:Claude 用標準的方式說『我想用某個工具』,你的 Server 負責檢查權限、實際去查、再把結果整理回去。
這篇給已經會寫程式的人,目標是讓你搞清楚一個自製 MCP Server 的骨架、權限該擺哪、以及出問題時怎麼除錯。不會綁定特定語言的逐行程式碼,而是講清楚每一塊負責什麼。
整條鏈是這樣:Claude → 你的 MCP Server → 你的內部系統,再原路返回。Claude 本身不直接碰你的資料庫,它只會對你的 Server 說『請用 query_customer 這個工具,參數是這個』。你的 Server 收到後,先驗證這個請求該不該被允許,通過了才去查內部系統,最後把資料整理成 Claude 看得懂的格式回傳。
這個設計的好處是:你的機敏憑證(資料庫密碼、API 金鑰)只存在你的 Server 裡,不會交給 Claude。Claude 永遠只透過你定義好的工具來存取,碰不到底層。
第一,工具定義:你告訴 Claude 有哪些工具可用、每個工具要什麼參數、會回傳什麼。這部分等於是你開給 Claude 的『菜單』,沒寫進菜單的它點不到。第二,實際執行的邏輯:當 Claude 點了某個工具,你的程式真正去查資料庫或呼叫 API 的那段。第三,傳輸方式:本機用的 stdio,或遠端用的 SSE/HTTP,決定 Claude 怎麼跟你的 Server 通訊。
這是最容易出包的地方。絕對不要用『跟 Claude 說請不要刪除資料』這種方式來控管權限——那只是請求,不是限制。真正的權限檢查必須寫在你 Server 的程式裡:在實際執行任何動作前,由你的程式碼判斷『這個操作允不允許』。例如把工具設成唯讀、限制可查的資料範圍、危險操作一律拒絕。把守門員放在 Server,而不是寄望模型乖乖聽話。
MCP 除錯最常見的三類問題:一是『Claude 看不到工具』,通常是工具定義沒正確註冊或傳輸沒連上;二是『工具被呼叫但參數怪怪的』,多半是你給工具的說明寫得不夠清楚,Claude 猜錯了該帶什麼;三是『查回來的東西 Claude 解讀錯』,通常是回傳格式太亂。實務上,先在你的 Server 端把每一次收到的請求和回傳都記錄下來(log),九成的問題看 log 就能定位。
如果你的團隊有一堆內部資料散在不同系統,而你希望用自然語言就能查到,自製 MCP Server 是把這些工具安全接上 AI 的標準做法。關鍵心法只有一句:把 Server 當成不信任外部請求的守門員來設計。先用唯讀、低風險的工具上線,確認權限和 log 都運作正常,再逐步開放更多能力。先求安全可控,再求功能齊全,順序錯了,出事的代價會遠高於你省下的時間。