OpenClaw Gateway 跑通之後，接入 MCP 工具鏈的難點往往不在「能 ping 通」，而在傳輸形態選型、子進程生命週期、握手協定與下游僵死。本文與站內 MCP 白名單與連通性、安全加固、跨平台安裝 分工：先給邊界說明與七條自檢痛點，再用stdio 與 HTTP／SSE 對照表定架構，附七步可重現接入、工具探索與版本漂移注意點，以及症狀→處理速查，幫助把 MCP 當成可稽核的供應鏈而不是臨時指令稿。
安裝篇解決的是 Gateway 進程如何常駐；安全篇解決監聽面、權杖、dmPolicy 與出站；白名單篇解決工具註冊與權限拒絕時的第一反應。本文落在它們之後：專門講 stdio 子進程與 HTTP 遠端 MCP在維運上的差異，以及握手、逾時、僵死時你該看哪幾類日誌。
若下面七條裡有三條以上命中，建議在評審單裡單獨開一行「MCP 運行級」風險，而不是把它合併進「再試試重啟 Gateway」的模糊項。
命令列只在開發機成立：npx 路徑、Node 小版本與全域套件在 systemd 環境下與互動式 shell 不一致，導致「我 SSH 上去能跑、Gateway 拉起來就掛」。
工作目錄隱含相依：MCP 子進程假設從某儲存庫根啟動，換到空 HOME 或唯讀掛載後靜默失敗。
HTTP MCP 只管 URL 不管 TLS：憑證鏈、SNI、內網自簽與 networkPolicy 組合錯誤時，症狀像「無限握手」。
工具列表快取過舊：伺服器端增刪工具後，用戶端仍依舊 schema 呼叫，表現為隨機參數校驗失敗。
無逾時的長呼叫：下游 API 卡住時 Gateway 側執行緒／連線不釋放，最終拖成全域僵死。
子進程殭屍化：stdio 管道一端關閉不當，子進程活著但不讀寫，佔用 fd 與 CPU 空轉。
設定漂移無人簽核：openclaw.json 在多臺機各改一份，沒有 validate／doctor 紀錄，排錯全靠口耳相傳。
把這些點寫進 Runbook 後，MCP 才能和 CI 一樣有「變更單 + 回滾版本」。接下來用一張表把 stdio 與 HTTP 的維運成本攤平，避免會上一句「遠端比較方便」就把 TLS 與出站治理整個跳過。
2026 年常見的平台工程實踐裡，工具鏈治理會和「誰能在生產環境起子進程」綁定：stdio 形態把邊界壓在作業系統使用者與檔案權限上，HTTP 形態則把邊界壓在網路策略與身分權杖上，兩者沒有絕對優劣，只有是否與你現有觀測與值班模型匹配。
這張表用於和 SRE、安全與業務方對齊：不要只比較「延遲」，要把身分、出站、升級與故障隔離一起算進去。
| 維度 | stdio（本機子進程） | HTTP／SSE 類遠端 MCP |
|---|---|---|
| 典型部署 | 與 Gateway 同機或同容器命名空間 | 獨立服務、Sidecar 或內網叢集 |
| 身分與信任 | OS 使用者、檔案權限、可選沙箱 | mTLS、Bearer、反向代理鑑權 |
| 升級路徑 | 鎖鏡像／套件版本，滾動 Gateway 或子進程套件 | 獨立藍綠，注意協定版本協商 |
| 觀測重點 | 結束代碼、stderr、fd 外洩、OOM | HTTP 5xx／429、連線池、TLS 握手耗時 |
| 失敗隔離 | 程序崩潰可由 supervisor 重啟 | 網路分區可能拖慢多個工具，需要熔斷 |
MCP 落地的本質是「把工具呼叫變成有版本、有邊界、可回滾的供應鏈」；傳輸方式只決定你把複雜度放在核心邊還是網路邊。
若你已依 安全加固收斂了 networkPolicy，引入 HTTP MCP 時要重新過一遍出站白名單；stdio 形態則要複查 Gateway 執行使用者能否執行預期二進位檔，避免「為了省事 chmod +x 全世界」。
下列步驟假設你已有可啟動的 Gateway；若尚未完成安裝與 daemon，請先回到跨平台安裝與 systemd／Docker 生產篇。
凍結執行時：紀錄 Node 小版本、套件管理員與 MCP server 套件版本；生產與預發必須同源。
最小 stdio 探針：用非互動命令在與 Gateway 相同使用者下手動啟動一次 MCP，確認 PATH 與 cwd。
寫入設定片段：在 openclaw.json（或專案文件指定的設定檔）登記 server，命名使用團隊前綴避免撞名。
跑校驗鏈路：先 openclaw config:validate，再 openclaw doctor；差異進變更單。
接通白名單：依 白名單篇把工具名與命名空間收斂到最小集。
加觀測掛鉤：為子進程 CPU／記憶體與 HTTP MCP 的 P95 延遲設閾值，接入現有日誌管道。
演練回滾：保留上一份可用設定與鏡像 digest，確保「刪一條 MCP 設定」即可恢復基線。
{
"mcpServers": {
"corp-files-stdio": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/var/lib/openclaw/mcp-data"],
"env": { "NODE_OPTIONS": "--max-old-space-size=512" }
},
"internal-api-http": {
"url": "https://mcp.internal.example/sse",
"headers": { "Authorization": "Bearer ${MCP_SERVICE_TOKEN}" }
}
}
}
提示：真實鍵名與巢狀路徑以你使用的 OpenClaw 版本文件為準；上圖僅表達「stdio 與 HTTP 兩類入口並存」時的結構思想。升級大版本前務必重跑 validate 並對照發行說明裡的破壞性變更。
MCP 工具名在網關側往往會帶上命名空間；若多環境共用同一 Gateway，容易出現「同名不同實作」的呼叫事故。建議在設定裡顯式前綴（如 prod_／stg_），並在發佈清單裡列出本次變更的工具列表 diff。
滾動升級 HTTP MCP 時，優先保證向後相容的 schema；若必須破壞相容，應同時更新 Gateway 側允許列表並灰度一小部分工作階段流量。stdio 類 server 升級則要關注二進位 ABI 與動態連結函式庫路徑，尤其在精簡容器鏡像中。
注意：不要在生產 Gateway 上直接試用未鎖版本的 npx -y 拉最新套件；應改為固定 digest 或內部製品庫，否則供應鏈稽核鏈斷裂。
下列症狀表用於 on-call 首屏；細節仍需結合 Gateway 日誌與上游 MCP 實作文件。
| 現象 | 優先檢查 | 常見處理 |
|---|---|---|
| 握手立即失敗 | 版本欄位、鑑權標頭、TLS 鏈 | 對齊協定版本；修正憑證或放行 SNI |
| 首次成功後再也調不通 | 連線池耗盡、子進程卡死 | 重啟 MCP 側；加逾時與熔斷 |
| 工具列表缺項 | 快取、灰度路由、白名單 | 清快取；校對 allowlist 與路由規則 |
| 隨機逾時 | 下游 API、配額、DNS | 分層逾時；列印 trace id |
openclaw.json 應保留校驗命令輸出片段在工單中，便於事後復盤。把 MCP 全壓在開發筆電上，容易在睡眠、VPN 抖動與多使用者桌面工作階段裡出現「工具偶發不可用」；把 HTTP MCP 隨便暴露在公網而缺少 TLS 與策略，則會把 Gateway 的攻擊面成倍放大。若你的團隊還需要在穩定 macOS 環境裡跑與 Apple 工具鏈相關的自動化（例如與行動建置、簽署或本機 Agent 結合的 MCP 工具），將執行層放到合約化的遠端 Mac 節點通常比混用個人裝置更易做權限與日誌邊界。綜合傳輸選型、子進程治理與值班模型，NodeMini 的 Mac Mini 雲端租賃適合作為補充算力平面：與 OpenClaw 專欄中的安裝、安全與觀測文章一起規劃，可把「模型網關 + 工具鏈 + macOS 執行」拆成清晰的責任層。
白名單篇講註冊、權限與連通性第一反應；本文講 stdio／HTTP 選型、生命週期與僵死。建議評審會兩張表一起過。
從 部落格 OpenClaw 分類進入安裝、systemd、Docker、安全與觀測篇，再按需回到本文做 MCP 運行級細化。