寫過 MCP 伺服器的人都遇過同一種情境：Claude Code 或 Cursor 明明看得到工具、也回報有呼叫，但結果就是不對——回覆的欄位少一半、參數被吞掉、或者整個呼叫卡在那邊十幾秒沒有錯誤訊息。翻官方 MCP Inspector 找不到蛛絲馬跡，因為 Inspector 根本不在客戶端跟伺服器之間的那條線上。mcpsnoop 這支 2026 年 7 月出現在 Hacker News 的 Go 工具，把自己包成一層透明代理，直接坐進資料路徑，然後在終端機開一個像 Wireshark 那樣的 TUI 攤出每一個 frame。
Inspector 為什麼看不見「真的在發生的事」
MCP Inspector 從第一天就設計成獨立客戶端，用 SSE 或 stdio 連上伺服器，走一次自己的 tools/list、按按鈕觸發 tools/call。它是一支 Postman，不是 Wireshark。生產環境裡 Cursor 呼出去的請求、Claude Code 收回來的回應，Inspector 那條 tab 從頭到尾都不知情。
這造成一批「沒有 log 的錯誤」實務上完全查不到：LLM 拿到 tool schema 之後決定不呼叫某個工具，Inspector 看不出來；某個 tool call 被送出去、但伺服器因為 stdout 混進一行 console.log 導致 JSON-RPC frame 損毀，Inspector 看不出來；伺服器把回覆卡在 pending 六十秒後被客戶端逾時掉，Inspector 也看不出來。stdio transport 這條路更慘，任何一行寫到 stdout 的 debug 輸出都會直接把協定串流打壞，等於工程師連 print 除錯都不能用。
Inspector 自己也不是沒事：CVE-2025-49596 曾經讓它變成一個開埠就吃 RCE 的破口，升級不夠快的人得先關掉 Inspector 才敢跑其他 MCP 伺服器。工具層面就已經有兩層洞——一是視野不足，二是自身安全。
mcpsnoop 的雙角色 binary：shim 跑在資料路徑上，hub 只做觀察
mcpsnoop 的架構乾淨到一句話講得完：同一支 Go binary，靠參數決定要當 shim 還是 hub。
當客戶端設定裡把 command 從 node build/index.js 改成 mcpsnoop -- node build/index.js，客戶端 spawn 出來的其實是 shim；shim 再 fork 出真正的伺服器，兩邊 stdin/stdout 逐位元組轉發，跟原本沒有 proxy 一模一樣。差別在於 shim 把每個 JSON-RPC frame 複製一份寫到本機 JSONL 檔跟一個 well-known Unix socket。
hub/UI 這一半在終端機另一個視窗跑 mcpsnoop 就開起來，兩邊透過 socket 自動配對，沒有先後順序也不用開防火牆埠。轉發跟觀察是完全解耦的，就算 TUI 沒開，session log 還是照寫；就算 log 磁碟寫失敗，資料路徑本身也不會被阻塞。這個「best-effort observability」的取捨對生產環境很重要——除錯工具不該是可觀測的單點故障來源。
streamable-HTTP transport 走另一條路：mcpsnoop http --target http://localhost:3000/mcp --listen :7000，變成標準的 reverse proxy。HTTP 狀態碼會被當成 frame 呈現，所以 401 挑戰、403 拒絕、502 錯誤都會躺在 stream 裡讓人拿 status:401 filter 撈。
工具定義漂移偵測：一個 MCP 生態一直沒認真面對的攻擊面
比逐 frame 觀察更有意思的功能是 baseline。mcpsnoop 會把某個 label 第一次完整看到的 tools/list 存成基準，之後每次 session 拿新的 tools/list 逐欄位比對——description、title、input/output schema、annotations、icons 全部對。
這件事聽起來像類型檢查，實際上處理的是 supply chain 安全問題。一個 MCP 伺服器如果第一次註冊時宣稱某個工具是 readOnlyHint: true、拿到客戶端批准，之後版本更新把該欄位改成 destructive，客戶端不會重新問使用者。攻擊者拿到伺服器的寫入權，就能把定義換成任意內容並繼承既有信任。
mcpsnoop baseline session.jsonl 會列出差異，--accept 用來接受合法變更、--reset 用來重新學。CI 情境把 baseline 放到持久化目錄後，用 mcpsnoop check --fail-on drift 就能在偏移發生時中斷 pipeline。對於在 VPS 上跑自架 MCP server 服務內部 AI Agent 的團隊，這是把「工具定義是可信的靜態文件」這個假設從口頭承諾降到可驗證的形式。
Session 匯出跟 replay 讓 bug report 有意義
mcpsnoop export 支援 JSON、HTML、text、HAR、OTLP 五種格式。HAR 這個選項很值得注意：捕到的一段 session 匯成 HAR 之後，直接拉進瀏覽器 DevTools 的 Network 面板就能看，等於把工程師既有的除錯肌肉記憶複用過來。OTLP 則是把每個 tool call 當成 span 丟給 collector，_meta.traceparent 支援 W3C trace context，可以跟呼叫端的 trace 接起來——如果部署已經有 SigNoz、Langfuse 或 Grafana Tempo，MCP 這一層就不會再變成觀測盲區。
Replay 功能允許在 TUI 裡對任何抓到的 tool call 按 r，工具會用乾淨的一份伺服器實例重跑同一個請求。這對回報者跟修 bug 者之間的溝通成本是巨大改善——過去要重現「某個特定 payload 觸發的問題」得請對方把整段對話抄出來，現在把 session.jsonl 傳過去、對面自己 replay 就結束。
遠端監看走 SSH，避免自己再蓋一層 auth
mcpsnoop remote user@host 印出一段 ssh -R 指令，把工作站上的 mcpsnoop socket 反向轉發到遠端主機，遠端跑的 shim 就會把 frame 送回本機 TUI 顯示。整套機制完全建立在 SSH 之上，沒有另外的 API key、沒有另外開放的埠、沒有另外一層要維護的 TLS。
事後檢視則更簡單：ssh user@host 'cat ~/.local/state/mcpsnoop/sessions/session.jsonl' | mcpsnoop open -，把遠端的 session 直接 pipe 進本機 UI。對於在臺灣機房跑 MCP 伺服器、開發人員在辦公室或家裡工作的常見架構，這條路徑省下自己蓋 web dashboard 的兩週。
Redaction 是「best-effort」而不是安全承諾
被人蒙混過去的一個細節：--redact-secrets、--redact-key、--redact-value、--redact-path 只作用在寫入本機的 trace 副本，實際在資料路徑上流動的原始位元組不會被改動。這個設計是對的——除錯工具不該修改真實流量——但意味著如果 log 檔本身被上傳（丟給 bug report、傳給協力廠商），redaction 品質才有意義；如果 log 只留在本機、SSH 傳給自己看，其實不需要 redaction。
Regex 型的 redaction 對 Base64 編碼過或轉義過的 secret 抓不到，這是文件明講的限制。真正在意 secret 洩漏的環境，寧可加 --no-trace 完全關掉磁碟寫入、只走記憶體。
什麼時候應該裝、什麼時候是過度工具化
在本機用 MCP Inspector 對著 hello-world 級的伺服器點幾下按鈕，mcpsnoop 是多餘的。它的價值出現在：伺服器要放到生產環境 VPS 上服務內部團隊、多客戶端（Claude Desktop + Cursor + Claude Code）並行使用同一支伺服器、需要在 CI 中檢查回歸、或必須追一個「只在特定客戶端才發生」的靈異 bug。
換句話說，判斷標準不是 MCP 伺服器複不複雜，是「有沒有人真的在依賴它」。獨立開發者寫 side project，不用；為公司內部 AI Agent 生產化 MCP 工具鏈，這是目前生態裡最省事的觀測方案，沒有之一。
自架 MCP 伺服器或內部 AI Agent 服務，效能跟穩定性建立在底層主機上。NCSE Network 提供臺灣是方電訊機房、Intel Gold CPU 與 NVMe SSD 的 VPS，適合部署 MCP 伺服器、LLM Gateway、AI Agent workflow 等對延遲跟磁碟 I/O 敏感的服務，若正在評估相關基礎設施，可參考 ncse.tw 的方案資訊。
