跑成功一次不等於整合完成：MCP 怎麼分辨
《Agentic Design Patterns》第 10 章講 MCP（Model Context Protocol）。核心一句話：給 agent 一個標準化的插座，讓它用同一套協定接外部工具和資料，不必每接一個服務就手刻一套黏合碼。插座裝好，任何 agent 都能插上去用。
我們讀完，剛好手上有一個現成的例子可以拿來說嘴。我用 Portaly 的 MCP server，一口氣建了 9 個金流商品：initialize、tools/list、tools/call 一路通到底，商品名、價格、active 狀態、portaly.cc 上真的可以打開的付款頁，全都是真的。MCP 整合，實作完成，打勾。然後我對自己做了一次對抗式稽核。這一章的真相是：那支腳本這輩子只跑過一次，而 .claude.json 裡一個 MCP server 都沒有。
round-trip 是真的，整合是假的
先說清楚哪部分是真的：那 9 個商品不是 demo 截圖，是真的物件。回傳的 JSON 裡每個都有 id、價格、status: active、可以打開的 previewUrl，Portaly 後台今天還在。協定層也是真的走完整套 JSON-RPC 握手。就 MCP 這個手法本身而言，它成立。
問題在「這算不算我們有 MCP 整合」。整件事是一支住在 ~/HQ/tmp/ 的 .mjs，token 寫死在第 4 行，我在終端機手打 node 跑了它一次，存下一個 portaly-result.json，然後就沒有然後了。艦隊沒有任何 timer、hook、cron 會再碰它。.claude.json 裡每一個 mcpServers 區塊都是空的 {}，Portaly 這個名字在整份 config 裡一次都沒出現。
所以誠實的講法不是「我們有 MCP 整合」，是「我們手動跑過一次 MCP，成功建了 9 個商品」。這兩句聽起來很像，差別是後者可重複、可被艦隊呼叫、下次還會自己發生，前者只在我手打指令的那 90 秒裡活著。把後者記成前者，就是把一次成功的 demo 冒充成一條上線的能力。
先花幾分鐘查你宣稱的 MCP 整合
01 查它有沒有註冊進 config
真正的整合住在設定檔，不是住在你的 shell 歷史裡。翻你的 host config（.claude.json、.mcp.json，或你的框架用的那個），找那個 server。mcpServers 是空的 {}，就代表沒有任何 agent 被接上去，你跑的那次是純手動。
# 把所有 mcpServers 區塊撈出來，看是不是全空的 {}
grep -oE '"mcpServers": \{[^}]*\}' ~/.claude.json | sort | uniq -c
# 或直接找那個 server 名字，一筆都撈不到 = 零註冊
grep -i 'portaly' ~/.claude.json ~/.mcp.json 2>/dev/null
紅旗：mcpServers 全是 {}，或你搜 server 名字一筆都沒有。它沒被裝進系統，只是被你手動跑過。
02 查它是排程自動觸發，還是人肉手動跑
常態整合背後有東西會替你觸發它：一個 timer、一條 cron、一個 hook、一個下游任務。一次性的背後是一個人（你）在打 node xxx.mjs。看除了你的手，還有誰會叫那支 driver。
# 有沒有任何排程或 hook 會叫它（換成你的 driver 檔名）
systemctl --user list-timers | grep -i portaly
crontab -l 2>/dev/null | grep -i portaly
grep -rl 'portaly-mcp-drive' ~/.openclaw ~/.claude 2>/dev/null
紅旗：三個都空的。沒有 timer、沒有 cron、除了你的終端機沒有任何東西引用那支 driver。
03 查一次性 demo 和常態整合的差別
一次性有它的味道：driver 住在 tmp/、token 寫死在原始碼裡、產出檔寫過一次就沒人再讀、最後改動時間停在你 demo 的那天。
# driver 住哪、token 是不是寫死、產出停在哪天
ls -la ~/HQ/tmp/*mcp* ; stat -c '%y %n' ~/HQ/tmp/portaly-result.json
grep -nE 'TOKEN *=|API_TOKEN' ~/HQ/tmp/portaly-mcp-drive.mjs
紅旗：driver 在 tmp/、憑證寫死在檔案裡、產出的時間戳停在 demo 當天、之後沒有任何流程再讀它。
我們沒有把它寫成整合
這一章我們沒有踩到帳單，也沒有東西壞掉，要修的不是程式，是講法。9 個商品是真的成績，我們會照用這個數字；但我們不會把它寫進「艦隊的 MCP 能力」那一欄。它就是它的樣子：一支一次性的 HQ 側 driver，證明了 Portaly MCP 這條路走得通，如此而已。要讓它變成真的整合，得把 server 註冊進 config、把 token 從原始碼挪進受管的憑證、給它一個排程或讓某個下游流程去消費它的產出，那是另一件工，還沒做。在那之前，它是一次漂亮的 round-trip，不是一條上線的整合。
MCP 最容易騙到自己的地方就在這裡：協定跑通的那一刻手感太好，initialize 一回、tools/list 一列、tools/call 一建就成，你會很自然地把「協定會動」記成「整合上線」。但會動的是協定，不是你的系統。
MCP 整合體檢清單
對你自己宣稱的每一個 MCP 或工具整合跑一遍：
- 那個 server 有註冊進 config 嗎，還是
mcpServers是空的{} - 除了你手打指令，有沒有 timer／cron／hook／下游任務會觸發它
- driver 住在正式路徑還是
tmp/，token 是受管憑證還是寫死在原始碼 - 它的產出有沒有被下游常態消費，還是寫過一次就沒人再讀
- 你講的是「我們有 X 整合」，還是「我們手動跑過一次 X」，這兩句你分得清嗎
- 最後一次真的跑，是哪一天
這一章的四句話
- MCP 給 agent 一個標準插座接工具，但插座裝好，跟你親手插過一次，是兩件事。
- 跑成功一次不等於整合完成。可重複、被排程或被艦隊呼叫，才叫整合。
- 查真假最快的一刀是翻 config。
mcpServers是{}，就沒有任何常態整合，不管你 demo 多漂亮。 - 住在
tmp/、token 寫死、產出時間戳停在 demo 當天，這三個味道加起來就是「一次性」，別把它算進你的能力。
原始碼位置：~/HQ/tmp/portaly-mcp-drive.mjs（HQ 手動跑的一次性 MCP stdio driver，token 寫死在原始碼、最後改動停在 2026-07-03），產出落在 ~/HQ/tmp/portaly-result.json（9 個真商品，含 id／價格／active 狀態／付款頁 URL）。艦隊的 .claude.json 全數 mcpServers: {}，Portaly 零註冊。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。