Model Context Protocol 正在成為 AI 應用連線外部工具的標準通道。當越來越多的 agent 開始通過 MCP 呼叫伺服器，SaaS 團隊面臨的就不只是「服務掛了沒有」的問題，而是「agent 是否選錯了工具」「模型是否把引數傳歪了」這類更微妙的問題。Spanly 就是衝著這個空白來的——它的定位是 MCP 伺服器的可觀測性與監控平臺。
從官網資訊來看，Spanly 主打的是「drop-in」式的接入體驗。你不用改業務程式碼，通過 CLI 或 SDK 就能為現有的 MCP 伺服器接入監控。它監控的維度包括 錯誤率、會話軌跡、延遲、客戶端分析以及部署告警，基本覆蓋了一個生產級服務需要盯住的全部關鍵指標。
監控的不只是健康狀態
傳統監控工具關注 p95 延遲和錯誤碼，但 MCP 伺服器的問題往往更深一層。Spanly 官網展示的介面裡，問題被歸類為「工具投毒」「Schema 正確性」「執行時安全」等型別。舉幾個例子：提示注入出現在工具輸出裡、工具引數中返回了金鑰、工具名稱讓 agent 選錯指令、schema 接受格式錯誤的引數——這些都不是傳統 APM 能直接告訴你的。
官方強調，掃描器已經分析了大量生產 MCP 伺服器（官網當天顯示「11,127 臺 MCP 伺服器被掃描」），因此它「知道問題長什麼樣」。這種基於大規模掃描積累的檢測能力，是它區別於通用監控工具的關鍵賣點。
從發現問題到自動修復
更實用的一點是，Spanly 不只是報問題，還嘗試給出補丁。官網截圖顯示，它可以針對某個工具的重新命名、schema 收緊、輸出裁剪等提出修改建議，並且通過 A/B 方式先在 10%～20% 的實時會話中測試，驗證有效後再逐步應用到全部流量。這個「先小範圍驗證再全量上線」的思路，對生產環境來說很務實。
同時，它會把修復建議按來源分門別類，有的等待上游更新，有的可以直接應用。這意味著團隊不用自己從頭分析 MCP 協議細節，省掉不少排查時間。
整合與資料駐留
在現有監控棧的處理上，Spanly 沒有打算取代 Datadog、Sentry 或 New Relic，而是作為補充，與它們共存。如果你已經在用這些工具，可以把它當成 MCP 層的專用探針。此外，它提供美國與歐盟兩個地區的資料駐留選項，對資料合規要求高的企業會比較友好。
具體部署方式上，官方提供 CLI 指令碼和 SDK，支援 30 秒免費掃描。價格方面，明確有免費層，但完整價格體系沒有完全公開，需要以官網為準。
適合誰用
如果你的團隊已經在生產環境對外提供 MCP 伺服器，並且使用者是各類 AI agent 客戶端，那 Spanly 會是一個值得試用的補充監控層。它特別適合那種「明明服務沒掛，但 agent 就是表現不對」的場景——問題往往不在響應狀態碼裡，而在工具暴露的方式上。
另一個典型場景是，當一個 MCP 伺服器要同時服務 Claude、Cursor 等多種客戶端時，不同客戶端對工具的呼叫方式可能存在差異。官網那句話「Works in Claude, Broken in Cursor」說的就是這種痛苦。用統一的掃描和監控來提前暴露問題，比等客戶投訴要聰明得多。
當然，Spanly 本身還很年輕，公開的技術細節有限，掃描器的檢測準確性也需要更多實際部署來驗證。建議先跑一次免費掃描，看看它能不能命中你已知的幾個隱患點，再決定要不要深入接入。
對任何正在把 MCP 推向生產的人來說，可觀測性遲早要補上。Spanly 是這一領域走得比較早的玩家之一，值得關注。
評論
暫無評論
成為第一個評論的人